In preparation for the BIND 9.6.1rc1 import, remove these two directories.

We do not install these files so there is little use to keeping them in
the tree, and the drafts directory in particular is the source of a lot
of churn for each new version.

158 files changed, 0 insertions, 153744 deletions

diff --git a/doc/draft/draft-baba-dnsext-acl-reqts-01.txt b/doc/draft/draft-baba-dnsext-acl-reqts-01.txt
deleted file mode 100644
index 1030e57..0000000
--- a/doc/draft/draft-baba-dnsext-acl-reqts-01.txt
+++ /dev/null
@@ -1,336 +0,0 @@
-
-
-
-
-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
deleted file mode 100644
index fffa8a5..0000000
--- a/doc/draft/draft-daigle-napstr-04.txt
+++ /dev/null
@@ -1,1232 +0,0 @@
-
-
-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
deleted file mode 100644
index 4a01d91..0000000
--- a/doc/draft/draft-danisch-dns-rr-smtp-03.txt
+++ /dev/null
@@ -1,1960 +0,0 @@
-
-
-
-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
deleted file mode 100644
index 7b5e8cc..0000000
--- a/doc/draft/draft-dnsext-opcode-discover-02.txt
+++ /dev/null
@@ -1,241 +0,0 @@
-
-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
deleted file mode 100644
index 224e7ad1..0000000
--- a/doc/draft/draft-durand-dnsop-dynreverse-00.txt
+++ /dev/null
@@ -1,240 +0,0 @@
-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
deleted file mode 100644
index fa41e76..0000000
--- a/doc/draft/draft-ietf-dnsext-2929bis-01.txt
+++ /dev/null
@@ -1,928 +0,0 @@
-
-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
deleted file mode 100644
index f0ce70a..0000000
--- a/doc/draft/draft-ietf-dnsext-axfr-clarify-05.txt
+++ /dev/null
@@ -1,393 +0,0 @@
-
-
-
-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
deleted file mode 100644
index 07749d9..0000000
--- a/doc/draft/draft-ietf-dnsext-dhcid-rr-12.txt
+++ /dev/null
@@ -1,674 +0,0 @@
-
-
-
-
-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
deleted file mode 100644
index 438e800..0000000
--- a/doc/draft/draft-ietf-dnsext-dns-name-p-s-00.txt
+++ /dev/null
@@ -1,1397 +0,0 @@
-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
deleted file mode 100644
index bcc2b4e..0000000
--- a/doc/draft/draft-ietf-dnsext-dnssec-2535typecode-change-06.txt
+++ /dev/null
@@ -1,442 +0,0 @@
-
-
-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
deleted file mode 100644
index 3a800f9..0000000
--- a/doc/draft/draft-ietf-dnsext-dnssec-bis-updates-01.txt
+++ /dev/null
@@ -1,616 +0,0 @@
-
-
-
-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
deleted file mode 100644
index ee03583..0000000
--- a/doc/draft/draft-ietf-dnsext-dnssec-experiments-01.txt
+++ /dev/null
@@ -1,784 +0,0 @@
-
-
-
-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
deleted file mode 100644
index 7503c66..0000000
--- a/doc/draft/draft-ietf-dnsext-dnssec-online-signing-02.txt
+++ /dev/null
@@ -1,616 +0,0 @@
-
-
-
-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
deleted file mode 100644
index 17e28e8..0000000
--- a/doc/draft/draft-ietf-dnsext-dnssec-opt-in-07.txt
+++ /dev/null
@@ -1,896 +0,0 @@
-
-
-
-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
deleted file mode 100644
index 390420a..0000000
--- a/doc/draft/draft-ietf-dnsext-dnssec-rsasha256-00.txt
+++ /dev/null
@@ -1,392 +0,0 @@
-
-
-
-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
deleted file mode 100644
index dd8cbf0..0000000
--- a/doc/draft/draft-ietf-dnsext-dnssec-trans-02.txt
+++ /dev/null
@@ -1,839 +0,0 @@
-
-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
deleted file mode 100644
index 2460cb6..0000000
--- a/doc/draft/draft-ietf-dnsext-ds-sha256-05.txt
+++ /dev/null
@@ -1,504 +0,0 @@
-
-
-
-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
deleted file mode 100644
index 2cdcdb1..0000000
--- a/doc/draft/draft-ietf-dnsext-ecc-key-07.txt
+++ /dev/null
@@ -1,928 +0,0 @@
-
-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
deleted file mode 100644
index 160afc3..0000000
--- a/doc/draft/draft-ietf-dnsext-interop3597-02.txt
+++ /dev/null
@@ -1,334 +0,0 @@
-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
deleted file mode 100644
index 6bffb70..0000000
--- a/doc/draft/draft-ietf-dnsext-keyrr-key-signing-flag-12.txt
+++ /dev/null
@@ -1,560 +0,0 @@
-
-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
deleted file mode 100644
index 5de6e85..0000000
--- a/doc/draft/draft-ietf-dnsext-mdns-43.txt
+++ /dev/null
@@ -1,1740 +0,0 @@
-
-
-
-
-
-
-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
deleted file mode 100644
index 8c6c5b1..0000000
--- a/doc/draft/draft-ietf-dnsext-nsec3-04.txt
+++ /dev/null
@@ -1,2352 +0,0 @@
-
-
-
-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
deleted file mode 100644
index 90d1a06..0000000
--- a/doc/draft/draft-ietf-dnsext-nsid-01.txt
+++ /dev/null
@@ -1,840 +0,0 @@
-
-
-
-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
deleted file mode 100644
index 5b6d655..0000000
--- a/doc/draft/draft-ietf-dnsext-rfc2536bis-dsa-06.txt
+++ /dev/null
@@ -1,464 +0,0 @@
-
-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
deleted file mode 100644
index 2ec9dbe..0000000
--- a/doc/draft/draft-ietf-dnsext-rfc2538bis-04.txt
+++ /dev/null
@@ -1,840 +0,0 @@
-
-
-
-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
deleted file mode 100644
index 5e6cb1d..0000000
--- a/doc/draft/draft-ietf-dnsext-rfc2539bis-dhk-06.txt
+++ /dev/null
@@ -1,580 +0,0 @@
-
-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
deleted file mode 100644
index 0af13c6..0000000
--- a/doc/draft/draft-ietf-dnsext-signed-nonexistence-requirements-01.txt
+++ /dev/null
@@ -1,755 +0,0 @@
-
-
-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
deleted file mode 100644
index 9c73c68..0000000
--- a/doc/draft/draft-ietf-dnsext-tkey-renewal-mode-05.txt
+++ /dev/null
@@ -1,1292 +0,0 @@
-
-
-
-
-
-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
deleted file mode 100644
index a598826..0000000
--- a/doc/draft/draft-ietf-dnsext-trustupdate-threshold-00.txt
+++ /dev/null
@@ -1,1501 +0,0 @@
-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
deleted file mode 100644
index 7cb9063..0000000
--- a/doc/draft/draft-ietf-dnsext-trustupdate-timers-02.txt
+++ /dev/null
@@ -1,730 +0,0 @@
-
-
-
-
-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
deleted file mode 100644
index 00476ae..0000000
--- a/doc/draft/draft-ietf-dnsext-tsig-sha-06.txt
+++ /dev/null
@@ -1,522 +0,0 @@
-
-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
deleted file mode 100644
index 9cf88a5..0000000
--- a/doc/draft/draft-ietf-dnsext-wcard-clarify-10.txt
+++ /dev/null
@@ -1,1063 +0,0 @@
-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
deleted file mode 100644
index 0855ba3..0000000
--- a/doc/draft/draft-ietf-dnsop-bad-dns-res-05.txt
+++ /dev/null
@@ -1,1232 +0,0 @@
-
-
-
-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
deleted file mode 100644
index 8ca68a8..0000000
--- a/doc/draft/draft-ietf-dnsop-dnssec-operational-practices-08.txt
+++ /dev/null
@@ -1,2016 +0,0 @@
-
-
-
-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
deleted file mode 100644
index bcd0d14..0000000
--- a/doc/draft/draft-ietf-dnsop-inaddr-required-07.txt
+++ /dev/null
@@ -1,396 +0,0 @@
-
-
-
-
-
-
-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
deleted file mode 100644
index bf2afcd..0000000
--- a/doc/draft/draft-ietf-dnsop-ipv6-dns-configuration-06.txt
+++ /dev/null
@@ -1,1848 +0,0 @@
-
-
-
-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
deleted file mode 100644
index 1276f9f..0000000
--- a/doc/draft/draft-ietf-dnsop-ipv6-dns-issues-11.txt
+++ /dev/null
@@ -1,1682 +0,0 @@
-
-
-
-
-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
deleted file mode 100644
index b2e2341..0000000
--- a/doc/draft/draft-ietf-dnsop-ipv6-transport-guidelines-01.txt
+++ /dev/null
@@ -1,300 +0,0 @@
-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
deleted file mode 100644
index 6bece56..0000000
--- a/doc/draft/draft-ietf-dnsop-key-rollover-requirements-02.txt
+++ /dev/null
@@ -1,389 +0,0 @@
-
-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
deleted file mode 100644
index 63fe2de..0000000
--- a/doc/draft/draft-ietf-dnsop-respsize-02.txt
+++ /dev/null
@@ -1,480 +0,0 @@
-
-
-
-
-
-
-   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
deleted file mode 100644
index c6ec7e4..0000000
--- a/doc/draft/draft-ietf-dnsop-serverid-06.txt
+++ /dev/null
@@ -1,618 +0,0 @@
-
-
-
-
-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
deleted file mode 100644
index 3353b3b..0000000
--- a/doc/draft/draft-ietf-enum-e164-gstn-np-05.txt
+++ /dev/null
@@ -1,1588 +0,0 @@
-
-                                                            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
deleted file mode 100644
index 2d5c87e..0000000
--- a/doc/draft/draft-ietf-ipv6-node-requirements-08.txt
+++ /dev/null
@@ -1,1200 +0,0 @@
-
-
-
-
-
-
-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
deleted file mode 100644
index a272d81..0000000
--- a/doc/draft/draft-ietf-secsh-dns-05.txt
+++ /dev/null
@@ -1,614 +0,0 @@
-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
deleted file mode 100644
index 3578d2a..0000000
--- a/doc/draft/draft-ihren-dnsext-threshold-validation-00.txt
+++ /dev/null
@@ -1,519 +0,0 @@
-
-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
deleted file mode 100644
index d857cd9..0000000
--- a/doc/draft/draft-kato-dnsop-local-zones-00.txt
+++ /dev/null
@@ -1,295 +0,0 @@
-
-
-
-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
deleted file mode 100644
index f9eaf26..0000000
--- a/doc/draft/draft-park-ipv6-extensions-dns-pnp-00.txt
+++ /dev/null
@@ -1,1830 +0,0 @@
-  
-  
-  
-  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
deleted file mode 100644
index 6ac2090..0000000
--- a/doc/draft/update
+++ /dev/null
@@ -1,46 +0,0 @@
-#!/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/rfc/index b/doc/rfc/index
deleted file mode 100644
index fea5f71..0000000
--- a/doc/rfc/index
+++ /dev/null
@@ -1,119 +0,0 @@
- 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
-3056:	Connection of IPv6 Domains via IPv4 Clouds
-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
-4648:	The Base16, Base32, and Base64 Data Encodings
-4701:	A DNS Resource Record (RR) for Encoding
-         Dynamic Host Configuration Protocol (DHCP) Information (DHCID RR)
-5155:	DNS Security (DNSSEC) Hashed Authenticated Denial of Existence
diff --git a/doc/rfc/rfc1032.txt b/doc/rfc/rfc1032.txt
deleted file mode 100644
index 0e82721..0000000
--- a/doc/rfc/rfc1032.txt
+++ /dev/null
@@ -1,781 +0,0 @@
-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
deleted file mode 100644
index 37029fd..0000000
--- a/doc/rfc/rfc1033.txt
+++ /dev/null
@@ -1,1229 +0,0 @@
-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
deleted file mode 100644
index 55cdb21..0000000
--- a/doc/rfc/rfc1034.txt
+++ /dev/null
@@ -1,3077 +0,0 @@
-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
deleted file mode 100644
index b1a9bf5..0000000
--- a/doc/rfc/rfc1035.txt
+++ /dev/null
@@ -1,3077 +0,0 @@
-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
deleted file mode 100644
index 66c9d8b..0000000
--- a/doc/rfc/rfc1101.txt
+++ /dev/null
@@ -1,787 +0,0 @@
-
-
-
-
-
-
-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
deleted file mode 100644
index c14f2e5..0000000
--- a/doc/rfc/rfc1122.txt
+++ /dev/null
@@ -1,6844 +0,0 @@
-
-
-
-
-
-
-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
deleted file mode 100644
index 51cdf83..0000000
--- a/doc/rfc/rfc1123.txt
+++ /dev/null
@@ -1,5782 +0,0 @@
-
-
-
-
-
-
-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
deleted file mode 100644
index 6f08044..0000000
--- a/doc/rfc/rfc1183.txt
+++ /dev/null
@@ -1,619 +0,0 @@
-
-
-
-
-
-
-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
deleted file mode 100644
index d9e5dea..0000000
--- a/doc/rfc/rfc1348.txt
+++ /dev/null
@@ -1,227 +0,0 @@
-
-
-
-
-
-
-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
deleted file mode 100644
index 03bddee..0000000
--- a/doc/rfc/rfc1535.txt
+++ /dev/null
@@ -1,283 +0,0 @@
-
-
-
-
-
-
-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
deleted file mode 100644
index 5ff2b25..0000000
--- a/doc/rfc/rfc1536.txt
+++ /dev/null
@@ -1,675 +0,0 @@
-
-
-
-
-
-
-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
deleted file mode 100644
index 81b9768..0000000
--- a/doc/rfc/rfc1537.txt
+++ /dev/null
@@ -1,507 +0,0 @@
-
-
-
-
-
-
-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
deleted file mode 100644
index 89e0a25..0000000
--- a/doc/rfc/rfc1591.txt
+++ /dev/null
@@ -1,395 +0,0 @@
-
-
-
-
-
-
-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
deleted file mode 100644
index ed5b93a..0000000
--- a/doc/rfc/rfc1611.txt
+++ /dev/null
@@ -1,1683 +0,0 @@
-
-
-
-
-
-
-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
deleted file mode 100644
index 4ef23b0..0000000
--- a/doc/rfc/rfc1612.txt
+++ /dev/null
@@ -1,1795 +0,0 @@
-
-
-
-
-
-
-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
deleted file mode 100644
index 5b5d821..0000000
--- a/doc/rfc/rfc1706.txt
+++ /dev/null
@@ -1,563 +0,0 @@
-
-
-
-
-
-
-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
deleted file mode 100644
index 40d8857..0000000
--- a/doc/rfc/rfc1712.txt
+++ /dev/null
@@ -1,395 +0,0 @@
-
-
-
-
-
-
-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
deleted file mode 100644
index 56d478c..0000000
--- a/doc/rfc/rfc1750.txt
+++ /dev/null
@@ -1,1683 +0,0 @@
-
-
-
-
-
-
-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
deleted file mode 100644
index a289cff..0000000
--- a/doc/rfc/rfc1876.txt
+++ /dev/null
@@ -1,1011 +0,0 @@
-
-
-
-
-
-
-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
deleted file mode 100644
index 9874fdd..0000000
--- a/doc/rfc/rfc1886.txt
+++ /dev/null
@@ -1,268 +0,0 @@
-
-
-
-
-
-
-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
deleted file mode 100644
index 5a34bc4..0000000
--- a/doc/rfc/rfc1982.txt
+++ /dev/null
@@ -1,394 +0,0 @@
-
-
-
-
-
-
-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
deleted file mode 100644
index b50bdc6..0000000
--- a/doc/rfc/rfc1995.txt
+++ /dev/null
@@ -1,451 +0,0 @@
-
-
-
-
-
-
-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
deleted file mode 100644
index b08f200..0000000
--- a/doc/rfc/rfc1996.txt
+++ /dev/null
@@ -1,395 +0,0 @@
-
-
-
-
-
-
-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
deleted file mode 100644
index 46ba362..0000000
--- a/doc/rfc/rfc2052.txt
+++ /dev/null
@@ -1,563 +0,0 @@
-
-
-
-
-
-
-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
deleted file mode 100644
index a205103..0000000
--- a/doc/rfc/rfc2104.txt
+++ /dev/null
@@ -1,620 +0,0 @@
-
-
-
-
-
-
-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
deleted file mode 100644
index e31fae4..0000000
--- a/doc/rfc/rfc2119.txt
+++ /dev/null
@@ -1,171 +0,0 @@
-
-
-
-
-
-
-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
deleted file mode 100644
index ea66cf0..0000000
--- a/doc/rfc/rfc2133.txt
+++ /dev/null
@@ -1,1795 +0,0 @@
-
-
-
-
-
-
-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
deleted file mode 100644
index 4d62702..0000000
--- a/doc/rfc/rfc2136.txt
+++ /dev/null
@@ -1,1460 +0,0 @@
-
-
-
-
-
-
-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
deleted file mode 100644
index ceb3613..0000000
--- a/doc/rfc/rfc2137.txt
+++ /dev/null
@@ -1,619 +0,0 @@
-
-
-
-
-
-
-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
deleted file mode 100644
index 00fcee7..0000000
--- a/doc/rfc/rfc2163.txt
+++ /dev/null
@@ -1,1459 +0,0 @@
-
-
-
-
-
-
-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
deleted file mode 100644
index 3eed1bd..0000000
--- a/doc/rfc/rfc2168.txt
+++ /dev/null
@@ -1,1123 +0,0 @@
-
-
-
-
-
-
-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
deleted file mode 100644
index 7899e1c..0000000
--- a/doc/rfc/rfc2181.txt
+++ /dev/null
@@ -1,842 +0,0 @@
-
-
-
-
-
-
-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
deleted file mode 100644
index 03995fe..0000000
--- a/doc/rfc/rfc2230.txt
+++ /dev/null
@@ -1,619 +0,0 @@
-
-
-
-
-
-
-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
deleted file mode 100644
index 9123a95..0000000
--- a/doc/rfc/rfc2308.txt
+++ /dev/null
@@ -1,1067 +0,0 @@
-
-
-
-
-
-
-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
deleted file mode 100644
index c17bb41..0000000
--- a/doc/rfc/rfc2317.txt
+++ /dev/null
@@ -1,563 +0,0 @@
-
-
-
-
-
-
-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
deleted file mode 100644
index 59fcff8..0000000
--- a/doc/rfc/rfc2373.txt
+++ /dev/null
@@ -1,1459 +0,0 @@
-
-
-
-
-
-
-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
deleted file mode 100644
index e3c7f0d..0000000
--- a/doc/rfc/rfc2374.txt
+++ /dev/null
@@ -1,675 +0,0 @@
-
-
-
-
-
-
-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
deleted file mode 100644
index a1fe8b9..0000000
--- a/doc/rfc/rfc2375.txt
+++ /dev/null
@@ -1,451 +0,0 @@
-
-
-
-
-
-
-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
deleted file mode 100644
index 9bdb2c5..0000000
--- a/doc/rfc/rfc2418.txt
+++ /dev/null
@@ -1,1459 +0,0 @@
-
-
-
-
-
-
-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
deleted file mode 100644
index fe0b3d0..0000000
--- a/doc/rfc/rfc2535.txt
+++ /dev/null
@@ -1,2635 +0,0 @@
-
-
-
-
-
-
-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
deleted file mode 100644
index 88be242..0000000
--- a/doc/rfc/rfc2536.txt
+++ /dev/null
@@ -1,339 +0,0 @@
-
-
-
-
-
-
-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
deleted file mode 100644
index cb75cf5..0000000
--- a/doc/rfc/rfc2537.txt
+++ /dev/null
@@ -1,339 +0,0 @@
-
-
-
-
-
-
-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
deleted file mode 100644
index c53e3ef..0000000
--- a/doc/rfc/rfc2538.txt
+++ /dev/null
@@ -1,563 +0,0 @@
-
-
-
-
-
-
-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
deleted file mode 100644
index cf32523..0000000
--- a/doc/rfc/rfc2539.txt
+++ /dev/null
@@ -1,395 +0,0 @@
-
-
-
-
-
-
-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
deleted file mode 100644
index 6314806..0000000
--- a/doc/rfc/rfc2540.txt
+++ /dev/null
@@ -1,339 +0,0 @@
-
-
-
-
-
-
-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
deleted file mode 100644
index a62ed2b..0000000
--- a/doc/rfc/rfc2541.txt
+++ /dev/null
@@ -1,395 +0,0 @@
-
-
-
-
-
-
-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
deleted file mode 100644
index 6989bf3..0000000
--- a/doc/rfc/rfc2553.txt
+++ /dev/null
@@ -1,2299 +0,0 @@
-
-
-
-
-
-
-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
deleted file mode 100644
index ec05f80..0000000
--- a/doc/rfc/rfc2671.txt
+++ /dev/null
@@ -1,395 +0,0 @@
-
-
-
-
-
-
-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
deleted file mode 100644
index 1103016..0000000
--- a/doc/rfc/rfc2672.txt
+++ /dev/null
@@ -1,507 +0,0 @@
-
-
-
-
-
-
-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
deleted file mode 100644
index 19d272e..0000000
--- a/doc/rfc/rfc2673.txt
+++ /dev/null
@@ -1,395 +0,0 @@
-
-
-
-
-
-
-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
deleted file mode 100644
index 1827f10..0000000
--- a/doc/rfc/rfc2782.txt
+++ /dev/null
@@ -1,675 +0,0 @@
-
-
-
-
-
-
-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
deleted file mode 100644
index fd8ef7c..0000000
--- a/doc/rfc/rfc2825.txt
+++ /dev/null
@@ -1,395 +0,0 @@
-

-

-

-

-

-

-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
deleted file mode 100644
index b4d8869..0000000
--- a/doc/rfc/rfc2826.txt
+++ /dev/null
@@ -1,339 +0,0 @@
-

-

-

-

-

-

-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
deleted file mode 100644
index aa9f385..0000000
--- a/doc/rfc/rfc2845.txt
+++ /dev/null
@@ -1,843 +0,0 @@
-
-
-
-
-
-
-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
deleted file mode 100644
index 915c104..0000000
--- a/doc/rfc/rfc2874.txt
+++ /dev/null
@@ -1,1123 +0,0 @@
-
-
-
-
-
-
-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
deleted file mode 100644
index 2022ba1..0000000
--- a/doc/rfc/rfc2915.txt
+++ /dev/null
@@ -1,1011 +0,0 @@
-
-
-
-
-
-
-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
deleted file mode 100644
index f055968..0000000
--- a/doc/rfc/rfc2929.txt
+++ /dev/null
@@ -1,675 +0,0 @@
-
-
-
-
-
-
-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
deleted file mode 100644
index f99573d..0000000
--- a/doc/rfc/rfc2930.txt
+++ /dev/null
@@ -1,899 +0,0 @@
-
-
-
-
-
-
-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
deleted file mode 100644
index 84cc97e..0000000
--- a/doc/rfc/rfc2931.txt
+++ /dev/null
@@ -1,563 +0,0 @@
-
-
-
-
-
-
-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
deleted file mode 100644
index 1697475..0000000
--- a/doc/rfc/rfc3007.txt
+++ /dev/null
@@ -1,507 +0,0 @@
-
-
-
-
-
-
-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
deleted file mode 100644
index 08a4a8f..0000000
--- a/doc/rfc/rfc3008.txt
+++ /dev/null
@@ -1,395 +0,0 @@
-
-
-
-
-
-
-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
deleted file mode 100644
index 2c4d52f..0000000
--- a/doc/rfc/rfc3071.txt
+++ /dev/null
@@ -1,563 +0,0 @@
-
-
-
-
-
-
-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
deleted file mode 100644
index 08008f7..0000000
--- a/doc/rfc/rfc3090.txt
+++ /dev/null
@@ -1,619 +0,0 @@
-
-
-
-
-
-
-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
deleted file mode 100644
index 7646948..0000000
--- a/doc/rfc/rfc3110.txt
+++ /dev/null
@@ -1,395 +0,0 @@
-
-
-
-
-
-
-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
deleted file mode 100644
index 3b2fe00..0000000
--- a/doc/rfc/rfc3123.txt
+++ /dev/null
@@ -1,451 +0,0 @@
-
-
-
-
-
-
-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
deleted file mode 100644
index b226ce6..0000000
--- a/doc/rfc/rfc3152.txt
+++ /dev/null
@@ -1,227 +0,0 @@
-
-
-
-
-
-
-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
deleted file mode 100644
index 94cefa4..0000000
--- a/doc/rfc/rfc3197.txt
+++ /dev/null
@@ -1,283 +0,0 @@
-
-
-
-
-
-
-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
deleted file mode 100644
index 13e6768..0000000
--- a/doc/rfc/rfc3225.txt
+++ /dev/null
@@ -1,339 +0,0 @@
-
-
-
-
-
-
-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
deleted file mode 100644
index dac0e11..0000000
--- a/doc/rfc/rfc3226.txt
+++ /dev/null
@@ -1,339 +0,0 @@
-
-
-
-
-
-
-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
deleted file mode 100644
index dcd4b34..0000000
--- a/doc/rfc/rfc3258.txt
+++ /dev/null
@@ -1,619 +0,0 @@
-
-
-
-
-
-
-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
deleted file mode 100644
index 9d7a39c..0000000
--- a/doc/rfc/rfc3363.txt
+++ /dev/null
@@ -1,339 +0,0 @@
-
-
-
-
-
-
-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
deleted file mode 100644
index 189c0d2..0000000
--- a/doc/rfc/rfc3364.txt
+++ /dev/null
@@ -1,619 +0,0 @@
-
-
-
-
-
-
-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
deleted file mode 100644
index 707cafd..0000000
--- a/doc/rfc/rfc3425.txt
+++ /dev/null
@@ -1,283 +0,0 @@
-
-
-
-
-
-
-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
deleted file mode 100644
index 67f9b2d..0000000
--- a/doc/rfc/rfc3445.txt
+++ /dev/null
@@ -1,563 +0,0 @@
-
-
-
-
-
-
-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
deleted file mode 100644
index 37ac7ec..0000000
--- a/doc/rfc/rfc3467.txt
+++ /dev/null
@@ -1,1739 +0,0 @@
-
-
-
-
-
-
-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
deleted file mode 100644
index d2e0b3b..0000000
--- a/doc/rfc/rfc3490.txt
+++ /dev/null
@@ -1,1235 +0,0 @@
-
-
-
-
-
-
-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
deleted file mode 100644
index dbc86c7..0000000
--- a/doc/rfc/rfc3491.txt
+++ /dev/null
@@ -1,395 +0,0 @@
-
-
-
-
-
-
-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
deleted file mode 100644
index e72ad81..0000000
--- a/doc/rfc/rfc3492.txt
+++ /dev/null
@@ -1,1963 +0,0 @@
-
-
-
-
-
-
-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
deleted file mode 100644
index 5fea6c1..0000000
--- a/doc/rfc/rfc3493.txt
+++ /dev/null
@@ -1,2187 +0,0 @@
-
-
-
-
-
-
-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
deleted file mode 100644
index 49c0fa4..0000000
--- a/doc/rfc/rfc3513.txt
+++ /dev/null
@@ -1,1459 +0,0 @@
-
-
-
-
-
-
-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
deleted file mode 100644
index f65690c..0000000
--- a/doc/rfc/rfc3596.txt
+++ /dev/null
@@ -1,451 +0,0 @@
-
-
-
-
-
-
-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
deleted file mode 100644
index 19e9a55..0000000
--- a/doc/rfc/rfc3597.txt
+++ /dev/null
@@ -1,451 +0,0 @@
-
-
-
-
-
-
-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
deleted file mode 100644
index 6126678..0000000
--- a/doc/rfc/rfc3645.txt
+++ /dev/null
@@ -1,1459 +0,0 @@
-
-
-
-
-
-
-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
deleted file mode 100644
index 13e586b..0000000
--- a/doc/rfc/rfc3655.txt
+++ /dev/null
@@ -1,451 +0,0 @@
-
-
-
-
-
-
-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
deleted file mode 100644
index 88cfb5a..0000000
--- a/doc/rfc/rfc3658.txt
+++ /dev/null
@@ -1,1067 +0,0 @@
-
-
-
-
-
-
-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
deleted file mode 100644
index 31890a4..0000000
--- a/doc/rfc/rfc3757.txt
+++ /dev/null
@@ -1,451 +0,0 @@
-
-
-
-
-
-
-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
deleted file mode 100644
index 8ce4d34..0000000
--- a/doc/rfc/rfc3833.txt
+++ /dev/null
@@ -1,899 +0,0 @@
-
-
-
-
-
-
-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
deleted file mode 100644
index 9887a20..0000000
--- a/doc/rfc/rfc3845.txt
+++ /dev/null
@@ -1,395 +0,0 @@
-
-
-
-
-
-
-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
deleted file mode 100644
index 43b7356..0000000
--- a/doc/rfc/rfc3901.txt
+++ /dev/null
@@ -1,283 +0,0 @@
-
-
-
-
-
-
-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
deleted file mode 100644
index 92e7f40..0000000
--- a/doc/rfc/rfc4025.txt
+++ /dev/null
@@ -1,675 +0,0 @@
-
-
-
-
-
-
-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
deleted file mode 100644
index 7f0a464..0000000
--- a/doc/rfc/rfc4033.txt
+++ /dev/null
@@ -1,1179 +0,0 @@
-
-
-
-
-
-
-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
deleted file mode 100644
index 6a12c6b..0000000
--- a/doc/rfc/rfc4034.txt
+++ /dev/null
@@ -1,1627 +0,0 @@
-
-
-
-
-
-
-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
deleted file mode 100644
index b701cd2..0000000
--- a/doc/rfc/rfc4035.txt
+++ /dev/null
@@ -1,2971 +0,0 @@
-
-
-
-
-
-
-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
deleted file mode 100644
index d9252b3..0000000
--- a/doc/rfc/rfc4074.txt
+++ /dev/null
@@ -1,339 +0,0 @@
-
-
-
-
-
-
-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
deleted file mode 100644
index 1ab4bd1..0000000
--- a/doc/rfc/rfc4159.txt
+++ /dev/null
@@ -1,171 +0,0 @@
-
-
-
-
-
-
-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
deleted file mode 100644
index 17e2c0b..0000000
--- a/doc/rfc/rfc4193.txt
+++ /dev/null
@@ -1,899 +0,0 @@
-
-
-
-
-
-
-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
deleted file mode 100644
index f350b7a..0000000
--- a/doc/rfc/rfc4255.txt
+++ /dev/null
@@ -1,507 +0,0 @@
-
-
-
-
-
-
-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
deleted file mode 100644
index 621420a..0000000
--- a/doc/rfc/rfc4343.txt
+++ /dev/null
@@ -1,563 +0,0 @@
-
-
-
-
-
-
-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
deleted file mode 100644
index f066b64..0000000
--- a/doc/rfc/rfc4367.txt
+++ /dev/null
@@ -1,955 +0,0 @@
-
-
-
-
-
-
-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
deleted file mode 100644
index 6437436..0000000
--- a/doc/rfc/rfc4398.txt
+++ /dev/null
@@ -1,955 +0,0 @@
-
-
-
-
-
-
-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
deleted file mode 100644
index bc1b3f5..0000000
--- a/doc/rfc/rfc4408.txt
+++ /dev/null
@@ -1,2691 +0,0 @@
-
-
-
-
-
-
-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
deleted file mode 100644
index 8b38872..0000000
--- a/doc/rfc/rfc4431.txt
+++ /dev/null
@@ -1,227 +0,0 @@
-
-
-
-
-
-
-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
deleted file mode 100644
index ac12d65..0000000
--- a/doc/rfc/rfc4470.txt
+++ /dev/null
@@ -1,451 +0,0 @@
-
-
-
-
-
-
-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
deleted file mode 100644
index b672df8..0000000
--- a/doc/rfc/rfc4634.txt
+++ /dev/null
@@ -1,6051 +0,0 @@
-
-
-
-
-
-
-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
deleted file mode 100644
index 0a013bc..0000000
--- a/doc/rfc/rfc4641.txt
+++ /dev/null
@@ -1,1963 +0,0 @@
-
-
-
-
-
-
-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/rfc4648.txt b/doc/rfc/rfc4648.txt
deleted file mode 100644
index c7599b4..0000000
--- a/doc/rfc/rfc4648.txt
+++ /dev/null
@@ -1,1011 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                       S. Josefsson
-Request for Comments: 4648                                           SJD
-Obsoletes: 3548                                             October 2006
-Category: Standards Track
-
-
-             The Base16, Base32, and Base64 Data Encodings
-
-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 the commonly used base 64, base 32, and base
-   16 encoding schemes.  It also discusses the use of line-feeds in
-   encoded data, use of padding in encoded data, use of non-alphabet
-   characters in encoded data, use of different encoding alphabets, and
-   canonical encodings.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Josefsson                   Standards Track                     [Page 1]
-
-RFC 4648                    Base-N Encodings                October 2006
-
-
-Table of Contents
-
-   1. Introduction ....................................................3
-   2. Conventions Used in This Document ...............................3
-   3. Implementation Discrepancies ....................................3
-      3.1. Line Feeds in Encoded Data .................................3
-      3.2. Padding of Encoded Data ....................................4
-      3.3. Interpretation of Non-Alphabet Characters in Encoded Data ..4
-      3.4. Choosing the Alphabet ......................................4
-      3.5. Canonical Encoding .........................................5
-   4. Base 64 Encoding ................................................5
-   5. Base 64 Encoding with URL and Filename Safe Alphabet ............7
-   6. Base 32 Encoding ................................................8
-   7. Base 32 Encoding with Extended Hex Alphabet ....................10
-   8. Base 16 Encoding ...............................................10
-   9. Illustrations and Examples .....................................11
-   10. Test Vectors ..................................................12
-   11. ISO C99 Implementation of Base64 ..............................14
-   12. Security Considerations .......................................14
-   13. Changes Since RFC 3548 ........................................15
-   14. Acknowledgements ..............................................15
-   15. Copying Conditions ............................................15
-   16. References ....................................................16
-      16.1. Normative References .....................................16
-      16.2. Informative References ...................................16
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Josefsson                   Standards Track                     [Page 2]
-
-RFC 4648                    Base-N Encodings                October 2006
-
-
-1.  Introduction
-
-   Base encoding of data is used in many situations to store or transfer
-   data in environments that, perhaps for legacy reasons, are restricted
-   to US-ASCII [1] data.  Base encoding can also be used in new
-   applications that do not have legacy restrictions, simply because it
-   makes it possible to manipulate objects with text editors.
-
-   In the past, different applications have had different requirements
-   and thus sometimes implemented base encodings in slightly different
-   ways.  Today, protocol specifications sometimes use base encodings in
-   general, and "base64" in particular, without a precise description or
-   reference.  Multipurpose Internet Mail Extensions (MIME) [4] is often
-   used as a reference for base64 without considering the consequences
-   for line-wrapping or non-alphabet characters.  The purpose of this
-   specification is to establish common alphabet and encoding
-   considerations.  This will hopefully reduce ambiguity in other
-   documents, leading to better interoperability.
-
-2.  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 [2].
-
-3.  Implementation Discrepancies
-
-   Here we discuss the discrepancies between base encoding
-   implementations in the past and, where appropriate, mandate a
-   specific recommended behavior for the future.
-
-3.1.  Line Feeds in Encoded Data
-
-   MIME [4] is often used as a reference for base 64 encoding.  However,
-   MIME does not define "base 64" per se, but rather a "base 64 Content-
-   Transfer-Encoding" for use within MIME.  As such, MIME enforces a
-   limit on line length of base 64-encoded data to 76 characters.  MIME
-   inherits the encoding from Privacy Enhanced Mail (PEM) [3], stating
-   that it is "virtually identical"; however, PEM uses a line length of
-   64 characters.  The MIME and PEM limits are both due to limits within
-   SMTP.
-
-   Implementations MUST NOT add line feeds to base-encoded data unless
-   the specification referring to this document explicitly directs base
-   encoders to add line feeds after a specific number of characters.
-
-
-
-
-
-
-Josefsson                   Standards Track                     [Page 3]
-
-RFC 4648                    Base-N Encodings                October 2006
-
-
-3.2.  Padding of Encoded Data
-
-   In some circumstances, the use of padding ("=") in base-encoded data
-   is not required or used.  In the general case, when assumptions about
-   the size of transported data cannot be made, padding is required to
-   yield correct decoded data.
-
-   Implementations MUST include appropriate pad characters at the end of
-   encoded data unless the specification referring to this document
-   explicitly states otherwise.
-
-   The base64 and base32 alphabets use padding, as described below in
-   sections 4 and 6, but the base16 alphabet does not need it; see
-   section 8.
-
-3.3.  Interpretation of Non-Alphabet Characters in Encoded Data
-
-   Base encodings use a specific, reduced alphabet to encode binary
-   data.  Non-alphabet characters could exist within base-encoded data,
-   caused by data corruption or by design.  Non-alphabet characters may
-   be exploited as a "covert channel", where non-protocol data can be
-   sent for nefarious purposes.  Non-alphabet characters might also be
-   sent in order to exploit implementation errors leading to, e.g.,
-   buffer overflow attacks.
-
-   Implementations MUST reject the encoded data if it contains
-   characters outside the base alphabet when interpreting base-encoded
-   data, unless the specification referring to this document explicitly
-   states otherwise.  Such specifications may instead state, as MIME
-   does, that characters outside the base encoding alphabet should
-   simply be ignored when interpreting data ("be liberal in what you
-   accept").  Note that this means that any adjacent carriage return/
-   line feed (CRLF) characters constitute "non-alphabet characters" and
-   are ignored.  Furthermore, such specifications MAY ignore the pad
-   character, "=", treating it as non-alphabet data, if it is present
-   before the end of the encoded data.  If more than the allowed number
-   of pad characters is found at the end of the string (e.g., a base 64
-   string terminated with "==="), the excess pad characters MAY also be
-   ignored.
-
-3.4.  Choosing the Alphabet
-
-   Different applications have different requirements on the characters
-   in the alphabet.  Here are a few requirements that determine which
-   alphabet should be used:
-
-
-
-
-
-
-Josefsson                   Standards Track                     [Page 4]
-
-RFC 4648                    Base-N Encodings                October 2006
-
-
-   o  Handled by humans.  The characters "0" and "O" are easily
-      confused, as are "1", "l", and "I".  In the base32 alphabet below,
-      where 0 (zero) and 1 (one) are not present, a decoder may
-      interpret 0 as O, and 1 as I or L depending on case.  (However, by
-      default it should not; see previous section.)
-
-   o  Encoded into structures that mandate other requirements.  For base
-      16 and base 32, this determines the use of upper- or lowercase
-      alphabets.  For base 64, the non-alphanumeric characters (in
-      particular, "/") may be problematic in file names and URLs.
-
-   o  Used as identifiers.  Certain characters, notably "+" and "/" in
-      the base 64 alphabet, are treated as word-breaks by legacy text
-      search/index tools.
-
-   There is no universally accepted alphabet that fulfills all the
-   requirements.  For an example of a highly specialized variant, see
-   IMAP [8].  In this document, we document and name some currently used
-   alphabets.
-
-3.5.  Canonical Encoding
-
-   The padding step in base 64 and base 32 encoding can, if improperly
-   implemented, lead to non-significant alterations of the encoded data.
-   For example, if the input is only one octet for a base 64 encoding,
-   then all six bits of the first symbol are used, but only the first
-   two bits of the next symbol are used.  These pad bits MUST be set to
-   zero by conforming encoders, which is described in the descriptions
-   on padding below.  If this property do not hold, there is no
-   canonical representation of base-encoded data, and multiple base-
-   encoded strings can be decoded to the same binary data.  If this
-   property (and others discussed in this document) holds, a canonical
-   encoding is guaranteed.
-
-   In some environments, the alteration is critical and therefore
-   decoders MAY chose to reject an encoding if the pad bits have not
-   been set to zero.  The specification referring to this may mandate a
-   specific behaviour.
-
-4.  Base 64 Encoding
-
-   The following description of base 64 is derived from [3], [4], [5],
-   and [6].  This encoding may be referred to as "base64".
-
-   The Base 64 encoding is designed to represent arbitrary sequences of
-   octets in a form that allows the use of both upper- and lowercase
-   letters but that need not be human readable.
-
-
-
-
-Josefsson                   Standards Track                     [Page 5]
-
-RFC 4648                    Base-N Encodings                October 2006
-
-
-   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 character 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, bits with value zero 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 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.
-
-
-
-Josefsson                   Standards Track                     [Page 6]
-
-RFC 4648                    Base-N Encodings                October 2006
-
-
-   (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.
-
-   (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.
-
-5.  Base 64 Encoding with URL and Filename Safe Alphabet
-
-   The Base 64 encoding with an URL and filename safe alphabet has been
-   used in [12].
-
-   An alternative alphabet has been suggested that would use "~" as the
-   63rd character.  Since the "~" character has special meaning in some
-   file system environments, the encoding described in this section is
-   recommended instead.  The remaining unreserved URI character is ".",
-   but some file system environments do not permit multiple "." in a
-   filename, thus making the "." character unattractive as well.
-
-   The pad character "=" is typically percent-encoded when used in an
-   URI [9], but if the data length is known implicitly, this can be
-   avoided by skipping the padding; see section 3.2.
-
-   This encoding may be referred to as "base64url".  This encoding
-   should not be regarded as the same as the "base64" encoding and
-   should not be referred to as only "base64".  Unless clarified
-   otherwise, "base64" refers to the base 64 in the previous section.
-
-   This encoding is technically identical to the previous one, except
-   for the 62:nd and 63:rd alphabet character, as indicated in Table 2.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Josefsson                   Standards Track                     [Page 7]
-
-RFC 4648                    Base-N Encodings                October 2006
-
-
-         Table 2: The "URL and Filename safe" 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 - (minus)
-        12 M            29 d            46 u            63 _
-        13 N            30 e            47 v           (underline)
-        14 O            31 f            48 w
-        15 P            32 g            49 x
-        16 Q            33 h            50 y         (pad) =
-
-6.  Base 32 Encoding
-
-   The following description of base 32 is derived from [11] (with
-   corrections).  This encoding may be referred to as "base32".
-
-   The Base 32 encoding is designed to represent arbitrary sequences of
-   octets in a form that needs to be case insensitive but that need not
-   be human readable.
-
-   A 33-character subset of US-ASCII is used, enabling 5 bits to be
-   represented per printable character.  (The extra 33rd character, "=",
-   is used to signify a special processing function.)
-
-   The encoding process represents 40-bit groups of input bits as output
-   strings of 8 encoded characters.  Proceeding from left to right, a
-   40-bit input group is formed by concatenating 5 8bit input groups.
-   These 40 bits are then treated as 8 concatenated 5-bit groups, each
-   of which is translated into a single character in the base 32
-   alphabet.  When a bit stream is encoded via the base 32 encoding, the
-   bit stream must be presumed to be ordered with the most-significant-
-   bit first.  That is, the first bit in the stream will be the high-
-   order bit in the first 8bit byte, the eighth bit will be the low-
-   order bit in the first 8bit byte, and so on.
-
-
-
-
-
-
-
-Josefsson                   Standards Track                     [Page 8]
-
-RFC 4648                    Base-N Encodings                October 2006
-
-
-   Each 5-bit group is used as an index into an array of 32 printable
-   characters.  The character referenced by the index is placed in the
-   output string.  These characters, identified in Table 3, below, are
-   selected from US-ASCII digits and uppercase letters.
-
-                     Table 3: The Base 32 Alphabet
-
-     Value Encoding  Value Encoding  Value Encoding  Value Encoding
-         0 A             9 J            18 S            27 3
-         1 B            10 K            19 T            28 4
-         2 C            11 L            20 U            29 5
-         3 D            12 M            21 V            30 6
-         4 E            13 N            22 W            31 7
-         5 F            14 O            23 X
-         6 G            15 P            24 Y         (pad) =
-         7 H            16 Q            25 Z
-         8 I            17 R            26 2
-
-   Special processing is performed if fewer than 40 bits are available
-   at the end of the data being encoded.  A full encoding quantum is
-   always completed at the end of a body.  When fewer than 40 input bits
-   are available in an input group, bits with value zero are added (on
-   the right) to form an integral number of 5-bit groups.  Padding at
-   the end of the data is performed using the "=" character.  Since all
-   base 32 input is an integral number of octets, only the following
-   cases can arise:
-
-   (1) The final quantum of encoding input is an integral multiple of 40
-       bits; here, the final unit of encoded output will be an integral
-       multiple of 8 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
-       six "=" padding characters.
-
-   (3) The final quantum of encoding input is exactly 16 bits; here, the
-       final unit of encoded output will be four characters followed by
-       four "=" padding characters.
-
-   (4) The final quantum of encoding input is exactly 24 bits; here, the
-       final unit of encoded output will be five characters followed by
-       three "=" padding characters.
-
-   (5) The final quantum of encoding input is exactly 32 bits; here, the
-       final unit of encoded output will be seven characters followed by
-       one "=" padding character.
-
-
-
-
-
-Josefsson                   Standards Track                     [Page 9]
-
-RFC 4648                    Base-N Encodings                October 2006
-
-
-7.  Base 32 Encoding with Extended Hex Alphabet
-
-   The following description of base 32 is derived from [7].  This
-   encoding may be referred to as "base32hex".  This encoding should not
-   be regarded as the same as the "base32" encoding and should not be
-   referred to as only "base32".  This encoding is used by, e.g.,
-   NextSECure3 (NSEC3) [10].
-
-   One property with this alphabet, which the base64 and base32
-   alphabets lack, is that encoded data maintains its sort order when
-   the encoded data is compared bit-wise.
-
-   This encoding is identical to the previous one, except for the
-   alphabet.  The new alphabet is found in Table 4.
-
-                 Table 4: The "Extended Hex" Base 32 Alphabet
-
-         Value Encoding  Value Encoding  Value Encoding  Value Encoding
-             0 0             9 9            18 I            27 R
-             1 1            10 A            19 J            28 S
-             2 2            11 B            20 K            29 T
-             3 3            12 C            21 L            30 U
-             4 4            13 D            22 M            31 V
-             5 5            14 E            23 N
-             6 6            15 F            24 O         (pad) =
-             7 7            16 G            25 P
-             8 8            17 H            26 Q
-
-8.  Base 16 Encoding
-
-   The following description is original but analogous to previous
-   descriptions.  Essentially, Base 16 encoding is the standard case-
-   insensitive hex encoding and may be referred to as "base16" or "hex".
-
-   A 16-character subset of US-ASCII is used, enabling 4 bits to be
-   represented per printable character.
-
-   The encoding process represents 8-bit groups (octets) of input bits
-   as output strings of 2 encoded characters.  Proceeding from left to
-   right, an 8-bit input is taken from the input data.  These 8 bits are
-   then treated as 2 concatenated 4-bit groups, each of which is
-   translated into a single character in the base 16 alphabet.
-
-   Each 4-bit group is used as an index into an array of 16 printable
-   characters.  The character referenced by the index is placed in the
-   output string.
-
-
-
-
-
-Josefsson                   Standards Track                    [Page 10]
-
-RFC 4648                    Base-N Encodings                October 2006
-
-
-                         Table 5: The Base 16 Alphabet
-
-         Value Encoding  Value Encoding  Value Encoding  Value Encoding
-             0 0             4 4             8 8            12 C
-             1 1             5 5             9 9            13 D
-             2 2             6 6            10 A            14 E
-             3 3             7 7            11 B            15 F
-
-   Unlike base 32 and base 64, no special padding is necessary since a
-   full code word is always available.
-
-9.  Illustrations and Examples
-
-   To translate between binary and a base encoding, the input is stored
-   in a structure, and the output is extracted.  The case for base 64 is
-   displayed in the following figure, borrowed from [5].
-
-            +--first octet--+-second octet--+--third octet--+
-            |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|
-            +-----------+---+-------+-------+---+-----------+
-            |5 4 3 2 1 0|5 4 3 2 1 0|5 4 3 2 1 0|5 4 3 2 1 0|
-            +--1.index--+--2.index--+--3.index--+--4.index--+
-
-   The case for base 32 is shown in the following figure, borrowed from
-   [7].  Each successive character in a base-32 value represents 5
-   successive bits of the underlying octet sequence.  Thus, each group
-   of 8 characters represents a sequence of 5 octets (40 bits).
-
-                        1          2          3
-             01234567 89012345 67890123 45678901 23456789
-            +--------+--------+--------+--------+--------+
-            |< 1 >< 2| >< 3 ><|.4 >< 5.|>< 6 ><.|7 >< 8 >|
-            +--------+--------+--------+--------+--------+
-                                                    <===> 8th character
-                                              <====> 7th character
-                                         <===> 6th character
-                                   <====> 5th character
-                             <====> 4th character
-                        <===> 3rd character
-                  <====> 2nd character
-             <===> 1st character
-
-
-
-
-
-
-
-
-
-
-Josefsson                   Standards Track                    [Page 11]
-
-RFC 4648                    Base-N Encodings                October 2006
-
-
-   The following example of Base64 data is from [5], with corrections.
-
-      Input data:  0x14fb9c03d97e
-      Hex:     1   4    f   b    9   c     | 0   3    d   9    7   e
-      8-bit:   00010100 11111011 10011100  | 00000011 11011001 01111110
-      6-bit:   000101 001111 101110 011100 | 000000 111101 100101 111110
-      Decimal: 5      15     46     28       0      61     37     62
-      Output:  F      P      u      c        A      9      l      +
-
-      Input data:  0x14fb9c03d9
-      Hex:     1   4    f   b    9   c     | 0   3    d   9
-      8-bit:   00010100 11111011 10011100  | 00000011 11011001
-                                                      pad with 00
-      6-bit:   000101 001111 101110 011100 | 000000 111101 100100
-      Decimal: 5      15     46     28       0      61     36
-                                                         pad with =
-      Output:  F      P      u      c        A      9      k      =
-
-      Input data:  0x14fb9c03
-      Hex:     1   4    f   b    9   c     | 0   3
-      8-bit:   00010100 11111011 10011100  | 00000011
-                                             pad with 0000
-      6-bit:   000101 001111 101110 011100 | 000000 110000
-      Decimal: 5      15     46     28       0      48
-                                                  pad with =      =
-      Output:  F      P      u      c        A      w      =      =
-
-10.  Test Vectors
-
-   BASE64("") = ""
-
-   BASE64("f") = "Zg=="
-
-   BASE64("fo") = "Zm8="
-
-   BASE64("foo") = "Zm9v"
-
-   BASE64("foob") = "Zm9vYg=="
-
-   BASE64("fooba") = "Zm9vYmE="
-
-   BASE64("foobar") = "Zm9vYmFy"
-
-   BASE32("") = ""
-
-   BASE32("f") = "MY======"
-
-   BASE32("fo") = "MZXQ===="
-
-
-
-Josefsson                   Standards Track                    [Page 12]
-
-RFC 4648                    Base-N Encodings                October 2006
-
-
-   BASE32("foo") = "MZXW6==="
-
-   BASE32("foob") = "MZXW6YQ="
-
-   BASE32("fooba") = "MZXW6YTB"
-
-   BASE32("foobar") = "MZXW6YTBOI======"
-
-   BASE32-HEX("") = ""
-
-   BASE32-HEX("f") = "CO======"
-
-   BASE32-HEX("fo") = "CPNG===="
-
-   BASE32-HEX("foo") = "CPNMU==="
-
-   BASE32-HEX("foob") = "CPNMUOG="
-
-   BASE32-HEX("fooba") = "CPNMUOJ1"
-
-   BASE32-HEX("foobar") = "CPNMUOJ1E8======"
-
-   BASE16("") = ""
-
-   BASE16("f") = "66"
-
-   BASE16("fo") = "666F"
-
-   BASE16("foo") = "666F6F"
-
-   BASE16("foob") = "666F6F62"
-
-   BASE16("fooba") = "666F6F6261"
-
-   BASE16("foobar") = "666F6F626172"
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Josefsson                   Standards Track                    [Page 13]
-
-RFC 4648                    Base-N Encodings                October 2006
-
-
-11.  ISO C99 Implementation of Base64
-
-   An ISO C99 implementation of Base64 encoding and decoding that is
-   believed to follow all recommendations in this RFC is available from:
-
-      http://josefsson.org/base-encoding/
-
-   This code is not normative.
-
-   The code could not be included in this RFC for procedural reasons
-   (RFC 3978 section 5.4).
-
-12.  Security Considerations
-
-   When base encoding and decoding is implemented, care should be taken
-   not to introduce vulnerabilities to buffer overflow attacks, or other
-   attacks on the implementation.  A decoder should not break on invalid
-   input including, e.g., embedded NUL characters (ASCII 0).
-
-   If non-alphabet characters are ignored, instead of causing rejection
-   of the entire encoding (as recommended), a covert channel that can be
-   used to "leak" information is made possible.  The ignored characters
-   could also be used for other nefarious purposes, such as to avoid a
-   string equality comparison or to trigger implementation bugs.  The
-   implications of ignoring non-alphabet characters should be understood
-   in applications that do not follow the recommended practice.
-   Similarly, when the base 16 and base 32 alphabets are handled case
-   insensitively, alteration of case can be used to leak information or
-   make string equality comparisons fail.
-
-   When padding is used, there are some non-significant bits that
-   warrant security concerns, as they may be abused to leak information
-   or used to bypass string equality comparisons or to trigger
-   implementation problems.
-
-   Base encoding visually hides otherwise easily recognized information,
-   such as passwords, but does not provide any computational
-   confidentiality.  This has been known to cause security incidents
-   when, e.g., a user reports details of a network protocol exchange
-   (perhaps to illustrate some other problem) and accidentally reveals
-   the password because she is unaware that the base encoding does not
-   protect the password.
-
-   Base encoding adds no entropy to the plaintext, but it does increase
-   the amount of plaintext available and provide a signature for
-   cryptanalysis in the form of a characteristic probability
-   distribution.
-
-
-
-
-Josefsson                   Standards Track                    [Page 14]
-
-RFC 4648                    Base-N Encodings                October 2006
-
-
-13.  Changes Since RFC 3548
-
-   Added the "base32 extended hex alphabet", needed to preserve sort
-   order of encoded data.
-
-   Referenced IMAP for the special Base64 encoding used there.
-
-   Fixed the example copied from RFC 2440.
-
-   Added security consideration about providing a signature for
-   cryptoanalysis.
-
-   Added test vectors.
-
-   Fixed typos.
-
-14.  Acknowledgements
-
-   Several people offered comments and/or suggestions, including John E.
-   Hadstate, Tony Hansen, Gordon Mohr, John Myers, Chris Newman, and
-   Andrew Sieber.  Text used in this document are based on earlier RFCs
-   describing specific uses of various base encodings.  The author
-   acknowledges the RSA Laboratories for supporting the work that led to
-   this document.
-
-   This revised version is based in parts on comments and/or suggestions
-   made by Roy Arends, Eric Blake, Brian E Carpenter, Elwyn Davies, Bill
-   Fenner, Sam Hartman, Ted Hardie, Per Hygum, Jelte Jansen, Clement
-   Kent, Tero Kivinen, Paul Kwiatkowski, and Ben Laurie.
-
-15.  Copying Conditions
-
-   Copyright (c) 2000-2006 Simon Josefsson
-
-   Regarding the abstract and sections 1, 3, 8, 10, 12, 13, and 14 of
-   this document, that were 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 and do not falsely purport to be IETF RFC documents.
-   Derivative works need not be licensed under similar terms.
-
-
-
-
-
-
-
-Josefsson                   Standards Track                    [Page 15]
-
-RFC 4648                    Base-N Encodings                October 2006
-
-
-16.  References
-
-16.1.  Normative References
-
-   [1]   Cerf, V., "ASCII format for network interchange", RFC 20,
-         October 1969.
-
-   [2]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
-         Levels", BCP 14, RFC 2119, March 1997.
-
-16.2.  Informative References
-
-   [3]   Linn, J., "Privacy Enhancement for Internet Electronic Mail:
-         Part I: Message Encryption and Authentication Procedures", RFC
-         1421, February 1993.
-
-   [4]   Freed, N. and N. Borenstein, "Multipurpose Internet Mail
-         Extensions (MIME) Part One: Format of Internet Message Bodies",
-         RFC 2045, November 1996.
-
-   [5]   Callas, J., Donnerhacke, L., Finney, H., and R. Thayer,
-         "OpenPGP Message Format", RFC 2440, November 1998.
-
-   [6]   Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-         "DNS Security Introduction and Requirements", RFC 4033, March
-         2005.
-
-   [7]   Klyne, G. and L. Masinter, "Identifying Composite Media
-         Features", RFC 2938, September 2000.
-
-   [8]   Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
-         4rev1", RFC 3501, March 2003.
-
-   [9]   Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
-         Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986,
-         January 2005.
-
-   [10]  Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNSSEC Hash
-         Authenticated Denial of Existence", Work in Progress, June
-         2006.
-
-   [11]  Myers, J., "SASL GSSAPI mechanisms", Work in Progress, May
-         2000.
-
-   [12]  Wilcox-O'Hearn, B., "Post to P2P-hackers mailing list",
-         http://zgp.org/pipermail/p2p-hackers/2001-September/
-         000315.html, September 2001.
-
-
-
-
-Josefsson                   Standards Track                    [Page 16]
-
-RFC 4648                    Base-N Encodings                October 2006
-
-
-Author's Address
-
-   Simon Josefsson
-   SJD
-   EMail: simon@josefsson.org
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Josefsson                   Standards Track                    [Page 17]
-
-RFC 4648                    Base-N Encodings                October 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 18]
-
diff --git a/doc/rfc/rfc4701.txt b/doc/rfc/rfc4701.txt
deleted file mode 100644
index 03e3c54..0000000
--- a/doc/rfc/rfc4701.txt
+++ /dev/null
@@ -1,675 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                           M. Stapp
-Request for Comments: 4701                           Cisco Systems, Inc.
-Category: Standards Track                                       T. Lemon
-                                                           Nominum, Inc.
-                                                           A. Gustafsson
-                                          Araneus Information Systems Oy
-                                                            October 2006
-
-
-                A DNS Resource Record (RR) for Encoding
-   Dynamic Host Configuration Protocol (DHCP) Information (DHCID 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 (2006).
-
-Abstract
-
-   It is possible for Dynamic Host Configuration Protocol (DHCP) clients
-   to attempt to update the same DNS Fully Qualified Domain Name (FQDN)
-   or 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, RFC 4703 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 Resource
-   Record (RR) type for this purpose for use by DHCP clients and
-   servers:  the "DHCID" RR.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Stapp, et al.               Standards Track                     [Page 1]
-
-RFC 4701                      The DHCID RR                  October 2006
-
-
-Table of Contents
-
-   1. Introduction ....................................................3
-   2. Terminology .....................................................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 ..................6
-           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 ...........................................7
-           3.6.3. Example 3 ...........................................7
-   4. Use of the DHCID RR .............................................8
-   5. Updater Behavior ................................................8
-   6. Security Considerations .........................................8
-   7. IANA Considerations .............................................9
-   8. Acknowledgements ................................................9
-   9. References ......................................................9
-      9.1. Normative References .......................................9
-      9.2. Informative References ....................................10
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Stapp, et al.               Standards Track                     [Page 2]
-
-RFC 4701                      The DHCID RR                  October 2006
-
-
-1.  Introduction
-
-   A set of procedures to allow DHCP [7] [11] clients and servers to
-   automatically update the DNS ([3], [4]) is proposed in [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, [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.
-
-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 [2].
-
-3.  The DHCID RR
-
-   The DHCID RR is defined with mnemonic DHCID and type code 49.  The
-   DHCID RR is only defined in the IN class.  DHCID RRs cause no
-   additional section processing.
-
-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
-   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,
-
-
-
-Stapp, et al.               Standards Track                     [Page 3]
-
-RFC 4701                      The DHCID RR                  October 2006
-
-
-   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 [8], Section 3.  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 and that type's identifier is:
-
-
-   +------------------+------------------------------------------------+
-   |  Identifier Type | Identifier                                     |
-   |       Code       |                                                |
-   +------------------+------------------------------------------------+
-   |      0x0000      | The 1-octet 'htype' followed by 'hlen' octets  |
-   |                  | of 'chaddr' from a DHCPv4 client's DHCPREQUEST |
-   |                  | [7].                                           |
-   |      0x0001      | The data octets (i.e., the Type and            |
-   |                  | Client-Identifier fields) from a DHCPv4        |
-   |                  | client's Client Identifier option [10].        |
-   |      0x0002      | The client's DUID (i.e., the data octets of a  |
-   |                  | DHCPv6 client's Client Identifier option [11]  |
-   |                  | or the DUID field from a DHCPv4 client's       |
-   |                  | Client Identifier option [6]).                 |
-   |  0x0003 - 0xfffe | Undefined; available to be assigned by IANA.   |
-   |      0xffff      | Undefined; 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.
-
-
-
-Stapp, et al.               Standards Track                     [Page 4]
-
-RFC 4701                      The DHCID RR                  October 2006
-
-
-   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.  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 the canonical wire format as
-   described in [9], Section 6.2.  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 [6].  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 [6]), 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.
-
-
-
-
-
-
-
-Stapp, et al.               Standards Track                     [Page 5]
-
-RFC 4701                      The DHCID RR                  October 2006
-
-
-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
-   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 allocates the IPv6 address 2001:DB8::1234:5678 to a
-   client that 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    2001:DB8::1234:5678
-     chi6.example.com.     DHCID   ( AAIBY2/AuCccgoJbsaxcQc9TUapptP69l
-                                     OjxfNuVAA2kjEA= )
-
-   If the DHCID RR type is not supported, the RDATA would be encoded
-   [13] as:
-
-
-
-Stapp, et al.               Standards Track                     [Page 6]
-
-RFC 4701                      The DHCID RR                  October 2006
-
-
-     \# 35 ( 000201636fc0b8271c82825bb1ac5c41cf5351aa69b4febd94e8f17cd
-             b95000da48c40 )
-
-3.6.2.  Example 2
-
-   A DHCP server allocates the IPv4 address 192.0.2.2 to a client that
-   included the DHCP client-identifier option data 01:07:08:09:0a:0b:0c
-   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       192.0.2.2
-     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 allocating the IPv4 address 192.0.2.3 to a client with
-   the 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
-   1-octet 'htype' value for Ethernet, 0x01, followed by the six octets
-   of the Ethernet MAC address, and the domain name (represented as
-   specified in Section 3.5).
-
-     client.example.com.   A       192.0.2.3
-     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 )
-
-
-
-
-
-Stapp, et al.               Standards Track                     [Page 7]
-
-RFC 4701                      The DHCID RR                  October 2006
-
-
-4.  Use of the DHCID RR
-
-   This RR MUST NOT be used for any purpose other than that detailed in
-   [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.  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.  Further, 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., [12]) when performing DNS updates.
-
-
-
-Stapp, et al.               Standards Track                     [Page 8]
-
-RFC 4701                      The DHCID RR                  October 2006
-
-
-7.  IANA Considerations
-
-   IANA has allocated 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 has
-   established 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 [5].
-
-   This specification defines a new number-space for the 1-octet digest
-   type codes associated with the DHCID RR.  IANA has established 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 [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 Fully Qualified Domain
-        Name (FQDN) Conflicts among Dynamic Host Configuration Protocol
-        (DHCP) Clients", RFC 4703, October 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.
-
-   [6]  Lemon, T. and B. Sommerfeld, "Node-specific Client Identifiers
-        for Dynamic Host Configuration Protocol Version Four (DHCPv4)",
-        RFC 4361, February 2006.
-
-
-
-
-
-Stapp, et al.               Standards Track                     [Page 9]
-
-RFC 4701                      The DHCID RR                  October 2006
-
-
-9.2.  Informative References
-
-   [7]   Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
-         March 1997.
-
-   [8]   Josefsson, S., "The Base16, Base32, and Base64 Data Encodings",
-         RFC 3548, July 2003.
-
-   [9]   Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
-         "Resource Records for the DNS Security Extensions", RFC 4034,
-         March 2005.
-
-   [10]  Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
-         Extensions", RFC 2132, March 1997.
-
-   [11]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M.
-         Carney, "Dynamic Host Configuration Protocol for IPv6
-         (DHCPv6)", RFC 3315, July 2003.
-
-   [12]  Vixie, P., Gudmundsson, O., Eastlake, D., and B. Wellington,
-         "Secret Key Transaction Authentication for DNS (TSIG)",
-         RFC 2845, May 2000.
-
-   [13]  Gustafsson, A., "Handling of Unknown DNS Resource Record (RR)
-         Types", RFC 3597, September 2003.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Stapp, et al.               Standards Track                    [Page 10]
-
-RFC 4701                      The DHCID RR                  October 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.               Standards Track                    [Page 11]
-
-RFC 4701                      The DHCID RR                  October 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).
-
-
-
-
-
-
-
-Stapp, et al.               Standards Track                    [Page 12]
-
diff --git a/doc/rfc/rfc5155.txt b/doc/rfc/rfc5155.txt
deleted file mode 100644
index d4b7297..0000000
--- a/doc/rfc/rfc5155.txt
+++ /dev/null
@@ -1,2915 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                          B. Laurie
-Request for Comments: 5155                                     G. Sisson
-Category: Standards Track                                      R. Arends
-                                                                 Nominet
-                                                               D. Blacka
-                                                          VeriSign, Inc.
-                                                              March 2008
-
-
-     DNS Security (DNSSEC) Hashed Authenticated Denial of Existence
-
-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 Security (DNSSEC) Extensions introduced the
-   NSEC resource record (RR) for authenticated denial of existence.
-   This document introduces an alternative resource record, NSEC3, which
-   similarly provides authenticated denial of existence.  However, it
-   also provides measures against zone enumeration and permits gradual
-   expansion of delegation-centric zones.
-
-Table of Contents
-
-   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
-     1.1.  Rationale  . . . . . . . . . . . . . . . . . . . . . . . .  4
-     1.2.  Requirements . . . . . . . . . . . . . . . . . . . . . . .  4
-     1.3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  5
-   2.  Backwards Compatibility  . . . . . . . . . . . . . . . . . . .  6
-   3.  The NSEC3 Resource Record  . . . . . . . . . . . . . . . . . .  7
-     3.1.  RDATA Fields . . . . . . . . . . . . . . . . . . . . . . .  8
-       3.1.1.  Hash Algorithm . . . . . . . . . . . . . . . . . . . .  8
-       3.1.2.  Flags  . . . . . . . . . . . . . . . . . . . . . . . .  8
-       3.1.3.  Iterations . . . . . . . . . . . . . . . . . . . . . .  8
-       3.1.4.  Salt Length  . . . . . . . . . . . . . . . . . . . . .  8
-       3.1.5.  Salt . . . . . . . . . . . . . . . . . . . . . . . . .  8
-       3.1.6.  Hash Length  . . . . . . . . . . . . . . . . . . . . .  9
-       3.1.7.  Next Hashed Owner Name . . . . . . . . . . . . . . . .  9
-       3.1.8.  Type Bit Maps  . . . . . . . . . . . . . . . . . . . .  9
-     3.2.  NSEC3 RDATA Wire Format  . . . . . . . . . . . . . . . . .  9
-       3.2.1.  Type Bit Maps Encoding . . . . . . . . . . . . . . . . 10
-     3.3.  Presentation Format  . . . . . . . . . . . . . . . . . . . 11
-
-
-
-Laurie, et al.              Standards Track                     [Page 1]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-   4.  The NSEC3PARAM Resource Record . . . . . . . . . . . . . . . . 12
-     4.1.  RDATA Fields . . . . . . . . . . . . . . . . . . . . . . . 12
-       4.1.1.  Hash Algorithm . . . . . . . . . . . . . . . . . . . . 12
-       4.1.2.  Flag Fields  . . . . . . . . . . . . . . . . . . . . . 12
-       4.1.3.  Iterations . . . . . . . . . . . . . . . . . . . . . . 13
-       4.1.4.  Salt Length  . . . . . . . . . . . . . . . . . . . . . 13
-       4.1.5.  Salt . . . . . . . . . . . . . . . . . . . . . . . . . 13
-     4.2.  NSEC3PARAM RDATA Wire Format . . . . . . . . . . . . . . . 13
-     4.3.  Presentation Format  . . . . . . . . . . . . . . . . . . . 14
-   5.  Calculation of the Hash  . . . . . . . . . . . . . . . . . . . 14
-   6.  Opt-Out  . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
-   7.  Authoritative Server Considerations  . . . . . . . . . . . . . 16
-     7.1.  Zone Signing . . . . . . . . . . . . . . . . . . . . . . . 16
-     7.2.  Zone Serving . . . . . . . . . . . . . . . . . . . . . . . 17
-       7.2.1.  Closest Encloser Proof . . . . . . . . . . . . . . . . 18
-       7.2.2.  Name Error Responses . . . . . . . . . . . . . . . . . 19
-       7.2.3.  No Data Responses, QTYPE is not DS . . . . . . . . . . 19
-       7.2.4.  No Data Responses, QTYPE is DS . . . . . . . . . . . . 19
-       7.2.5.  Wildcard No Data Responses . . . . . . . . . . . . . . 19
-       7.2.6.  Wildcard Answer Responses  . . . . . . . . . . . . . . 20
-       7.2.7.  Referrals to Unsigned Subzones . . . . . . . . . . . . 20
-       7.2.8.  Responding to Queries for NSEC3 Owner Names  . . . . . 20
-       7.2.9.  Server Response to a Run-Time Collision  . . . . . . . 21
-     7.3.  Secondary Servers  . . . . . . . . . . . . . . . . . . . . 21
-     7.4.  Zones Using Unknown Hash Algorithms  . . . . . . . . . . . 21
-     7.5.  Dynamic Update . . . . . . . . . . . . . . . . . . . . . . 21
-   8.  Validator Considerations . . . . . . . . . . . . . . . . . . . 23
-     8.1.  Responses with Unknown Hash Types  . . . . . . . . . . . . 23
-     8.2.  Verifying NSEC3 RRs  . . . . . . . . . . . . . . . . . . . 23
-     8.3.  Closest Encloser Proof . . . . . . . . . . . . . . . . . . 23
-     8.4.  Validating Name Error Responses  . . . . . . . . . . . . . 24
-     8.5.  Validating No Data Responses, QTYPE is not DS  . . . . . . 24
-     8.6.  Validating No Data Responses, QTYPE is DS  . . . . . . . . 24
-     8.7.  Validating Wildcard No Data Responses  . . . . . . . . . . 25
-     8.8.  Validating Wildcard Answer Responses . . . . . . . . . . . 25
-     8.9.  Validating Referrals to Unsigned Subzones  . . . . . . . . 25
-   9.  Resolver Considerations  . . . . . . . . . . . . . . . . . . . 26
-     9.1.  NSEC3 Resource Record Caching  . . . . . . . . . . . . . . 26
-     9.2.  Use of the AD Bit  . . . . . . . . . . . . . . . . . . . . 26
-   10. Special Considerations . . . . . . . . . . . . . . . . . . . . 26
-     10.1. Domain Name Length Restrictions  . . . . . . . . . . . . . 26
-     10.2. DNAME at the Zone Apex . . . . . . . . . . . . . . . . . . 27
-     10.3. Iterations . . . . . . . . . . . . . . . . . . . . . . . . 27
-     10.4. Transitioning a Signed Zone from NSEC to NSEC3 . . . . . . 28
-     10.5. Transitioning a Signed Zone from NSEC3 to NSEC . . . . . . 28
-   11. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 29
-   12. Security Considerations  . . . . . . . . . . . . . . . . . . . 30
-     12.1. Hashing Considerations . . . . . . . . . . . . . . . . . . 30
-
-
-
-Laurie, et al.              Standards Track                     [Page 2]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-       12.1.1. Dictionary Attacks . . . . . . . . . . . . . . . . . . 30
-       12.1.2. Collisions . . . . . . . . . . . . . . . . . . . . . . 31
-       12.1.3. Transitioning to a New Hash Algorithm  . . . . . . . . 31
-       12.1.4. Using High Iteration Values  . . . . . . . . . . . . . 31
-     12.2. Opt-Out Considerations . . . . . . . . . . . . . . . . . . 32
-     12.3. Other Considerations . . . . . . . . . . . . . . . . . . . 33
-   13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
-     13.1. Normative References . . . . . . . . . . . . . . . . . . . 33
-     13.2. Informative References . . . . . . . . . . . . . . . . . . 34
-   Appendix A.  Example Zone  . . . . . . . . . . . . . . . . . . . . 35
-   Appendix B.  Example Responses . . . . . . . . . . . . . . . . . . 40
-     B.1.  Name Error . . . . . . . . . . . . . . . . . . . . . . . . 40
-     B.2.  No Data Error  . . . . . . . . . . . . . . . . . . . . . . 42
-       B.2.1.  No Data Error, Empty Non-Terminal  . . . . . . . . . . 43
-     B.3.  Referral to an Opt-Out Unsigned Zone . . . . . . . . . . . 44
-     B.4.  Wildcard Expansion . . . . . . . . . . . . . . . . . . . . 45
-     B.5.  Wildcard No Data Error . . . . . . . . . . . . . . . . . . 46
-     B.6.  DS Child Zone No Data Error  . . . . . . . . . . . . . . . 48
-   Appendix C.  Special Considerations  . . . . . . . . . . . . . . . 48
-     C.1.  Salting  . . . . . . . . . . . . . . . . . . . . . . . . . 49
-     C.2.  Hash Collision . . . . . . . . . . . . . . . . . . . . . . 49
-       C.2.1.  Avoiding Hash Collisions During Generation . . . . . . 50
-       C.2.2.  Second Preimage Requirement Analysis . . . . . . . . . 50
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Laurie, et al.              Standards Track                     [Page 3]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-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 introduces a
-   side-effect in that the contents of a zone can be enumerated.  This
-   property introduces undesired policy issues.
-
-   The enumeration is enabled by the set of NSEC records that exists
-   inside a signed zone.  An NSEC record lists two names that are
-   ordered canonically, in order to show that nothing exists between the
-   two names.  The complete set of NSEC records lists all the names in a
-   zone.  It is trivial to enumerate the content of a zone by querying
-   for names that do not exist.
-
-   An enumerated zone can be used, for example, as a source of probable
-   e-mail addresses for spam, or as a key for multiple WHOIS queries to
-   reveal registrant data that many registries may have legal
-   obligations to protect.  Many registries therefore prohibit the
-   copying of their zone data; however, the use of NSEC RRs renders
-   these policies unenforceable.
-
-   A second problem is that the cost to cryptographically secure
-   delegations to unsigned zones is high, relative to the perceived
-   security benefit, in two cases: large, delegation-centric zones, and
-   zones where insecure delegations will be updated rapidly.  In these
-   cases, the costs of maintaining the NSEC RR chain may be extremely
-   high and use of the "Opt-Out" convention may be more appropriate (for
-   these unsecured zones).
-
-   This document presents the NSEC3 Resource Record which can be used as
-   an alternative to NSEC to mitigate these issues.
-
-   Earlier work to address these issues include [DNSEXT-NO], [RFC4956],
-   and [DNSEXT-NSEC2v2].
-
-1.2.  Requirements
-
-   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].
-
-
-
-
-
-
-
-
-Laurie, et al.              Standards Track                     [Page 4]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-1.3.  Terminology
-
-   The reader is assumed to be familiar with the basic DNS and DNSSEC
-   concepts described in [RFC1034], [RFC1035], [RFC4033], [RFC4034],
-   [RFC4035], and subsequent RFCs that update them: [RFC2136],
-   [RFC2181], and [RFC2308].
-
-   The following terminology is used throughout this document:
-
-   Zone enumeration:  the practice of discovering the full content of a
-      zone via successive queries.  Zone enumeration was non-trivial
-      prior to the introduction of DNSSEC.
-
-   Original owner name:  the owner name corresponding to a hashed owner
-      name.
-
-   Hashed owner name:  the owner name created after applying the hash
-      function to an owner name.
-
-   Hash order:  the order in which hashed owner names are arranged
-      according to their numerical value, treating the leftmost (lowest
-      numbered) octet as the most significant octet.  Note that this
-      order is the same as the canonical DNS name order specified in
-      [RFC4034], when the hashed owner names are in base32, encoded with
-      an Extended Hex Alphabet [RFC4648].
-
-   Empty non-terminal:  a domain name that owns no resource records, but
-      has one or more subdomains that do.
-
-   Delegation:  an NS RRSet with a name different from the current zone
-      apex (non-zone-apex), signifying a delegation to a child zone.
-
-   Secure delegation:  a name containing a delegation (NS RRSet) and a
-      signed DS RRSet, signifying a delegation to a signed child zone.
-
-   Insecure delegation:  a name containing a delegation (NS RRSet), but
-      lacking a DS RRSet, signifying a delegation to an unsigned child
-      zone.
-
-   Opt-Out NSEC3 resource record:  an NSEC3 resource record that has the
-      Opt-Out flag set to 1.
-
-   Opt-Out zone:  a zone with at least one Opt-Out NSEC3 RR.
-
-   Closest encloser:  the longest existing ancestor of a name.  See also
-      Section 3.3.1 of [RFC4592].
-
-
-
-
-
-Laurie, et al.              Standards Track                     [Page 5]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-   Closest provable encloser:  the longest ancestor of a name that can
-      be proven to exist.  Note that this is only different from the
-      closest encloser in an Opt-Out zone.
-
-   Next closer name:  the name one label longer than the closest
-      provable encloser of a name.
-
-   Base32:  the "Base 32 Encoding with Extended Hex Alphabet" as
-      specified in [RFC4648].  Note that trailing padding characters
-      ("=") are not used in the NSEC3 specification.
-
-   To cover:  An NSEC3 RR is said to "cover" a name if the hash of the
-      name or "next closer" name falls between the owner name and the
-      next hashed owner name of the NSEC3.  In other words, if it proves
-      the nonexistence of the name, either directly or by proving the
-      nonexistence of an ancestor of the name.
-
-   To match:  An NSEC3 RR is said to "match" a name if the owner name of
-      the NSEC3 RR is the same as the hashed owner name of that name.
-
-2.  Backwards Compatibility
-
-   This specification describes a protocol change that is not generally
-   backwards compatible with [RFC4033], [RFC4034], and [RFC4035].  In
-   particular, security-aware resolvers that are unaware of this
-   specification (NSEC3-unaware resolvers) may fail to validate the
-   responses introduced by this document.
-
-   In order to aid deployment, this specification uses a signaling
-   technique to prevent NSEC3-unaware resolvers from attempting to
-   validate responses from NSEC3-signed zones.
-
-   This specification allocates two new DNSKEY algorithm identifiers for
-   this purpose.  Algorithm 6, DSA-NSEC3-SHA1 is an alias for algorithm
-   3, DSA.  Algorithm 7, RSASHA1-NSEC3-SHA1 is an alias for algorithm 5,
-   RSASHA1.  These are not new algorithms, they are additional
-   identifiers for the existing algorithms.
-
-   Zones signed according to this specification MUST only use these
-   algorithm identifiers for their DNSKEY RRs.  Because these new
-   identifiers will be unknown algorithms to existing, NSEC3-unaware
-   resolvers, those resolvers will then treat responses from the NSEC3
-   signed zone as insecure, as detailed in Section 5.2 of [RFC4035].
-
-   These algorithm identifiers are used with the NSEC3 hash algorithm
-   SHA1.  Using other NSEC3 hash algorithms requires allocation of a new
-   alias (see Section 12.1.3).
-
-
-
-
-Laurie, et al.              Standards Track                     [Page 6]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-   Security aware resolvers that are aware of this specification MUST
-   recognize the new algorithm identifiers and treat them as equivalent
-   to the algorithms that they alias.
-
-   A methodology for transitioning from a DNSSEC signed zone to a zone
-   signed using NSEC3 is discussed in Section 10.4.
-
-3.  The NSEC3 Resource Record
-
-   The NSEC3 Resource Record (RR) provides authenticated denial of
-   existence for DNS Resource Record Sets.
-
-   The NSEC3 RR lists RR types present at the original owner name of the
-   NSEC3 RR.  It includes the next hashed owner name in the hash order
-   of the zone.  The complete set of NSEC3 RRs in a zone indicates which
-   RRSets exist for the original owner name of the RR and form a chain
-   of hashed owner names in the zone.  This information is used to
-   provide authenticated denial of existence for DNS data.  To provide
-   protection against zone enumeration, the owner names used in the
-   NSEC3 RR are cryptographic hashes of the original owner name
-   prepended as a single label 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 owner name.  The hashing technique is
-   described fully in Section 5.
-
-   Hashed owner names of unsigned delegations may be excluded from the
-   chain.  An NSEC3 RR whose span covers the hash of an owner name or
-   "next closer" name of an unsigned delegation is referred to as an
-   Opt-Out NSEC3 RR and is indicated by the presence of a flag.
-
-   The owner name for the NSEC3 RR is the base32 encoding of the hashed
-   owner name prepended as a single label to the name of the zone.
-
-   The type value for the NSEC3 RR is 50.
-
-   The NSEC3 RR RDATA format is class independent and is described
-   below.
-
-   The class MUST be the same as the class of the original owner name.
-
-   The NSEC3 RR SHOULD have the same TTL value as the SOA minimum TTL
-   field.  This is in the spirit of negative caching [RFC2308].
-
-
-
-
-
-
-
-
-Laurie, et al.              Standards Track                     [Page 7]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-3.1.  RDATA Fields
-
-3.1.1.  Hash Algorithm
-
-   The Hash Algorithm field identifies the cryptographic hash algorithm
-   used to construct the hash-value.
-
-   The values for this field are defined in the NSEC3 hash algorithm
-   registry defined in Section 11.
-
-3.1.2.  Flags
-
-   The Flags field contains 8 one-bit flags that can be used to indicate
-   different processing.  All undefined flags must be zero.  The only
-   flag defined by this specification is the Opt-Out flag.
-
-3.1.2.1.  Opt-Out Flag
-
-   If the Opt-Out flag is set, the NSEC3 record covers zero or more
-   unsigned delegations.
-
-   If the Opt-Out flag is clear, the NSEC3 record covers zero unsigned
-   delegations.
-
-   The Opt-Out Flag indicates whether this NSEC3 RR may cover unsigned
-   delegations.  It is the least significant bit in the Flags field.
-   See Section 6 for details about the use of this flag.
-
-3.1.3.  Iterations
-
-   The Iterations field defines the number of additional times the hash
-   function has been performed.  More iterations result in greater
-   resiliency of the hash value against dictionary attacks, but at a
-   higher computational cost for both the server and resolver.  See
-   Section 5 for details of the use of this field, and Section 10.3 for
-   limitations on the value.
-
-3.1.4.  Salt Length
-
-   The Salt Length field defines the length of the Salt field in octets,
-   ranging in value from 0 to 255.
-
-3.1.5.  Salt
-
-   The Salt field is appended to the original owner name before hashing
-   in order to defend against pre-calculated dictionary attacks.  See
-   Section 5 for details on how the salt is used.
-
-
-
-
-Laurie, et al.              Standards Track                     [Page 8]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-3.1.6.  Hash Length
-
-   The Hash Length field defines the length of the Next Hashed Owner
-   Name field, ranging in value from 1 to 255 octets.
-
-3.1.7.  Next Hashed Owner Name
-
-   The Next Hashed Owner Name field contains the next hashed owner name
-   in hash order.  This value is in binary format.  Given the ordered
-   set of all hashed owner names, the Next Hashed Owner Name field
-   contains the hash of an owner name that immediately follows the owner
-   name of the given NSEC3 RR.  The value of the Next Hashed Owner Name
-   field in the last NSEC3 RR in the zone is the same as the hashed
-   owner name of the first NSEC3 RR in the zone in hash order.  Note
-   that, unlike the owner name of the NSEC3 RR, the value of this field
-   does not contain the appended zone name.
-
-3.1.8.  Type Bit Maps
-
-   The Type Bit Maps field identifies the RRSet types that exist at the
-   original owner name of the NSEC3 RR.
-
-3.2.  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 Alg.   |     Flags     |          Iterations           |
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |  Salt Length  |                     Salt                      /
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |  Hash Length  |             Next Hashed Owner Name            /
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   /                         Type Bit Maps                         /
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-   Hash Algorithm is a single octet.
-
-   Flags field is a single octet, the Opt-Out flag is the least
-   significant bit, as shown below:
-
-    0 1 2 3 4 5 6 7
-   +-+-+-+-+-+-+-+-+
-   |             |O|
-   +-+-+-+-+-+-+-+-+
-
-
-
-
-Laurie, et al.              Standards Track                     [Page 9]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-   Iterations is represented as a 16-bit unsigned integer, with the most
-   significant bit first.
-
-   Salt Length is represented as an unsigned octet.  Salt Length
-   represents the length of the Salt field in octets.  If the value is
-   zero, the following Salt field is omitted.
-
-   Salt, if present, is encoded as a sequence of binary octets.  The
-   length of this field is determined by the preceding Salt Length
-   field.
-
-   Hash Length is represented as an unsigned octet.  Hash Length
-   represents the length of the Next Hashed Owner Name field in octets.
-
-   The next hashed owner name is not base32 encoded, unlike the owner
-   name of the NSEC3 RR.  It is the unmodified binary hash value.  It
-   does not include the name of the containing zone.  The length of this
-   field is determined by the preceding Hash Length field.
-
-3.2.1.  Type Bit Maps Encoding
-
-   The encoding of the Type Bit Maps field is the same as that used by
-   the NSEC RR, described in [RFC4034].  It is explained and clarified
-   here for clarity.
-
-   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 bitmap of the
-   window block, and up to 32 octets (256 bits) of bitmap.
-
-   Blocks are present in the NSEC3 RR RDATA in increasing numerical
-   order.
-
-      Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )+
-
-      where "|" denotes concatenation.
-
-   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
-   original owner name of the NSEC3 RR.  If a bit is set to 0, it
-   indicates that no RRSet of that type is present for the original
-   owner name of the NSEC3 RR.
-
-
-
-Laurie, et al.              Standards Track                    [Page 10]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-   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 Section 3.1 of
-   [RFC2929] 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 the bitmap of
-   each block is determined by the type code with the largest numerical
-   value, within that block, among the set of RR types present at the
-   original owner name of the NSEC3 RR.  Trailing octets not specified
-   MUST be interpreted as zero octets.
-
-3.3.  Presentation Format
-
-   The presentation format of the RDATA portion is as follows:
-
-   o  The Hash Algorithm field is represented as an unsigned decimal
-      integer.  The value has a maximum of 255.
-
-   o  The Flags field is represented as an unsigned decimal integer.
-      The value has a maximum of 255.
-
-   o  The Iterations field is represented as an unsigned decimal
-      integer.  The value is between 0 and 65535, inclusive.
-
-   o  The Salt Length field is not represented.
-
-   o  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 a value of 0.
-
-   o  The Hash Length field is not represented.
-
-   o  The Next Hashed Owner Name field is represented as an unpadded
-      sequence of case-insensitive base32 digits, without whitespace.
-
-   o  The Type Bit Maps field is represented as a sequence of RR type
-      mnemonics.  When the mnemonic is not known, the TYPE
-      representation as described in Section 5 of [RFC3597] MUST be
-      used.
-
-
-
-
-
-
-Laurie, et al.              Standards Track                    [Page 11]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-4.  The NSEC3PARAM Resource Record
-
-   The NSEC3PARAM RR contains the NSEC3 parameters (hash algorithm,
-   flags, iterations, and salt) needed by authoritative servers to
-   calculate hashed owner names.  The presence of an NSEC3PARAM RR at a
-   zone apex indicates that the specified parameters may be used by
-   authoritative servers to choose an appropriate set of NSEC3 RRs for
-   negative responses.  The NSEC3PARAM RR is not used by validators or
-   resolvers.
-
-   If an NSEC3PARAM RR is present at the apex of a zone with a Flags
-   field value of zero, then there MUST be an NSEC3 RR using the same
-   hash algorithm, iterations, and salt parameters present at every
-   hashed owner name in the zone.  That is, the zone MUST contain a
-   complete set of NSEC3 RRs with the same hash algorithm, iterations,
-   and salt parameters.
-
-   The owner name for the NSEC3PARAM RR is the name of the zone apex.
-
-   The type value for the NSEC3PARAM RR is 51.
-
-   The NSEC3PARAM RR RDATA format is class independent and is described
-   below.
-
-   The class MUST be the same as the NSEC3 RRs to which this RR refers.
-
-4.1.  RDATA Fields
-
-   The RDATA for this RR mirrors the first four fields in the NSEC3 RR.
-
-4.1.1.  Hash Algorithm
-
-   The Hash Algorithm field identifies the cryptographic hash algorithm
-   used to construct the hash-value.
-
-   The acceptable values are the same as the corresponding field in the
-   NSEC3 RR.
-
-4.1.2.  Flag Fields
-
-   The Opt-Out flag is not used and is set to zero.
-
-   All other flags are reserved for future use, and must be zero.
-
-   NSEC3PARAM RRs with a Flags field value other than zero MUST be
-   ignored.
-
-
-
-
-
-Laurie, et al.              Standards Track                    [Page 12]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-4.1.3.  Iterations
-
-   The Iterations field defines the number of additional times the hash
-   is performed.
-
-   Its acceptable values are the same as the corresponding field in the
-   NSEC3 RR.
-
-4.1.4.  Salt Length
-
-   The Salt Length field defines the length of the salt in octets,
-   ranging in value from 0 to 255.
-
-4.1.5.  Salt
-
-   The Salt field is appended to the original owner name before hashing.
-
-4.2.  NSEC3PARAM RDATA Wire Format
-
-   The RDATA of the NSEC3PARAM 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 Alg.   |     Flags     |          Iterations           |
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |  Salt Length  |                     Salt                      /
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-   Hash Algorithm is a single octet.
-
-   Flags field is a single octet.
-
-   Iterations is represented as a 16-bit unsigned integer, with the most
-   significant bit first.
-
-   Salt Length is represented as an unsigned octet.  Salt Length
-   represents the length of the following Salt field in octets.  If the
-   value is zero, the Salt field is omitted.
-
-   Salt, if present, is encoded as a sequence of binary octets.  The
-   length of this field is determined by the preceding Salt Length
-   field.
-
-
-
-
-
-
-
-
-Laurie, et al.              Standards Track                    [Page 13]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-4.3.  Presentation Format
-
-   The presentation format of the RDATA portion is as follows:
-
-   o  The Hash Algorithm field is represented as an unsigned decimal
-      integer.  The value has a maximum of 255.
-
-   o  The Flags field is represented as an unsigned decimal integer.
-      The value has a maximum value of 255.
-
-   o  The Iterations field is represented as an unsigned decimal
-      integer.  The value is between 0 and 65535, inclusive.
-
-   o  The Salt Length field is not represented.
-
-   o  The Salt field is represented as a sequence of case-insensitive
-      hexadecimal digits.  Whitespace is not allowed within the
-      sequence.  This field is represented as "-" (without the quotes)
-      when the Salt Length field is zero.
-
-5.  Calculation of the Hash
-
-   The hash calculation uses three of the NSEC3 RDATA fields: Hash
-   Algorithm, Salt, and Iterations.
-
-   Define H(x) to be the hash of x using the Hash Algorithm selected by
-   the NSEC3 RR, k to be the number of Iterations, and || to indicate
-   concatenation.  Then define:
-
-      IH(salt, x, 0) = H(x || salt), and
-
-      IH(salt, x, k) = H(IH(salt, x, k-1) || salt), if k > 0
-
-   Then the calculated hash of an owner name is
-
-      IH(salt, owner name, iterations),
-
-   where the owner name is in the canonical form, defined as:
-
-   The wire format of the owner name where:
-
-   1.  The owner name 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;
-
-
-
-
-
-Laurie, et al.              Standards Track                    [Page 14]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-   3.  If the owner name is a wildcard name, the owner name is in its
-       original unexpanded form, including the "*" label (no wildcard
-       substitution);
-
-   This form is as defined in Section 6.2 of [RFC4034].
-
-   The method to calculate the Hash is based on [RFC2898].
-
-6.  Opt-Out
-
-   In this specification, as in [RFC4033], [RFC4034] and [RFC4035], NS
-   RRSets at delegation points are not signed and may be accompanied by
-   a DS RRSet.  With the Opt-Out bit clear, the security status of the
-   child zone is determined by the presence or absence of this DS RRSet,
-   cryptographically proven by the signed NSEC3 RR at the hashed owner
-   name of the delegation.  Setting the Opt-Out flag modifies this by
-   allowing insecure delegations to exist within the signed zone without
-   a corresponding NSEC3 RR at the hashed owner name of the delegation.
-
-   An Opt-Out NSEC3 RR is said to cover a delegation if the hash of the
-   owner name or "next closer" name of the delegation is between the
-   owner name of the NSEC3 RR and the next hashed owner name.
-
-   An Opt-Out NSEC3 RR does not assert the existence or non-existence of
-   the insecure delegations that it may cover.  This allows for the
-   addition or removal of these delegations without recalculating or re-
-   signing RRs in the NSEC3 RR chain.  However, Opt-Out NSEC3 RRs do
-   assert the (non)existence of other, authoritative RRSets.
-
-   An Opt-Out NSEC3 RR 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 the type map and the signed NSEC3 RR does
-   assert the existence of the delegation.
-
-   Zones using Opt-Out MAY contain a mixture of Opt-Out NSEC3 RRs and
-   non-Opt-Out NSEC3 RRs.  If an NSEC3 RR is not Opt-Out, there MUST NOT
-   be any hashed owner names of insecure delegations (nor any other RRs)
-   between it and the name indicated by the next hashed owner name in
-   the NSEC3 RDATA.  If it is Opt-Out, it MUST only cover hashed owner
-   names or hashed "next closer" names of insecure delegations.
-
-   The effects of the Opt-Out flag on signing, serving, and validating
-   responses are covered in following sections.
-
-
-
-
-
-
-
-
-Laurie, et al.              Standards Track                    [Page 15]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-7.  Authoritative Server Considerations
-
-7.1.  Zone Signing
-
-   Zones using NSEC3 must satisfy the following properties:
-
-   o  Each owner name within the zone that owns authoritative RRSets
-      MUST have a corresponding NSEC3 RR.  Owner names that correspond
-      to unsigned delegations MAY have a corresponding NSEC3 RR.
-      However, if there is not a corresponding NSEC3 RR, there MUST be
-      an Opt-Out NSEC3 RR that covers the "next closer" name to the
-      delegation.  Other non-authoritative RRs are not represented by
-      NSEC3 RRs.
-
-   o  Each empty non-terminal MUST have a corresponding NSEC3 RR, unless
-      the empty non-terminal is only derived from an insecure delegation
-      covered by an Opt-Out NSEC3 RR.
-
-   o  The TTL value for any NSEC3 RR SHOULD be the same as the minimum
-      TTL value field in the zone SOA RR.
-
-   o  The Type Bit Maps field of every NSEC3 RR in a signed zone MUST
-      indicate the presence of all types present at the original owner
-      name, except for the types solely contributed by an NSEC3 RR
-      itself.  Note that this means that the NSEC3 type itself will
-      never be present in the Type Bit Maps.
-
-   The following steps describe a method of proper construction of NSEC3
-   RRs.  This is not the only such possible method.
-
-   1.  Select the hash algorithm and the values for salt and iterations.
-
-   2.  For each unique original owner name in the zone add an NSEC3 RR.
-
-       *  If Opt-Out is being used, owner names of unsigned delegations
-          MAY be excluded.
-
-       *  The owner name of the NSEC3 RR is the hash of the original
-          owner name, prepended as a single label to the zone name.
-
-       *  The Next Hashed Owner Name field is left blank for the moment.
-
-       *  If Opt-Out is being used, set the Opt-Out bit to one.
-
-       *  For collision detection purposes, optionally keep track of the
-          original owner name with the NSEC3 RR.
-
-
-
-
-
-Laurie, et al.              Standards Track                    [Page 16]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-       *  Additionally, for collision detection purposes, optionally
-          create an additional NSEC3 RR corresponding to the original
-          owner name with the asterisk label prepended (i.e., as if a
-          wildcard existed as a child of this owner name) and keep track
-          of this original owner name.  Mark this NSEC3 RR as temporary.
-
-   3.  For each RRSet at the original owner name, set the corresponding
-       bit in the Type Bit Maps field.
-
-   4.  If the difference in number of labels between the apex and the
-       original owner name is greater than 1, additional NSEC3 RRs need
-       to be added for every empty non-terminal between the apex and the
-       original owner name.  This process may generate NSEC3 RRs with
-       duplicate hashed owner names.  Optionally, for collision
-       detection, track the original owner names of these NSEC3 RRs and
-       create temporary NSEC3 RRs for wildcard collisions in a similar
-       fashion to step 1.
-
-   5.  Sort the set of NSEC3 RRs into hash order.
-
-   6.  Combine NSEC3 RRs with identical hashed owner names by replacing
-       them with a single NSEC3 RR with the Type Bit Maps field
-       consisting of the union of the types represented by the set of
-       NSEC3 RRs.  If the original owner name was tracked, then
-       collisions may be detected when combining, as all of the matching
-       NSEC3 RRs should have the same original owner name.  Discard any
-       possible temporary NSEC3 RRs.
-
-   7.  In each NSEC3 RR, insert the next hashed owner name by using the
-       value of the next NSEC3 RR in hash order.  The next hashed owner
-       name of the last NSEC3 RR in the zone contains the value of the
-       hashed owner name of the first NSEC3 RR in the hash order.
-
-   8.  Finally, add an NSEC3PARAM RR with the same Hash Algorithm,
-       Iterations, and Salt fields to the zone apex.
-
-   If a hash collision is detected, then a new salt has to be chosen,
-   and the signing process restarted.
-
-7.2.  Zone Serving
-
-   This specification modifies DNSSEC-enabled DNS responses generated by
-   authoritative servers.  In particular, it replaces the use of NSEC
-   RRs in such responses with NSEC3 RRs.
-
-
-
-
-
-
-
-Laurie, et al.              Standards Track                    [Page 17]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-   In the following response cases, the NSEC RRs dictated by DNSSEC
-   [RFC4035] are replaced with NSEC3 RRs that prove the same facts.
-   Responses that would not contain NSEC RRs are unchanged by this
-   specification.
-
-   When returning responses containing multiple NSEC3 RRs, all of the
-   NSEC3 RRs MUST use the same hash algorithm, iteration, and salt
-   values.  The Flags field value MUST be either zero or one.
-
-7.2.1.  Closest Encloser Proof
-
-   For many NSEC3 responses a proof of the closest encloser is required.
-   This is a proof that some ancestor of the QNAME is the closest
-   encloser of QNAME.
-
-   This proof consists of (up to) two different NSEC3 RRs:
-
-   o  An NSEC3 RR that matches the closest (provable) encloser.
-
-   o  An NSEC3 RR that covers the "next closer" name to the closest
-      encloser.
-
-   The first NSEC3 RR essentially proposes a possible closest encloser,
-   and proves that the particular encloser does, in fact, exist.  The
-   second NSEC3 RR proves that the possible closest encloser is the
-   closest, and proves that the QNAME (and any ancestors between QNAME
-   and the closest encloser) does not exist.
-
-   These NSEC3 RRs are collectively referred to as the "closest encloser
-   proof" in the subsequent descriptions.
-
-   For example, the closest encloser proof for the nonexistent
-   "alpha.beta.gamma.example." owner name might prove that
-   "gamma.example." is the closest encloser.  This response would
-   contain the NSEC3 RR that matches "gamma.example.", and would also
-   contain the NSEC3 RR that covers "beta.gamma.example." (which is the
-   "next closer" name).
-
-   It is possible, when using Opt-Out (Section 6), to not be able to
-   prove the actual closest encloser because it is, or is part of an
-   insecure delegation covered by an Opt-Out span.  In this case,
-   instead of proving the actual closest encloser, the closest provable
-   encloser is used.  That is, the closest enclosing authoritative name
-   is used instead.  In this case, the set of NSEC3 RRs used for this
-   proof is referred to as the "closest provable encloser proof".
-
-
-
-
-
-
-Laurie, et al.              Standards Track                    [Page 18]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-7.2.2.  Name Error Responses
-
-   To prove the nonexistence of QNAME, a closest encloser proof and an
-   NSEC3 RR covering the (nonexistent) wildcard RR at the closest
-   encloser MUST be included in the response.  This collection of (up
-   to) three NSEC3 RRs proves both that QNAME does not exist and that a
-   wildcard that could have matched QNAME also does not exist.
-
-   For example, if "gamma.example." is the closest provable encloser to
-   QNAME, then an NSEC3 RR covering "*.gamma.example." is included in
-   the authority section of the response.
-
-7.2.3.  No Data Responses, QTYPE is not DS
-
-   The server MUST include the NSEC3 RR that matches QNAME.  This NSEC3
-   RR MUST NOT have the bits corresponding to either the QTYPE or CNAME
-   set in its Type Bit Maps field.
-
-7.2.4.  No Data Responses, QTYPE is DS
-
-   If there is an NSEC3 RR that matches QNAME, the server MUST return it
-   in the response.  The bits corresponding with DS and CNAME MUST NOT
-   be set in the Type Bit Maps field of this NSEC3 RR.
-
-   If no NSEC3 RR matches QNAME, the server MUST return a closest
-   provable encloser proof for QNAME.  The NSEC3 RR that covers the
-   "next closer" name MUST have the Opt-Out bit set (note that this is
-   true by definition -- if the Opt-Out bit is not set, something has
-   gone wrong).
-
-   If a server is authoritative for both sides of a zone cut at QNAME,
-   the server MUST return the proof from the parent side of the zone
-   cut.
-
-7.2.5.  Wildcard No Data Responses
-
-   If there is a wildcard match for QNAME, but QTYPE is not present at
-   that name, the response MUST include a closest encloser proof for
-   QNAME and MUST include the NSEC3 RR that matches the wildcard.  This
-   combination proves both that QNAME itself does not exist and that a
-   wildcard that matches QNAME does exist.  Note that the closest
-   encloser to QNAME MUST be the immediate ancestor of the wildcard RR
-   (if this is not the case, then something has gone wrong).
-
-
-
-
-
-
-
-
-Laurie, et al.              Standards Track                    [Page 19]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-7.2.6.  Wildcard Answer Responses
-
-   If there is a wildcard match for QNAME and QTYPE, then, in addition
-   to the expanded wildcard RRSet returned in the answer section of the
-   response, proof that the wildcard match was valid must be returned.
-
-   This proof is accomplished by proving that both QNAME does not exist
-   and that the closest encloser of the QNAME and the immediate ancestor
-   of the wildcard are the same (i.e., the correct wildcard matched).
-
-   To this end, the NSEC3 RR that covers the "next closer" name of the
-   immediate ancestor of the wildcard MUST be returned.  It is not
-   necessary to return an NSEC3 RR that matches the closest encloser, as
-   the existence of this closest encloser is proven by the presence of
-   the expanded wildcard in the response.
-
-7.2.7.  Referrals to Unsigned Subzones
-
-   If there is an NSEC3 RR that matches the delegation name, then that
-   NSEC3 RR MUST be included in the response.  The DS bit in the type
-   bit maps of the NSEC3 RR MUST NOT be set.
-
-   If the zone is Opt-Out, then there may not be an NSEC3 RR
-   corresponding to the delegation.  In this case, the closest provable
-   encloser proof MUST be included in the response.  The included NSEC3
-   RR that covers the "next closer" name for the delegation MUST have
-   the Opt-Out flag set to one.  (Note that this will be the case unless
-   something has gone wrong).
-
-7.2.8.  Responding to Queries for NSEC3 Owner Names
-
-   The owner names of NSEC3 RRs are not represented in the NSEC3 RR
-   chain like other owner names.  As a result, each NSEC3 owner name is
-   covered by another NSEC3 RR, effectively negating the existence of
-   the NSEC3 RR.  This is a paradox, since the existence of an NSEC3 RR
-   can be proven by its RRSIG RRSet.
-
-   If the following conditions are all true:
-
-   o  the QNAME equals the owner name of an existing NSEC3 RR, and
-
-   o  no RR types exist at the QNAME, nor at any descendant of QNAME,
-
-   then the response MUST be constructed as a Name Error response
-   (Section 7.2.2).  Or, in other words, the authoritative name server
-   will act as if the owner name of the NSEC3 RR did not exist.
-
-
-
-
-
-Laurie, et al.              Standards Track                    [Page 20]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-   Note that NSEC3 RRs are returned as a result of an AXFR or IXFR
-   query.
-
-7.2.9.  Server Response to a Run-Time Collision
-
-   If the hash of a non-existing QNAME collides with the owner name of
-   an existing NSEC3 RR, then the server will be unable to return a
-   response that proves that QNAME does not exist.  In this case, the
-   server MUST return a response with an RCODE of 2 (server failure).
-
-   Note that with the hash algorithm specified in this document, SHA-1,
-   such collisions are highly unlikely.
-
-7.3.  Secondary Servers
-
-   Secondary servers (and perhaps other entities) need to reliably
-   determine which NSEC3 parameters (i.e., hash, salt, and iterations)
-   are present at every hashed owner name, in order to be able to choose
-   an appropriate set of NSEC3 RRs for negative responses.  This is
-   indicated by an NSEC3PARAM RR present at the zone apex.
-
-   If there are multiple NSEC3PARAM RRs present, there are multiple
-   valid NSEC3 chains present.  The server must choose one of them, but
-   may use any criteria to do so.
-
-7.4.  Zones Using Unknown Hash Algorithms
-
-   Zones that are signed according to this specification, but are using
-   an unrecognized NSEC3 hash algorithm value, cannot be effectively
-   served.  Such zones SHOULD be rejected when loading.  Servers SHOULD
-   respond with RCODE=2 (server failure) responses when handling queries
-   that would fall under such zones.
-
-7.5.  Dynamic Update
-
-   A zone signed using NSEC3 may accept dynamic updates [RFC2136].
-   However, NSEC3 introduces some special considerations for dynamic
-   updates.
-
-   Adding and removing names in a zone MUST account for the creation or
-   removal of empty non-terminals.
-
-   o  When removing a name with a corresponding NSEC3 RR, any NSEC3 RRs
-      corresponding to empty non-terminals created by that name MUST be
-      removed.  Note that more than one name may be asserting the
-      existence of a particular empty non-terminal.
-
-
-
-
-
-Laurie, et al.              Standards Track                    [Page 21]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-   o  When adding a name that requires adding an NSEC3 RR, NSEC3 RRs
-      MUST also be added for any empty non-terminals that are created.
-      That is, if there is not an existing NSEC3 RR matching an empty
-      non-terminal, it must be created and added.
-
-   The presence of Opt-Out in a zone means that some additions or
-   delegations of names will not require changes to the NSEC3 RRs in a
-   zone.
-
-   o  When removing a delegation RRSet, if that delegation does not have
-      a matching NSEC3 RR, then it was opted out.  In this case, nothing
-      further needs to be done.
-
-   o  When adding a delegation RRSet, if the "next closer" name of the
-      delegation is covered by an existing Opt-Out NSEC3 RR, then the
-      delegation MAY be added without modifying the NSEC3 RRs in the
-      zone.
-
-   The presence of Opt-Out in a zone means that when adding or removing
-   NSEC3 RRs, the value of the Opt-Out flag that should be set in new or
-   modified NSEC3 RRs is ambiguous.  Servers SHOULD follow this set of
-   basic rules to resolve the ambiguity.
-
-   The central concept to these rules is that the state of the Opt-Out
-   flag of the covering NSEC3 RR is preserved.
-
-   o  When removing an NSEC3 RR, the value of the Opt-Out flag for the
-      previous NSEC3 RR (the one whose next hashed owner name is
-      modified) should not be changed.
-
-   o  When adding an NSEC3 RR, the value of the Opt-Out flag is set to
-      the value of the Opt-Out flag of the NSEC3 RR that previously
-      covered the owner name of the NSEC3 RR.  That is, the now previous
-      NSEC3 RR.
-
-   If the zone in question is consistent with its use of the Opt-Out
-   flag (that is, all NSEC3 RRs in the zone have the same value for the
-   flag) then these rules will retain that consistency.  If the zone is
-   not consistent in the use of the flag (i.e., a partially Opt-Out
-   zone), then these rules will not retain the same pattern of use of
-   the Opt-Out flag.
-
-   For zones that partially use the Opt-Out flag, if there is a logical
-   pattern for that use, the pattern could be maintained by using a
-   local policy on the server.
-
-
-
-
-
-
-Laurie, et al.              Standards Track                    [Page 22]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-8.  Validator Considerations
-
-8.1.  Responses with Unknown Hash Types
-
-   A validator MUST ignore NSEC3 RRs with unknown hash types.  The
-   practical result of this is that responses containing only such NSEC3
-   RRs will generally be considered bogus.
-
-8.2.  Verifying NSEC3 RRs
-
-   A validator MUST ignore NSEC3 RRs with a Flag fields value other than
-   zero or one.
-
-   A validator MAY treat a response as bogus if the response contains
-   NSEC3 RRs that contain different values for hash algorithm,
-   iterations, or salt from each other for that zone.
-
-8.3.  Closest Encloser Proof
-
-   In order to verify a closest encloser proof, the validator MUST find
-   the longest name, X, such that
-
-   o  X is an ancestor of QNAME that is matched by an NSEC3 RR present
-      in the response.  This is a candidate for the closest encloser,
-      and
-
-   o  The name one label longer than X (but still an ancestor of -- or
-      equal to -- QNAME) is covered by an NSEC3 RR present in the
-      response.
-
-   One possible algorithm for verifying this proof is as follows:
-
-   1.  Set SNAME=QNAME.  Clear the flag.
-
-   2.  Check whether SNAME exists:
-
-       *  If there is no NSEC3 RR in the response that matches SNAME
-          (i.e., an NSEC3 RR whose owner name is the same as the hash of
-          SNAME, prepended as a single label to the zone name), clear
-          the flag.
-
-       *  If there is an NSEC3 RR in the response that covers SNAME, set
-          the flag.
-
-       *  If there is a matching NSEC3 RR in the response and the flag
-          was set, then the proof is complete, and SNAME is the closest
-          encloser.
-
-
-
-
-Laurie, et al.              Standards Track                    [Page 23]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-       *  If there is a matching NSEC3 RR in the response, but the flag
-          is not set, then the response is bogus.
-
-   3.  Truncate SNAME by one label from the left, go to step 2.
-
-   Once the closest encloser has been discovered, the validator MUST
-   check that the NSEC3 RR that has the closest encloser as the original
-   owner name is from the proper zone.  The DNAME type bit must not be
-   set and the NS type bit may only be set if the SOA type bit is set.
-   If this is not the case, it would be an indication that an attacker
-   is using them to falsely deny the existence of RRs for which the
-   server is not authoritative.
-
-   In the following descriptions, the phrase "a closest (provable)
-   encloser proof for X" means that the algorithm above (or an
-   equivalent algorithm) proves that X does not exist by proving that an
-   ancestor of X is its closest encloser.
-
-8.4.  Validating Name Error Responses
-
-   A validator MUST verify that there is a closest encloser proof for
-   QNAME present in the response and that there is an NSEC3 RR that
-   covers the wildcard at the closest encloser (i.e., the name formed by
-   prepending the asterisk label to the closest encloser).
-
-8.5.  Validating No Data Responses, QTYPE is not DS
-
-   The validator MUST verify that an NSEC3 RR that matches QNAME is
-   present and that both the QTYPE and the CNAME type are not set in its
-   Type Bit Maps field.
-
-   Note that this test also covers the case where the NSEC3 RR exists
-   because it corresponds to an empty non-terminal, in which case the
-   NSEC3 RR will have an empty Type Bit Maps field.
-
-8.6.  Validating No Data Responses, QTYPE is DS
-
-   If there is an NSEC3 RR that matches QNAME present in the response,
-   then that NSEC3 RR MUST NOT have the bits corresponding to DS and
-   CNAME set in its Type Bit Maps field.
-
-   If there is no such NSEC3 RR, then the validator MUST verify that a
-   closest provable encloser proof for QNAME is present in the response,
-   and that the NSEC3 RR that covers the "next closer" name has the Opt-
-   Out bit set.
-
-
-
-
-
-
-Laurie, et al.              Standards Track                    [Page 24]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-8.7.  Validating Wildcard No Data Responses
-
-   The validator MUST verify a closest encloser proof for QNAME and MUST
-   find an NSEC3 RR present in the response that matches the wildcard
-   name generated by prepending the asterisk label to the closest
-   encloser.  Furthermore, the bits corresponding to both QTYPE and
-   CNAME MUST NOT be set in the wildcard matching NSEC3 RR.
-
-8.8.  Validating Wildcard Answer Responses
-
-   The verified wildcard answer RRSet in the response provides the
-   validator with a (candidate) closest encloser for QNAME.  This
-   closest encloser is the immediate ancestor to the generating
-   wildcard.
-
-   Validators MUST verify that there is an NSEC3 RR that covers the
-   "next closer" name to QNAME present in the response.  This proves
-   that QNAME itself did not exist and that the correct wildcard was
-   used to generate the response.
-
-8.9.  Validating Referrals to Unsigned Subzones
-
-   The delegation name in a referral is the owner name of the NS RRSet
-   present in the authority section of the referral response.
-
-   If there is an NSEC3 RR present in the response that matches the
-   delegation name, then the validator MUST ensure that the NS bit is
-   set and that the DS bit is not set in the Type Bit Maps field of the
-   NSEC3 RR.  The validator MUST also ensure that the NSEC3 RR is from
-   the correct (i.e., parent) zone.  This is done by ensuring that the
-   SOA bit is not set in the Type Bit Maps field of this NSEC3 RR.
-
-   Note that the presence of an NS bit implies the absence of a DNAME
-   bit, so there is no need to check for the DNAME bit in the Type Bit
-   Maps field of the NSEC3 RR.
-
-   If there is no NSEC3 RR present that matches the delegation name,
-   then the validator MUST verify a closest provable encloser proof for
-   the delegation name.  The validator MUST verify that the Opt-Out bit
-   is set in the NSEC3 RR that covers the "next closer" name to the
-   delegation name.
-
-
-
-
-
-
-
-
-
-
-Laurie, et al.              Standards Track                    [Page 25]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-9.  Resolver Considerations
-
-9.1.  NSEC3 Resource Record Caching
-
-   Caching resolvers MUST be able to retrieve the appropriate NSEC3 RRs
-   when returning responses that contain them.  In DNSSEC [RFC4035], in
-   many cases it is possible to find the correct NSEC RR to return in a
-   response by name (e.g., when returning a referral, the NSEC RR will
-   always have the same owner name as the delegation).  With this
-   specification, that will not be true, nor will a cache be able to
-   calculate the name(s) of the appropriate NSEC3 RR(s).
-   Implementations may need to use new methods for caching and
-   retrieving NSEC3 RRs.
-
-9.2.  Use of the AD Bit
-
-   The AD bit, as defined by [RFC4035], MUST NOT be set when returning a
-   response containing a closest (provable) encloser proof in which the
-   NSEC3 RR that covers the "next closer" name has the Opt-Out bit set.
-
-   This rule is based on what this closest encloser proof actually
-   proves: names that would be covered by the Opt-Out NSEC3 RR may or
-   may not exist as insecure delegations.  As such, not all the data in
-   responses containing such closest encloser proofs will have been
-   cryptographically verified, so the AD bit cannot be set.
-
-10.  Special Considerations
-
-10.1.  Domain Name Length Restrictions
-
-   Zones signed using this specification have additional domain name
-   length restrictions imposed upon them.  In particular, zones with
-   names that, when converted into hashed owner names exceed the 255
-   octet length limit imposed by [RFC1035], cannot use this
-   specification.
-
-   The actual maximum length of a domain name in a particular zone
-   depends on both the length of the zone name (versus the whole domain
-   name) and the particular hash function used.
-
-   As an example, SHA-1 produces a hash of 160 bits.  The base-32
-   encoding of 160 bits results in 32 characters.  The 32 characters are
-   prepended to the name of the zone as a single label, which includes a
-   length field of a single octet.  The maximum length of the zone name,
-   when using SHA-1, is 222 octets (255 - 33).
-
-
-
-
-
-
-Laurie, et al.              Standards Track                    [Page 26]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-10.2.  DNAME at the Zone Apex
-
-   The DNAME specification in Section 3 of [RFC2672] has a 'no-
-   descendants' limitation.  If a DNAME RR is present at node N, there
-   MUST be no data at any descendant of N.
-
-   If N is the apex of the zone, there will be NSEC3 and RRSIG types
-   present at descendants of N.  This specification updates the DNAME
-   specification to allow NSEC3 and RRSIG types at descendants of the
-   apex regardless of the existence of DNAME at the apex.
-
-10.3.  Iterations
-
-   Setting the number of iterations used allows the zone owner to choose
-   the cost of computing a hash, and therefore 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 and serving the zone as well as the validator's cost of
-   verifying responses from the zone.  We therefore impose an upper
-   limit on the number of iterations.  We base this on the number of
-   iterations that approximates the cost of verifying an RRSet.
-
-   The limits, therefore, are based on the size of the smallest zone
-   signing key, rounded up to the nearest table value (or rounded down
-   if the key is larger than the largest table value).
-
-   A zone owner MUST NOT use a value higher than shown in the table
-   below for iterations for the given key size.  A resolver MAY treat a
-   response with a higher value as insecure, after the validator has
-   verified that the signature over the NSEC3 RR is correct.
-
-                         +----------+------------+
-                         | Key Size | Iterations |
-                         +----------+------------+
-                         | 1024     | 150        |
-                         | 2048     | 500        |
-                         | 4096     | 2,500      |
-                         +----------+------------+
-
-   This table is based on an approximation of the ratio between the cost
-   of an SHA-1 calculation and the cost of an RSA verification for keys
-   of size 1024 bits (150 to 1), 2048 bits (500 to 1), and 4096 bits
-   (2500 to 1).
-
-
-
-
-
-Laurie, et al.              Standards Track                    [Page 27]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-   The ratio between SHA-1 calculation and DSA verification is higher
-   (1500 to 1 for keys of size 1024).  A higher iteration count degrades
-   performance, while DSA verification is already more expensive than
-   RSA for the same key size.  Therefore the values in the table MUST be
-   used independent of the key algorithm.
-
-10.4.  Transitioning a Signed Zone from NSEC to NSEC3
-
-   When transitioning an already signed and trusted zone to this
-   specification, care must be taken to prevent client validation
-   failures during the process.
-
-   The basic procedure is as follows:
-
-   1.  Transition all DNSKEYs to DNSKEYs using the algorithm aliases
-       described in Section 2.  The actual method for safely and
-       securely changing the DNSKEY RRSet of the zone is outside the
-       scope of this specification.  However, the end result MUST be
-       that all DS RRs in the parent use the specified algorithm
-       aliases.
-
-       After this transition is complete, all NSEC3-unaware clients will
-       treat the zone as insecure.  At this point, the authoritative
-       server still returns negative and wildcard responses that contain
-       NSEC RRs.
-
-   2.  Add signed NSEC3 RRs to the zone, either incrementally or all at
-       once.  If adding incrementally, then the last RRSet added MUST be
-       the NSEC3PARAM RRSet.
-
-   3.  Upon the addition of the NSEC3PARAM RRSet, the server switches to
-       serving negative and wildcard responses with NSEC3 RRs according
-       to this specification.
-
-   4.  Remove the NSEC RRs either incrementally or all at once.
-
-10.5.  Transitioning a Signed Zone from NSEC3 to NSEC
-
-   To safely transition back to a DNSSEC [RFC4035] signed zone, simply
-   reverse the procedure above:
-
-   1.  Add NSEC RRs incrementally or all at once.
-
-   2.  Remove the NSEC3PARAM RRSet.  This will signal the server to use
-       the NSEC RRs for negative and wildcard responses.
-
-   3.  Remove the NSEC3 RRs either incrementally or all at once.
-
-
-
-
-Laurie, et al.              Standards Track                    [Page 28]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-   4.  Transition all of the DNSKEYs to DNSSEC algorithm identifiers.
-       After this transition is complete, all NSEC3-unaware clients will
-       treat the zone as secure.
-
-11.  IANA Considerations
-
-   Although the NSEC3 and NSEC3PARAM RR formats include a hash algorithm
-   parameter, this document does not define a particular mechanism for
-   safely transitioning from one NSEC3 hash algorithm to another.  When
-   specifying a new hash algorithm for use with NSEC3, a transition
-   mechanism MUST also be defined.
-
-   This document updates the IANA registry "DOMAIN NAME SYSTEM
-   PARAMETERS" (http://www.iana.org/assignments/dns-parameters) in sub-
-   registry "TYPES", by defining two new types.  Section 3 defines the
-   NSEC3 RR type 50.  Section 4 defines the NSEC3PARAM RR type 51.
-
-   This document updates the IANA registry "DNS SECURITY ALGORITHM
-   NUMBERS -- per [RFC4035]"
-   (http://www.iana.org/assignments/dns-sec-alg-numbers).  Section 2
-   defines the aliases DSA-NSEC3-SHA1 (6) and RSASHA1-NSEC3-SHA1 (7) for
-   respectively existing registrations DSA and RSASHA1 in combination
-   with NSEC3 hash algorithm SHA1.
-
-   Since these algorithm numbers are aliases for existing DNSKEY
-   algorithm numbers, the flags that exist for the original algorithm
-   are valid for the alias algorithm.
-
-   This document creates a new IANA registry for NSEC3 flags.  This
-   registry is named "DNSSEC NSEC3 Flags".  The initial contents of this
-   registry are:
-
-     0   1   2   3   4   5   6   7
-   +---+---+---+---+---+---+---+---+
-   |   |   |   |   |   |   |   |Opt|
-   |   |   |   |   |   |   |   |Out|
-   +---+---+---+---+---+---+---+---+
-
-      bit 7 is the Opt-Out flag.
-
-      bits 0 - 6 are available for assignment.
-
-   Assignment of additional NSEC3 Flags in this registry requires IETF
-   Standards Action [RFC2434].
-
-   This document creates a new IANA registry for NSEC3PARAM flags.  This
-   registry is named "DNSSEC NSEC3PARAM Flags".  The initial contents of
-   this registry are:
-
-
-
-Laurie, et al.              Standards Track                    [Page 29]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-     0   1   2   3   4   5   6   7
-   +---+---+---+---+---+---+---+---+
-   |   |   |   |   |   |   |   | 0 |
-   +---+---+---+---+---+---+---+---+
-
-      bit 7 is reserved and must be 0.
-
-      bits 0 - 6 are available for assignment.
-
-   Assignment of additional NSEC3PARAM Flags in this registry requires
-   IETF Standards Action [RFC2434].
-
-   Finally, this document creates a new IANA registry for NSEC3 hash
-   algorithms.  This registry is named "DNSSEC NSEC3 Hash Algorithms".
-   The initial contents of this registry are:
-
-      0 is Reserved.
-
-      1 is SHA-1.
-
-      2-255 Available for assignment.
-
-   Assignment of additional NSEC3 hash algorithms in this registry
-   requires IETF Standards Action [RFC2434].
-
-12.  Security Considerations
-
-12.1.  Hashing Considerations
-
-12.1.1.  Dictionary Attacks
-
-   The NSEC3 RRs are still susceptible to dictionary attacks (i.e., the
-   attacker retrieves all the NSEC3 RRs, then calculates the hashes of
-   all likely domain names, comparing against the hashes found in the
-   NSEC3 RRs, and thus enumerating the zone).  These are substantially
-   more expensive than enumerating the original NSEC RRs 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.
-
-   Zones are also susceptible to a pre-calculated dictionary attack --
-   that is, a list of hashes for all likely names is computed once, then
-   NSEC3 RR is scanned periodically and compared against the precomputed
-   hashes.  This attack is prevented by changing the salt on a regular
-   basis.
-
-
-
-
-Laurie, et al.              Standards Track                    [Page 30]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-   The salt SHOULD be at least 64 bits long and unpredictable, so that
-   an attacker cannot anticipate the value of the salt and compute the
-   next set of dictionaries before the zone is published.
-
-12.1.2.  Collisions
-
-   Hash collisions between QNAME and the owner name of an NSEC3 RR may
-   occur.  When they do, it will be impossible to prove the non-
-   existence of the colliding QNAME.  However, with SHA-1, this is
-   highly unlikely (on the order of 1 in 2^160).  Note that DNSSEC
-   already relies on the presumption that a cryptographic hash function
-   is second pre-image resistant, since these hash functions are used
-   for generating and validating signatures and DS RRs.
-
-12.1.3.  Transitioning to a New Hash Algorithm
-
-   Although the NSEC3 and NSEC3PARAM RR formats include a hash algorithm
-   parameter, this document does not define a particular mechanism for
-   safely transitioning from one NSEC3 hash algorithm to another.  When
-   specifying a new hash algorithm for use with NSEC3, a transition
-   mechanism MUST also be defined.  It is possible that the only
-   practical and palatable transition mechanisms may require an
-   intermediate transition to an insecure state, or to a state that uses
-   NSEC records instead of NSEC3.
-
-12.1.4.  Using High Iteration Values
-
-   Since validators should treat responses containing NSEC3 RRs with
-   high iteration values as insecure, presence of just one signed NSEC3
-   RR with a high iteration value in a zone provides attackers with a
-   possible downgrade attack.
-
-   The attack is simply to remove any existing NSEC3 RRs from a
-   response, and replace or add a single (or multiple) NSEC3 RR that
-   uses a high iterations value to the response.  Validators will then
-   be forced to treat the response as insecure.  This attack would be
-   effective only when all of following conditions are met:
-
-   o  There is at least one signed NSEC3 RR that uses a high iterations
-      value present in the zone.
-
-   o  The attacker has access to one or more of these NSEC3 RRs.  This
-      is trivially true when the NSEC3 RRs with high iteration values
-      are being returned in typical responses, but may also be true if
-      the attacker can access the zone via AXFR or IXFR queries, or any
-      other methodology.
-
-
-
-
-
-Laurie, et al.              Standards Track                    [Page 31]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-   Using a high number of iterations also introduces an additional
-   denial-of-service opportunity against servers, since servers must
-   calculate several hashes per negative or wildcard response.
-
-12.2.  Opt-Out Considerations
-
-   The Opt-Out Flag (O) allows for unsigned names, in the form of
-   delegations to unsigned zones, to exist within an otherwise signed
-   zone.  All unsigned names are, by definition, insecure, and their
-   validity or existence cannot be cryptographically proven.
-
-   In general:
-
-   o  Resource records with unsigned names (whether existing or not)
-      suffer from the same vulnerabilities as RRs in an unsigned zone.
-      These vulnerabilities are described in more detail in [RFC3833]
-      (note in particular Section 2.3, "Name Chaining" and Section 2.6,
-      "Authenticated Denial of Domain Names").
-
-   o  Resource records with signed names have the same security whether
-      or not Opt-Out is used.
-
-   Note that with or without Opt-Out, an insecure delegation may be
-   undetectably altered by an attacker.  Because of this, the primary
-   difference in security when using Opt-Out is the loss of the ability
-   to prove the existence or nonexistence of an insecure delegation
-   within the span of an Opt-Out NSEC3 RR.
-
-   In particular, this means that a malicious entity may be able to
-   insert or delete RRs with unsigned names.  These RRs are normally NS
-   RRs, but this also includes signed wildcard expansions (while the
-   wildcard RR itself is signed, its expanded name is an unsigned name).
-
-   Note that being able to add a delegation is functionally equivalent
-   to being able to add any RR type: an attacker merely has to forge a
-   delegation to name server under his/her control and place whatever
-   RRs 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-Out be used sparingly.
-   In particular, zone signing tools SHOULD NOT default to using Opt-
-   Out, and MAY choose to not support Opt-Out at all.
-
-
-
-
-
-
-
-
-Laurie, et al.              Standards Track                    [Page 32]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-12.3.  Other Considerations
-
-   Walking the NSEC3 RRs will reveal the total number of RRs in the zone
-   (plus empty non-terminals), and also what types there are.  This
-   could be mitigated by adding dummy entries, but certainly an upper
-   limit can always be found.
-
-13.  References
-
-13.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.
-
-   [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.
-
-   [RFC2308]         Andrews, M., "Negative Caching of DNS Queries (DNS
-                     NCACHE)", RFC 2308, March 1998.
-
-   [RFC2434]         Narten, T. and H. Alvestrand, "Guidelines for
-                     Writing an IANA Considerations Section in RFCs",
-                     BCP 26, RFC 2434, October 1998.
-
-   [RFC2929]         Eastlake, D., Brunner-Williams, E., and B. Manning,
-                     "Domain Name System (DNS) IANA Considerations",
-                     BCP 42, RFC 2929, September 2000.
-
-   [RFC3597]         Gustafsson, A., "Handling of Unknown DNS Resource
-                     Record (RR) Types", RFC 3597, September 2003.
-
-   [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.
-
-
-
-Laurie, et al.              Standards Track                    [Page 33]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-   [RFC4035]         Arends, R., Austein, R., Larson, M., Massey, D.,
-                     and S. Rose, "Protocol Modifications for the DNS
-                     Security Extensions", RFC 4035, March 2005.
-
-   [RFC4648]         Josefsson, S., "The Base16, Base32, and Base64 Data
-                     Encodings", RFC 4648, October 2006.
-
-13.2.  Informative References
-
-   [DNSEXT-NO]       Josefsson, S., "Authenticating Denial of Existence
-                     in DNS with Minimum Disclosure", Work in Progress,
-                     July 2000.
-
-   [DNSEXT-NSEC2v2]  Laurie, B., "DNSSEC NSEC2 Owner and RDATA Format",
-                     Work in Progress, December 2004.
-
-   [RFC2672]         Crawford, M., "Non-Terminal DNS Name Redirection",
-                     RFC 2672, August 1999.
-
-   [RFC2898]         Kaliski, B., "PKCS #5: Password-Based Cryptography
-                     Specification Version 2.0", RFC 2898,
-                     September 2000.
-
-   [RFC3833]         Atkins, D. and R. Austein, "Threat Analysis of the
-                     Domain Name System (DNS)", RFC 3833, August 2004.
-
-   [RFC4592]         Lewis, E., "The Role of Wildcards in the Domain
-                     Name System", RFC 4592, July 2006.
-
-   [RFC4956]         Arends, R., Kosters, M., and D. Blacka, "DNS
-                     Security (DNSSEC) Opt-In", RFC 4956, July 2007.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Laurie, et al.              Standards Track                    [Page 34]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-Appendix A.  Example Zone
-
-   This is a zone showing its NSEC3 RRs.  They can also be used as test
-   vectors for the hash algorithm.
-
-   The overall TTL and class are specified in the SOA RR, and are
-   subsequently omitted for clarity.
-
-   The zone is preceded by a list that contains the hashes of the
-   original ownernames.
-
-   ; H(example)       = 0p9mhaveqvm6t7vbl5lop2u3t2rp3tom
-   ; H(a.example)     = 35mthgpgcu1qg68fab165klnsnk3dpvl
-   ; H(ai.example)    = gjeqe526plbf1g8mklp59enfd789njgi
-   ; H(ns1.example)   = 2t7b4g4vsa5smi47k61mv5bv1a22bojr
-   ; H(ns2.example)   = q04jkcevqvmu85r014c7dkba38o0ji5r
-   ; H(w.example)     = k8udemvp1j2f7eg6jebps17vp3n8i58h
-   ; H(*.w.example)   = r53bq7cc2uvmubfu5ocmm6pers9tk9en
-   ; H(x.w.example)   = b4um86eghhds6nea196smvmlo4ors995
-   ; H(y.w.example)   = ji6neoaepv8b5o6k4ev33abha8ht9fgc
-   ; H(x.y.w.example) = 2vptu5timamqttgl4luu9kg21e0aor3s
-   ; H(xx.example)    = t644ebqk9bibcna874givr6joj62mlhv
-   ; H(2t7b4g4vsa5smi47k61mv5bv1a22bojr.example)
-   ;                  = kohar7mbb8dc2ce8a9qvl8hon4k53uhi
-   example. 3600  IN SOA  ns1.example. bugs.x.w.example. 1 3600 300 (
-                          3600000 3600 )
-                  RRSIG   SOA 7 1 3600 20150420235959 20051021000000 (
-                          40430 example.
-                          Hu25UIyNPmvPIVBrldN+9Mlp9Zql39qaUd8i
-                          q4ZLlYWfUUbbAS41pG+68z81q1xhkYAcEyHd
-                          VI2LmKusbZsT0Q== )
-                  NS      ns1.example.
-                  NS      ns2.example.
-                  RRSIG   NS 7 1 3600 20150420235959 20051021000000 (
-                          40430 example.
-                          PVOgtMK1HHeSTau+HwDWC8Ts+6C8qtqd4pQJ
-                          qOtdEVgg+MA+ai4fWDEhu3qHJyLcQ9tbD2vv
-                          CnMXjtz6SyObxA== )
-                  MX      1 xx.example.
-                  RRSIG   MX 7 1 3600 20150420235959 20051021000000 (
-                          40430 example.
-                          GgQ1A9xs47k42VPvpL/a1BWUz/6XsnHkjotw
-                          9So8MQtZtl2wJBsnOQsaoHrRCrRbyriEl/GZ
-                          n9Mto/Kx+wBo+w== )
-                  DNSKEY  256 3 7 AwEAAaetidLzsKWUt4swWR8yu0wPHPiUi8LU (
-                          sAD0QPWU+wzt89epO6tHzkMBVDkC7qphQO2h
-                          TY4hHn9npWFRw5BYubE= )
-
-
-
-
-Laurie, et al.              Standards Track                    [Page 35]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-                  DNSKEY  257 3 7 AwEAAcUlFV1vhmqx6NSOUOq2R/dsR7Xm3upJ (
-                          j7IommWSpJABVfW8Q0rOvXdM6kzt+TAu92L9
-                          AbsUdblMFin8CVF3n4s= )
-                  RRSIG   DNSKEY 7 1 3600 20150420235959 (
-                          20051021000000 12708 example.
-                          AuU4juU9RaxescSmStrQks3Gh9FblGBlVU31
-                          uzMZ/U/FpsUb8aC6QZS+sTsJXnLnz7flGOsm
-                          MGQZf3bH+QsCtg== )
-                  NSEC3PARAM 1 0 12 aabbccdd
-                  RRSIG   NSEC3PARAM 7 1 3600 20150420235959 (
-                          20051021000000 40430 example.
-                          C1Gl8tPZNtnjlrYWDeeUV/sGLCyy/IHie2re
-                          rN05XSA3Pq0U3+4VvGWYWdUMfflOdxqnXHwJ
-                          TLQsjlkynhG6Cg== )
-   0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. NSEC3 1 1 12 aabbccdd (
-                          2t7b4g4vsa5smi47k61mv5bv1a22bojr MX DNSKEY NS
-                          SOA NSEC3PARAM RRSIG )
-                  RRSIG   NSEC3 7 2 3600 20150420235959 20051021000000 (
-                          40430 example.
-                          OSgWSm26B+cS+dDL8b5QrWr/dEWhtCsKlwKL
-                          IBHYH6blRxK9rC0bMJPwQ4mLIuw85H2EY762
-                          BOCXJZMnpuwhpA== )
-   2t7b4g4vsa5smi47k61mv5bv1a22bojr.example. A 192.0.2.127
-                  RRSIG   A 7 2 3600 20150420235959 20051021000000 (
-                          40430 example.
-                          h6c++bzhRuWWt2bykN6mjaTNBcXNq5UuL5Ed
-                          K+iDP4eY8I0kSiKaCjg3tC1SQkeloMeub2GW
-                          k8p6xHMPZumXlw== )
-                  NSEC3   1 1 12 aabbccdd (
-                          2vptu5timamqttgl4luu9kg21e0aor3s A RRSIG )
-                  RRSIG   NSEC3 7 2 3600 20150420235959 20051021000000 (
-                          40430 example.
-                          OmBvJ1Vgg1hCKMXHFiNeIYHK9XVW0iLDLwJN
-                          4TFoNxZuP03gAXEI634YwOc4YBNITrj413iq
-                          NI6mRk/r1dOSUw== )
-   2vptu5timamqttgl4luu9kg21e0aor3s.example. NSEC3 1 1 12 aabbccdd (
-                          35mthgpgcu1qg68fab165klnsnk3dpvl MX RRSIG )
-                  RRSIG   NSEC3 7 2 3600 20150420235959 20051021000000 (
-                          40430 example.
-                          KL1V2oFYghNV0Hm7Tf2vpJjM6l+0g1JCcVYG
-                          VfI0lKrhPmTsOA96cLEACgo1x8I7kApJX+ob
-                          TuktZ+sdsZPY1w== )
-   35mthgpgcu1qg68fab165klnsnk3dpvl.example. NSEC3 1 1 12 aabbccdd (
-                          b4um86eghhds6nea196smvmlo4ors995 NS DS RRSIG )
-
-
-
-
-
-
-
-Laurie, et al.              Standards Track                    [Page 36]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-                  RRSIG   NSEC3 7 2 3600 20150420235959 20051021000000 (
-                          40430 example.
-                          g6jPUUpduAJKRljUsN8gB4UagAX0NxY9shwQ
-                          Aynzo8EUWH+z6hEIBlUTPGj15eZll6VhQqgZ
-                          XtAIR3chwgW+SA== )
-   a.example.     NS      ns1.a.example.
-                  NS      ns2.a.example.
-                  DS      58470 5 1 (
-                          3079F1593EBAD6DC121E202A8B766A6A4837206C )
-                  RRSIG   DS 7 2 3600 20150420235959 20051021000000 (
-                          40430 example.
-                          XacFcQVHLVzdoc45EJhN616zQ4mEXtE8FzUh
-                          M2KWjfy1VfRKD9r1MeVGwwoukOKgJxBPFsWo
-                          o722vZ4UZ2dIdA== )
-   ns1.a.example. A       192.0.2.5
-   ns2.a.example. A       192.0.2.6
-   ai.example.    A       192.0.2.9
-                  RRSIG   A 7 2 3600 20150420235959 20051021000000 (
-                          40430 example.
-                          hVe+wKYMlObTRPhX0NL67GxeZfdxqr/QeR6F
-                          tfdAj5+FgYxyzPEjIzvKWy00hWIl6wD3Vws+
-                          rznEn8sQ64UdqA== )
-                  HINFO   "KLH-10" "ITS"
-                  RRSIG   HINFO 7 2 3600 20150420235959 20051021000000 (
-                          40430 example.
-                          Yi42uOq43eyO6qXHNvwwfFnIustWgV5urFcx
-                          enkLvs6pKRh00VBjODmf3Z4nMO7IOl6nHSQ1
-                          v0wLHpEZG7Xj2w== )
-                  AAAA    2001:db8:0:0:0:0:f00:baa9
-                  RRSIG   AAAA 7 2 3600 20150420235959 20051021000000 (
-                          40430 example.
-                          LcdxKaCB5bGZwPDg+3JJ4O02zoMBrjxqlf6W
-                          uaHQZZfTUpb9Nf2nxFGe2XRPfR5tpJT6GdRG
-                          cHueLuXkMjBArQ== )
-   b4um86eghhds6nea196smvmlo4ors995.example. NSEC3 1 1 12 aabbccdd (
-                          gjeqe526plbf1g8mklp59enfd789njgi MX RRSIG )
-                  RRSIG   NSEC3 7 2 3600 20150420235959 20051021000000 (
-                          40430 example.
-                          ZkPG3M32lmoHM6pa3D6gZFGB/rhL//Bs3Omh
-                          5u4m/CUiwtblEVOaAKKZd7S959OeiX43aLX3
-                          pOv0TSTyiTxIZg== )
-   c.example.     NS      ns1.c.example.
-                  NS      ns2.c.example.
-   ns1.c.example. A       192.0.2.7
-   ns2.c.example. A       192.0.2.8
-   gjeqe526plbf1g8mklp59enfd789njgi.example. NSEC3 1 1 12 aabbccdd (
-                          ji6neoaepv8b5o6k4ev33abha8ht9fgc HINFO A AAAA
-                          RRSIG )
-
-
-
-Laurie, et al.              Standards Track                    [Page 37]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-                  RRSIG   NSEC3 7 2 3600 20150420235959 20051021000000 (
-                          40430 example.
-                          IVnezTJ9iqblFF97vPSmfXZ5Zozngx3KX3by
-                          LTZC4QBH2dFWhf6scrGFZB980AfCxoD9qbbK
-                          Dy+rdGIeRSVNyw== )
-   ji6neoaepv8b5o6k4ev33abha8ht9fgc.example. NSEC3 1 1 12 aabbccdd (
-                          k8udemvp1j2f7eg6jebps17vp3n8i58h )
-                  RRSIG   NSEC3 7 2 3600 20150420235959 20051021000000 (
-                          40430 example.
-                          gPkFp1s2QDQ6wQzcg1uSebZ61W33rUBDcTj7
-                          2F3kQ490fEdp7k1BUIfbcZtPbX3YCpE+sIt0
-                          MpzVSKfTwx4uYA== )
-   k8udemvp1j2f7eg6jebps17vp3n8i58h.example. NSEC3 1 1 12 aabbccdd (
-                          kohar7mbb8dc2ce8a9qvl8hon4k53uhi )
-                  RRSIG   NSEC3 7 2 3600 20150420235959 20051021000000 (
-                          40430 example.
-                          FtXGbvF0+wf8iWkyo73enAuVx03klN+pILBK
-                          S6qCcftVtfH4yVzsEZquJ27NHR7ruxJWDNMt
-                          Otx7w9WfcIg62A== )
-   kohar7mbb8dc2ce8a9qvl8hon4k53uhi.example. NSEC3 1 1 12 aabbccdd (
-                          q04jkcevqvmu85r014c7dkba38o0ji5r A RRSIG )
-                  RRSIG   NSEC3 7 2 3600 20150420235959 20051021000000 (
-                          40430 example.
-                          VrDXs2uVW21N08SyQIz88zml+y4ZCInTwgDr
-                          6zz43yAg+LFERjOrj3Ojct51ac7Dp4eZbf9F
-                          QJazmASFKGxGXg== )
-   ns1.example.   A       192.0.2.1
-                  RRSIG   A 7 2 3600 20150420235959 20051021000000 (
-                          40430 example.
-                          bu6kx73n6XEunoVGuRfAgY7EF/AJqHy7hj0j
-                          kiqJjB0dOrx3wuz9SaBeGfqWIdn/uta3SavN
-                          4FRvZR9SCFHF5Q== )
-   ns2.example.   A       192.0.2.2
-                  RRSIG   A 7 2 3600 20150420235959 20051021000000 (
-                          40430 example.
-                          ktQ3TqE0CfRfki0Rb/Ip5BM0VnxelbuejCC4
-                          zpLbFKA/7eD7UNAwxMgxJPtbdST+syjYSJaj
-                          4IHfeX6n8vfoGA== )
-   q04jkcevqvmu85r014c7dkba38o0ji5r.example. NSEC3 1 1 12 aabbccdd (
-                          r53bq7cc2uvmubfu5ocmm6pers9tk9en A RRSIG )
-                  RRSIG   NSEC3 7 2 3600 20150420235959 20051021000000 (
-                          40430 example.
-                          hV5I89b+4FHJDATp09g4bbN0R1F845CaXpL3
-                          ZxlMKimoPAyqletMlEWwLfFia7sdpSzn+ZlN
-                          NlkxWcLsIlMmUg== )
-
-
-
-
-
-
-Laurie, et al.              Standards Track                    [Page 38]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-   r53bq7cc2uvmubfu5ocmm6pers9tk9en.example. NSEC3 1 1 12 aabbccdd (
-                          t644ebqk9bibcna874givr6joj62mlhv MX RRSIG )
-                  RRSIG   NSEC3 7 2 3600 20150420235959 20051021000000 (
-                          40430 example.
-                          aupviViruXs4bDg9rCbezzBMf9h1ZlDvbW/C
-                          ZFKulIGXXLj8B/fsDJarXVDA9bnUoRhEbKp+
-                          HF1FWKW7RIJdtQ== )
-   t644ebqk9bibcna874givr6joj62mlhv.example. NSEC3 1 1 12 aabbccdd (
-                          0p9mhaveqvm6t7vbl5lop2u3t2rp3tom HINFO A AAAA
-                          RRSIG )
-                  RRSIG   NSEC3 7 2 3600 20150420235959 20051021000000 (
-                          40430 example.
-                          RAjGECB8P7O+F4Pa4Dx3tC0M+Z3KmlLKImca
-                          fb9XWwx+NWUNz7NBEDBQHivIyKPVDkChcePI
-                          X1xPl1ATNa+8Dw== )
-   *.w.example.   MX      1 ai.example.
-                  RRSIG   MX 7 2 3600 20150420235959 20051021000000 (
-                          40430 example.
-                          CikebjQwGQPwijVcxgcZcSJKtfynugtlBiKb
-                          9FcBTrmOoyQ4InoWVudhCWsh/URX3lc4WRUM
-                          ivEBP6+4KS3ldA== )
-   x.w.example.   MX      1 xx.example.
-                  RRSIG   MX 7 3 3600 20150420235959 20051021000000 (
-                          40430 example.
-                          IrK3tq/tHFIBF0scHiE/1IwMAvckS/55hAVv
-                          QyxTFbkAdDloP3NbZzu+yoSsr3b3OX6qbBpY
-                          7WCtwwekLKRAwQ== )
-   x.y.w.example. MX      1 xx.example.
-                  RRSIG   MX 7 4 3600 20150420235959 20051021000000 (
-                          40430 example.
-                          MqSt5HqJIN8+SLlzTOImrh5h9Xa6gDvAW/Gn
-                          nbdPc6Z7nXvCpLPJj/5lCwx3VuzVOjkbvXze
-                          8/8Ccl2Zn2hbug== )
-   xx.example.    A       192.0.2.10
-                  RRSIG   A 7 2 3600 20150420235959 20051021000000 (
-                          40430 example.
-                          T35hBWEZ017VC5u2c4OriKyVn/pu+fVK4AlX
-                          YOxJ6iQylfV2HQIKjv6b7DzINB3aF/wjJqgX
-                          pQvhq+Ac6+ZiFg== )
-                  HINFO   "KLH-10" "TOPS-20"
-                  RRSIG   HINFO 7 2 3600 20150420235959 20051021000000 (
-                          40430 example.
-                          KimG+rDd+7VA1zRsu0ITNAQUTRlpnsmqWrih
-                          FRnU+bRa93v2e5oFNFYCs3Rqgv62K93N7AhW
-                          6Jfqj/8NzWjvKg== )
-                  AAAA    2001:db8:0:0:0:0:f00:baaa
-
-
-
-
-
-Laurie, et al.              Standards Track                    [Page 39]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-                  RRSIG   AAAA 7 2 3600 20150420235959 20051021000000 (
-                          40430 example.
-                          IXBcXORITNwd8h3gNwyxtYFvAupS/CYWufVe
-                          uBUX0O25ivBCULjZjpDxFSxfohb/KA7YRdxE
-                          NzYfMItpILl/Xw== )
-
-Appendix B.  Example Responses
-
-   The examples in this section show response messages using the signed
-   zone example in Appendix A.
-
-B.1.  Name Error
-
-   An authoritative name error.  The NSEC3 RRs prove that the name does
-   not exist and that there is no wildcard RR that should have been
-   expanded.
-
-;; Header: QR AA DO RCODE=3
-;;
-;; Question
-a.c.x.w.example.         IN A
-
-;; Answer
-;; (empty)
-
-;; Authority
-
-example.       SOA     ns1.example. bugs.x.w.example. 1 3600 300 (
-                       3600000 3600 )
-example.       RRSIG   SOA 7 1 3600 20150420235959 20051021000000 (
-                       40430 example.
-                       Hu25UIyNPmvPIVBrldN+9Mlp9Zql39qaUd8i
-                       q4ZLlYWfUUbbAS41pG+68z81q1xhkYAcEyHd
-                       VI2LmKusbZsT0Q== )
-
-;; NSEC3 RR that covers the "next closer" name (c.x.w.example)
-;; H(c.x.w.example) = 0va5bpr2ou0vk0lbqeeljri88laipsfh
-
-0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. NSEC3 1 1 12 aabbccdd (
-                       2t7b4g4vsa5smi47k61mv5bv1a22bojr MX DNSKEY NS
-                       SOA NSEC3PARAM RRSIG )
-0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. RRSIG NSEC3 7 2 3600 (
-                       20150420235959 20051021000000 40430 example.
-                       OSgWSm26B+cS+dDL8b5QrWr/dEWhtCsKlwKL
-                       IBHYH6blRxK9rC0bMJPwQ4mLIuw85H2EY762
-                       BOCXJZMnpuwhpA== )
-
-
-
-
-
-Laurie, et al.              Standards Track                    [Page 40]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-;; NSEC3 RR that matches the closest encloser (x.w.example)
-;; H(x.w.example) = b4um86eghhds6nea196smvmlo4ors995
-
-b4um86eghhds6nea196smvmlo4ors995.example. NSEC3 1 1 12 aabbccdd (
-                       gjeqe526plbf1g8mklp59enfd789njgi MX RRSIG )
-b4um86eghhds6nea196smvmlo4ors995.example. RRSIG NSEC3 7 2 3600 (
-                       20150420235959 20051021000000 40430 example.
-                       ZkPG3M32lmoHM6pa3D6gZFGB/rhL//Bs3Omh
-                       5u4m/CUiwtblEVOaAKKZd7S959OeiX43aLX3
-                       pOv0TSTyiTxIZg== )
-
-;; NSEC3 RR that covers wildcard at the closest encloser (*.x.w.example)
-;; H(*.x.w.example) = 92pqneegtaue7pjatc3l3qnk738c6v5m
-
-35mthgpgcu1qg68fab165klnsnk3dpvl.example. NSEC3 1 1 12 aabbccdd (
-                       b4um86eghhds6nea196smvmlo4ors995 NS DS RRSIG )
-35mthgpgcu1qg68fab165klnsnk3dpvl.example. RRSIG NSEC3 7 2 3600 (
-                       20150420235959 20051021000000 40430 example.
-                       g6jPUUpduAJKRljUsN8gB4UagAX0NxY9shwQ
-                       Aynzo8EUWH+z6hEIBlUTPGj15eZll6VhQqgZ
-                       XtAIR3chwgW+SA== )
-
-;; Additional
-;; (empty)
-
-   The query returned three NSEC3 RRs that prove that the requested data
-   does not exist and that no wildcard expansion applies.  The negative
-   response is authenticated by verifying the NSEC3 RRs.  The
-   corresponding RRSIGs indicate that the NSEC3 RRs are signed by an
-   "example" DNSKEY of algorithm 7 and with key tag 40430.  The resolver
-   needs the corresponding DNSKEY RR in order to authenticate this
-   answer.
-
-   One of the owner names of the NSEC3 RRs matches the closest encloser.
-   One of the NSEC3 RRs prove that there exists no longer name.  One of
-   the NSEC3 RRs prove that there exists no wildcard RRSets that should
-   have been expanded.  The closest encloser can be found by applying
-   the algorithm in Section 8.3.
-
-   In the above example, the name 'x.w.example' hashes to
-   'b4um86eghhds6nea196smvmlo4ors995'.  This indicates that this might
-   be the closest encloser.  To prove that 'c.x.w.example' and
-   '*.x.w.example' do not exist, these names are hashed to,
-   respectively, '0va5bpr2ou0vk0lbqeeljri88laipsfh' and
-   '92pqneegtaue7pjatc3l3qnk738c6v5m'.  The first and last NSEC3 RRs
-   prove that these hashed owner names do not exist.
-
-
-
-
-
-Laurie, et al.              Standards Track                    [Page 41]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-B.2.  No Data Error
-
-   A "no data" response.  The NSEC3 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.       SOA     ns1.example. bugs.x.w.example. 1 3600 300 (
-                       3600000 3600 )
-example.       RRSIG   SOA 7 1 3600 20150420235959 20051021000000 (
-                       40430 example.
-                       Hu25UIyNPmvPIVBrldN+9Mlp9Zql39qaUd8i
-                       q4ZLlYWfUUbbAS41pG+68z81q1xhkYAcEyHd
-                       VI2LmKusbZsT0Q== )
-
-;; NSEC3 RR matches the QNAME and shows that the MX type bit is not set.
-
-2t7b4g4vsa5smi47k61mv5bv1a22bojr.example. NSEC3 1 1 12 aabbccdd (
-                       2vptu5timamqttgl4luu9kg21e0aor3s A RRSIG )
-2t7b4g4vsa5smi47k61mv5bv1a22bojr.example. RRSIG NSEC3 7 2 3600 (
-                       20150420235959 20051021000000 40430 example.
-                       OmBvJ1Vgg1hCKMXHFiNeIYHK9XVW0iLDLwJN
-                       4TFoNxZuP03gAXEI634YwOc4YBNITrj413iq
-                       NI6mRk/r1dOSUw== )
-;; Additional
-;; (empty)
-
-   The query returned an NSEC3 RR that proves that the requested name
-   exists ("ns1.example." hashes to "2t7b4g4vsa5smi47k61mv5bv1a22bojr"),
-   but the requested RR type does not exist (type MX is absent in the
-   type code list of the NSEC3 RR), and was not a CNAME (type CNAME is
-   also absent in the type code list of the NSEC3 RR).
-
-
-
-
-
-
-
-
-
-
-
-
-Laurie, et al.              Standards Track                    [Page 42]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-B.2.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.
-
- ;; Header: QR AA DO RCODE=0
- ;;
- ;; Question
- y.w.example.        IN A
-
- ;; Answer
- ;; (empty)
-
- ;; Authority
- example.       SOA     ns1.example. bugs.x.w.example. 1 3600 300 (
-                        3600000 3600 )
- example.       RRSIG   SOA 7 1 3600 20150420235959 20051021000000 (
-                        40430 example.
-                        Hu25UIyNPmvPIVBrldN+9Mlp9Zql39qaUd8i
-                        q4ZLlYWfUUbbAS41pG+68z81q1xhkYAcEyHd
-                        VI2LmKusbZsT0Q== )
-
- ;; NSEC3 RR matches the QNAME and shows that the A type bit is not set.
-
- ji6neoaepv8b5o6k4ev33abha8ht9fgc.example. NSEC3 1 1 12 aabbccdd (
-                        k8udemvp1j2f7eg6jebps17vp3n8i58h )
- ji6neoaepv8b5o6k4ev33abha8ht9fgc.example. RRSIG NSEC3 7 2 3600 (
-                        20150420235959 20051021000000 40430 example.
-                        gPkFp1s2QDQ6wQzcg1uSebZ61W33rUBDcTj7
-                        2F3kQ490fEdp7k1BUIfbcZtPbX3YCpE+sIt0
-                        MpzVSKfTwx4uYA== )
-
- ;; Additional
- ;; (empty)
-
-   The query returned an NSEC3 RR that proves that the requested name
-   exists ("y.w.example." hashes to "ji6neoaepv8b5o6k4ev33abha8ht9fgc"),
-   but the requested RR type does not exist (Type A is absent in the
-   Type Bit Maps field of the NSEC3 RR).  Note that, unlike an empty
-   non-terminal proof using NSECs, this is identical to a No Data Error.
-   This example is solely mentioned to be complete.
-
-
-
-
-
-
-
-
-
-
-Laurie, et al.              Standards Track                    [Page 43]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-B.3.  Referral to an Opt-Out Unsigned Zone
-
-   The NSEC3 RRs prove that nothing for this delegation was signed.
-   There is no proof that the unsigned delegation exists.
-
-   ;; Header: QR DO RCODE=0
-   ;;
-   ;; Question
-   mc.c.example.       IN MX
-
-   ;; Answer
-   ;; (empty)
-
-   ;; Authority
-   c.example.     NS      ns1.c.example.
-                  NS      ns2.c.example.
-
-   ;; NSEC3 RR that covers the "next closer" name (c.example)
-   ;; H(c.example) = 4g6p9u5gvfshp30pqecj98b3maqbn1ck
-
-   35mthgpgcu1qg68fab165klnsnk3dpvl.example. NSEC3 1 1 12 aabbccdd (
-                          b4um86eghhds6nea196smvmlo4ors995 NS DS RRSIG )
-   35mthgpgcu1qg68fab165klnsnk3dpvl.example. RRSIG NSEC3 7 2 3600 (
-                          20150420235959 20051021000000 40430 example.
-                          g6jPUUpduAJKRljUsN8gB4UagAX0NxY9shwQ
-                          Aynzo8EUWH+z6hEIBlUTPGj15eZll6VhQqgZ
-                          XtAIR3chwgW+SA== )
-
-   ;; NSEC3 RR that matches the closest encloser (example)
-   ;; H(example) = 0p9mhaveqvm6t7vbl5lop2u3t2rp3tom
-
-   0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. NSEC3 1 1 12 aabbccdd (
-                          2t7b4g4vsa5smi47k61mv5bv1a22bojr MX DNSKEY NS
-                          SOA NSEC3PARAM RRSIG )
-   0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. RRSIG NSEC3 7 2 3600 (
-                          20150420235959 20051021000000 40430 example.
-                          OSgWSm26B+cS+dDL8b5QrWr/dEWhtCsKlwKL
-                          IBHYH6blRxK9rC0bMJPwQ4mLIuw85H2EY762
-                          BOCXJZMnpuwhpA== )
-
-   ;; Additional
-   ns1.c.example. A       192.0.2.7
-   ns2.c.example. A       192.0.2.8
-
-   The query returned a referral to the unsigned "c.example." zone.  The
-   response contains the closest provable encloser of "c.example" to be
-   "example", since the hash of "c.example"
-
-
-
-
-Laurie, et al.              Standards Track                    [Page 44]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-   ("4g6p9u5gvfshp30pqecj98b3maqbn1ck") is covered by the first NSEC3 RR
-   and its Opt-Out bit is set.
-
-B.4.  Wildcard Expansion
-
-   A query that was answered with a response containing a wildcard
-   expansion.  The label count in the RRSIG RRSet in the answer section
-   indicates that a wildcard RRSet was expanded to produce this
-   response, and the NSEC3 RR proves that no "next closer" name exists
-   in the zone.
-
-   ;; Header: QR AA DO RCODE=0
-   ;;
-   ;; Question
-   a.z.w.example. IN MX
-
-   ;; Answer
-   a.z.w.example. MX      1 ai.example.
-   a.z.w.example. RRSIG   MX 7 2 3600 20150420235959 20051021000000 (
-                          40430 example.
-                          CikebjQwGQPwijVcxgcZcSJKtfynugtlBiKb
-                          9FcBTrmOoyQ4InoWVudhCWsh/URX3lc4WRUM
-                          ivEBP6+4KS3ldA== )
-
-   ;; Authority
-   example.       NS      ns1.example.
-   example.       NS      ns2.example.
-   example.       RRSIG   NS 7 1 3600 20150420235959 20051021000000 (
-                          40430 example.
-                          PVOgtMK1HHeSTau+HwDWC8Ts+6C8qtqd4pQJ
-                          qOtdEVgg+MA+ai4fWDEhu3qHJyLcQ9tbD2vv
-                          CnMXjtz6SyObxA== )
-
-   ;; NSEC3 RR that covers the "next closer" name (z.w.example)
-   ;; H(z.w.example) = qlu7gtfaeh0ek0c05ksfhdpbcgglbe03
-
-   q04jkcevqvmu85r014c7dkba38o0ji5r.example. NSEC3 1 1 12 aabbccdd (
-                          r53bq7cc2uvmubfu5ocmm6pers9tk9en A RRSIG )
-   q04jkcevqvmu85r014c7dkba38o0ji5r.example. RRSIG NSEC3 7 2 3600 (
-                          20150420235959 20051021000000 40430 example.
-                          hV5I89b+4FHJDATp09g4bbN0R1F845CaXpL3
-                          ZxlMKimoPAyqletMlEWwLfFia7sdpSzn+ZlN
-                          NlkxWcLsIlMmUg== )
-
-
-
-
-
-
-
-
-Laurie, et al.              Standards Track                    [Page 45]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-   ;; Additional
-   ai.example.    A       192.0.2.9
-   ai.example.    RRSIG   A 7 2 3600 20150420235959 20051021000000 (
-                          40430 example.
-                          hVe+wKYMlObTRPhX0NL67GxeZfdxqr/QeR6F
-                          tfdAj5+FgYxyzPEjIzvKWy00hWIl6wD3Vws+
-                          rznEn8sQ64UdqA== )
-   ai.example.    AAAA    2001:db8:0:0:0:0:f00:baa9
-   ai.example.    RRSIG   AAAA 7 2 3600 20150420235959 20051021000000 (
-                          40430 example.
-                          LcdxKaCB5bGZwPDg+3JJ4O02zoMBrjxqlf6W
-                          uaHQZZfTUpb9Nf2nxFGe2XRPfR5tpJT6GdRG
-                          cHueLuXkMjBArQ== )
-
-   The query returned an answer that was produced as a result of a
-   wildcard expansion.  The answer section contains a wildcard RRSet
-   expanded as it would be in a traditional DNS response.  The RRSIG
-   Labels field value of 2 indicates that the answer is the result of a
-   wildcard expansion, as the "a.z.w.example" name contains 4 labels.
-   This also shows that "w.example" exists, so there is no need for an
-   NSEC3 RR that matches the closest encloser.
-
-   The NSEC3 RR proves that no closer match could have been used to
-   answer this query.
-
-B.5.  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.
-
-   ;; Header: QR AA DO RCODE=0
-   ;;
-   ;; Question
-   a.z.w.example.      IN AAAA
-
-   ;; Answer
-   ;; (empty)
-
-   ;; Authority
-   example.       SOA     ns1.example. bugs.x.w.example. 1 3600 300 (
-                          3600000 3600 )
-   example.       RRSIG   SOA 7 1 3600 20150420235959 20051021000000 (
-                          40430 example.
-                          Hu25UIyNPmvPIVBrldN+9Mlp9Zql39qaUd8i
-                          q4ZLlYWfUUbbAS41pG+68z81q1xhkYAcEyHd
-                          VI2LmKusbZsT0Q== )
-
-
-
-
-Laurie, et al.              Standards Track                    [Page 46]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-   ;; NSEC3 RR that matches the closest encloser (w.example)
-   ;; H(w.example) = k8udemvp1j2f7eg6jebps17vp3n8i58h
-
-   k8udemvp1j2f7eg6jebps17vp3n8i58h.example. NSEC3 1 1 12 aabbccdd (
-                          kohar7mbb8dc2ce8a9qvl8hon4k53uhi )
-   k8udemvp1j2f7eg6jebps17vp3n8i58h.example. RRSIG NSEC3 7 2 3600 (
-                          20150420235959 20051021000000 40430 example.
-                          FtXGbvF0+wf8iWkyo73enAuVx03klN+pILBK
-                          S6qCcftVtfH4yVzsEZquJ27NHR7ruxJWDNMt
-                          Otx7w9WfcIg62A== )
-
-   ;; NSEC3 RR that covers the "next closer" name (z.w.example)
-   ;; H(z.w.example) = qlu7gtfaeh0ek0c05ksfhdpbcgglbe03
-
-   q04jkcevqvmu85r014c7dkba38o0ji5r.example. NSEC3 1 1 12 aabbccdd (
-                          r53bq7cc2uvmubfu5ocmm6pers9tk9en A RRSIG )
-   q04jkcevqvmu85r014c7dkba38o0ji5r.example. RRSIG NSEC3 7 2 3600 (
-                          20150420235959 20051021000000 40430 example.
-                          hV5I89b+4FHJDATp09g4bbN0R1F845CaXpL3
-                          ZxlMKimoPAyqletMlEWwLfFia7sdpSzn+ZlN
-                          NlkxWcLsIlMmUg== )
-
-   ;; NSEC3 RR that matches a wildcard at the closest encloser.
-   ;; H(*.w.example) = r53bq7cc2uvmubfu5ocmm6pers9tk9en
-
-   r53bq7cc2uvmubfu5ocmm6pers9tk9en.example. NSEC3 1 1 12 aabbccdd (
-                          t644ebqk9bibcna874givr6joj62mlhv MX RRSIG )
-   r53bq7cc2uvmubfu5ocmm6pers9tk9en.example. RRSIG NSEC3 7 2 3600 (
-                          20150420235959 20051021000000 40430 example.
-                          aupviViruXs4bDg9rCbezzBMf9h1ZlDvbW/C
-                          ZFKulIGXXLj8B/fsDJarXVDA9bnUoRhEbKp+
-                          HF1FWKW7RIJdtQ== )
-
-   ;; Additional
-   ;; (empty)
-
-   The query returned the NSEC3 RRs that prove that the requested data
-   does not exist and no wildcard RR applies.
-
-
-
-
-
-
-
-
-
-
-
-
-
-Laurie, et al.              Standards Track                    [Page 47]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-B.6.  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.       SOA     ns1.example. bugs.x.w.example. 1 3600 300 (
-                       3600000 3600 )
-example.       RRSIG   SOA 7 1 3600 20150420235959 20051021000000 (
-                       40430 example.
-                       Hu25UIyNPmvPIVBrldN+9Mlp9Zql39qaUd8i
-                       q4ZLlYWfUUbbAS41pG+68z81q1xhkYAcEyHd
-                       VI2LmKusbZsT0Q== )
-
-;; NSEC3 RR matches the QNAME and shows that the DS type bit is not set.
-
-0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. NSEC3 1 1 12 aabbccdd (
-                       2t7b4g4vsa5smi47k61mv5bv1a22bojr MX DNSKEY NS
-                       SOA NSEC3PARAM RRSIG )
-0p9mhaveqvm6t7vbl5lop2u3t2rp3tom.example. RRSIG NSEC3 7 2 3600
-                       20150420235959 20051021000000 40430 example.
-                       OSgWSm26B+cS+dDL8b5QrWr/dEWhtCsKlwKL
-                       IBHYH6blRxK9rC0bMJPwQ4mLIuw85H2EY762
-                       BOCXJZMnpuwhpA== )
-
-;; Additional
-;; (empty)
-
-   The query returned an NSEC3 RR showing that the requested was
-   answered by the server authoritative for the zone "example".  The
-   NSEC3 RR indicates the presence of an SOA RR, showing that this NSEC3
-   RR is from the apex of the child, not from the zone cut of the
-   parent.  Queries for the "example" DS RRSet should be sent to the
-   parent servers (which are in this case the root servers).
-
-Appendix C.  Special Considerations
-
-   The following paragraphs clarify specific behavior and explain
-   special considerations for implementations.
-
-
-
-
-Laurie, et al.              Standards Track                    [Page 48]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-C.1.  Salting
-
-   Augmenting original owner names 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.
-
-   Including a salt, regardless of size, does not affect the cost of
-   constructing NSEC3 RRs.  It does increase the size of the NSEC3 RR.
-
-   There MUST be at least one complete set of NSEC3 RRs for the zone
-   using the same salt value.
-
-   The salt SHOULD be changed periodically to prevent pre-computation
-   using a single salt.  It is RECOMMENDED that the salt be changed for
-   every re-signing.
-
-   Note that this could cause a resolver to see RRs with different salt
-   values for the same zone.  This is harmless, since each RR stands
-   alone (that is, it denies the set of owner names whose hashes, using
-   the salt in the NSEC3 RR, fall between the two hashes in the NSEC3
-   RR) -- it is only the server that needs a complete set of NSEC3 RRs
-   with the same salt in order to be able to answer every possible
-   query.
-
-   There is no prohibition with having NSEC3 RRs 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 NSEC3 RRs.
-
-C.2.  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.
-
-
-
-
-
-
-
-Laurie, et al.              Standards Track                    [Page 49]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-C.2.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.
-
-C.2.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 that
-   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
-   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 that does not yet exist.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Laurie, et al.              Standards Track                    [Page 50]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-Authors' Addresses
-
-   Ben Laurie
-   Nominet
-   17 Perryn Road
-   London  W3 7LR
-   England
-
-   Phone: +44 20 8735 0686
-   EMail: ben@links.org
-
-
-   Geoffrey Sisson
-   Nominet
-   Minerva House
-   Edmund Halley Road
-   Oxford Science Park
-   Oxford  OX4 4DQ
-   UNITED KINGDOM
-
-   Phone: +44 1865 332211
-   EMail: geoff-s@panix.com
-
-
-   Roy Arends
-   Nominet
-   Minerva House
-   Edmund Halley Road
-   Oxford Science Park
-   Oxford  OX4 4DQ
-   UNITED KINGDOM
-
-   Phone: +44 1865 332211
-   EMail: roy@nominet.org.uk
-
-
-   David Blacka
-   VeriSign, Inc.
-   21355 Ridgetop Circle
-   Dulles, VA  20166
-   US
-
-   Phone: +1 703 948 3200
-   EMail: davidb@verisign.com
-
-
-
-
-
-
-
-Laurie, et al.              Standards Track                    [Page 51]
-
-RFC 5155                         NSEC3                        March 2008
-
-
-Full Copyright Statement
-
-   Copyright (C) The IETF Trust (2008).
-
-   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, THE IETF TRUST 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.
-
-
-
-
-
-
-
-
-
-
-
-
-Laurie, et al.              Standards Track                    [Page 52]
-
diff --git a/doc/rfc/rfc952.txt b/doc/rfc/rfc952.txt
deleted file mode 100644
index 7df339a..0000000
--- a/doc/rfc/rfc952.txt
+++ /dev/null
@@ -1,340 +0,0 @@
-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]
-