111 files changed, 111706 insertions, 0 deletions

diff --git a/doc/rfc/fetch b/doc/rfc/fetch
new file mode 100755
index 0000000..17ce40f
--- /dev/null
+++ b/doc/rfc/fetch
@@ -0,0 +1,6 @@
+#!/bin/sh -f
+for i in $*
+do
+	i=`echo $i | sed -e 's/^rfc//' -e 's/\.txt$//'`
+	fetch "http://www.ietf.org/rfc/rfc${i}.txt"
+done
diff --git a/doc/rfc/index b/doc/rfc/index
new file mode 100644
index 0000000..fea5f71
--- /dev/null
+++ b/doc/rfc/index
@@ -0,0 +1,119 @@
+ 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
new file mode 100644
index 0000000..0e82721
--- /dev/null
+++ b/doc/rfc/rfc1032.txt
@@ -0,0 +1,781 @@
+Network Working Group                                       M. Stahl
+Request for Comments: 1032                         SRI International
+                                                       November 1987
+
+
+                      DOMAIN ADMINISTRATORS GUIDE
+
+
+STATUS OF THIS MEMO
+
+   This memo describes procedures for registering a domain with the
+   Network Information Center (NIC) of Defense Data Network (DDN), and
+   offers guidelines on the establishment and administration of a domain
+   in accordance with the requirements specified in RFC-920.  It is
+   intended for use by domain administrators.  This memo should be used
+   in conjunction with RFC-920, which is an official policy statement of
+   the Internet Activities Board (IAB) and the Defense Advanced Research
+   Projects Agency (DARPA).  Distribution of this memo is unlimited.
+
+BACKGROUND
+
+   Domains are administrative entities that provide decentralized
+   management of host naming and addressing.  The domain-naming system
+   is distributed and hierarchical.
+
+   The NIC is designated by the Defense Communications Agency (DCA) to
+   provide registry services for the domain-naming system on the DDN and
+   DARPA portions of the Internet.
+
+   As registrar of top-level and second-level domains, as well as
+   administrator of the root domain name servers on behalf of DARPA and
+   DDN, the NIC is responsible for maintaining the root server zone
+   files and their binary equivalents.  In addition, the NIC is
+   responsible for administering the top-level domains of "ARPA," "COM,"
+   "EDU," "ORG," "GOV," and "MIL" on behalf of DCA and DARPA until it
+   becomes feasible for other appropriate organizations to assume those
+   responsibilities.
+
+   It is recommended that the guidelines described in this document be
+   used by domain administrators in the establishment and control of
+   second-level domains.
+
+THE DOMAIN ADMINISTRATOR
+
+   The role of the domain administrator (DA) is that of coordinator,
+   manager, and technician.  If his domain is established at the second
+   level or lower in the tree, the DA must register by interacting with
+   the management of the domain directly above his, making certain that
+
+
+
+Stahl                                                           [Page 1]
+
+RFC 1032              DOMAIN ADMINISTRATORS GUIDE          November 1987
+
+
+   his domain satisfies all the requirements of the administration under
+   which his domain would be situated.  To find out who has authority
+   over the name space he wishes to join, the DA can ask the NIC
+   Hostmaster.  Information on contacts for the top-level and second-
+   level domains can also be found on line in the file NETINFO:DOMAIN-
+   CONTACTS.TXT, which is available from the NIC via anonymous FTP.
+
+   The DA should be technically competent; he should understand the
+   concepts and procedures for operating a domain server, as described
+   in RFC-1034, and make sure that the service provided is reliable and
+   uninterrupted.  It is his responsibility or that of his delegate to
+   ensure that the data will be current at all times.  As a manager, the
+   DA must be able to handle complaints about service provided by his
+   domain name server.  He must be aware of the behavior of the hosts in
+   his domain, and take prompt action on reports of problems, such as
+   protocol violations or other serious misbehavior.  The administrator
+   of a domain must be a responsible person who has the authority to
+   either enforce these actions himself or delegate them to someone
+   else.
+
+   Name assignments within a domain are controlled by the DA, who should
+   verify that names are unique within his domain and that they conform
+   to standard naming conventions.  He furnishes access to names and
+   name-related information to users both inside and outside his domain.
+   He should work closely with the personnel he has designated as the
+   "technical and zone" contacts for his domain, for many administrative
+   decisions will be made on the basis of input from these people.
+
+THE DOMAIN TECHNICAL AND ZONE CONTACT
+
+   A zone consists of those contiguous parts of the domain tree for
+   which a domain server has complete information and over which it has
+   authority.  A domain server may be authoritative for more than one
+   zone.  The domain technical/zone contact is the person who tends to
+   the technical aspects of maintaining the domain's name server and
+   resolver software, and database files.  He keeps the name server
+   running, and interacts with technical people in other domains and
+   zones to solve problems that affect his zone.
+
+POLICIES
+
+   Domain or host name choices and the allocation of domain name space
+   are considered to be local matters.  In the event of conflicts, it is
+   the policy of the NIC not to get involved in local disputes or in the
+   local decision-making process.  The NIC will not act as referee in
+   disputes over such matters as who has the "right" to register a
+   particular top-level or second-level domain for an organization.  The
+   NIC considers this a private local matter that must be settled among
+
+
+
+Stahl                                                           [Page 2]
+
+RFC 1032              DOMAIN ADMINISTRATORS GUIDE          November 1987
+
+
+   the parties involved prior to their commencing the registration
+   process with the NIC.  Therefore, it is assumed that the responsible
+   person for a domain will have resolved any local conflicts among the
+   members of his domain before registering that domain with the NIC.
+   The NIC will give guidance, if requested, by answering specific
+   technical questions, but will not provide arbitration in disputes at
+   the local level.  This policy is also in keeping with the distributed
+   hierarchical nature of the domain-naming system in that it helps to
+   distribute the tasks of solving problems and handling questions.
+
+   Naming conventions for hosts should follow the rules specified in
+   RFC-952.  From a technical standpoint, domain names can be very long.
+   Each segment of a domain name may contain up to 64 characters, but
+   the NIC strongly advises DAs to choose names that are 12 characters
+   or fewer, because behind every domain system there is a human being
+   who must keep track of the names, addresses, contacts, and other data
+   in a database.  The longer the name, the more likely the data
+   maintainer is to make a mistake.  Users also will appreciate shorter
+   names.  Most people agree that short names are easier to remember and
+   type; most domain names registered so far are 12 characters or fewer.
+
+   Domain name assignments are made on a first-come-first-served basis.
+   The NIC has chosen not to register individual hosts directly under
+   the top-level domains it administers.  One advantage of the domain
+   naming system is that administration and data maintenance can be
+   delegated down a hierarchical tree.  Registration of hosts at the
+   same level in the tree as a second-level domain would dilute the
+   usefulness of this feature.  In addition, the administrator of a
+   domain is responsible for the actions of hosts within his domain.  We
+   would not want to find ourselves in the awkward position of policing
+   the actions of individual hosts.  Rather, the subdomains registered
+   under these top-level domains retain the responsibility for this
+   function.
+
+   Countries that wish to be registered as top-level domains are
+   required to name themselves after the two-letter country code listed
+   in the international standard ISO-3166.  In some cases, however, the
+   two-letter ISO country code is identical to a state code used by the
+   U.S. Postal Service.  Requests made by countries to use the three-
+   letter form of country code specified in the ISO-3166 standard will
+   be considered in such cases so as to prevent possible conflicts and
+   confusion.
+
+
+
+
+
+
+
+
+
+Stahl                                                           [Page 3]
+
+RFC 1032              DOMAIN ADMINISTRATORS GUIDE          November 1987
+
+
+HOW TO REGISTER
+
+   Obtain a domain questionnaire from the NIC hostmaster, or FTP the
+   file NETINFO:DOMAIN-TEMPLATE.TXT from host SRI-NIC.ARPA.
+
+   Fill out the questionnaire completely.  Return it via electronic mail
+   to HOSTMASTER@SRI-NIC.ARPA.
+
+   The APPENDIX to this memo contains the application form for
+   registering a top-level or second-level domain with the NIC.  It
+   supersedes the version of the questionnaire found in RFC-920.  The
+   application should be submitted by the person administratively
+   responsible for the domain, and must be filled out completely before
+   the NIC will authorize establishment of a top-level or second-level
+   domain.  The DA is responsible for keeping his domain's data current
+   with the NIC or with the registration agent with which his domain is
+   registered.  For example, the CSNET and UUCP managements act as
+   domain filters, processing domain applications for their own
+   organizations.  They pass pertinent information along periodically to
+   the NIC for incorporation into the domain database and root server
+   files.  The online file NETINFO:ALTERNATE-DOMAIN-PROCEDURE.TXT
+   outlines this procedure.  It is highly recommended that the DA review
+   this information periodically and provide any corrections or
+   additions.  Corrections should be submitted via electronic mail.
+
+WHICH DOMAIN NAME?
+
+   The designers of the domain-naming system initiated several general
+   categories of names as top-level domain names, so that each could
+   accommodate a variety of organizations.  The current top-level
+   domains registered with the DDN Network Information Center are ARPA,
+   COM, EDU, GOV, MIL, NET, and ORG, plus a number of top-level country
+   domains.  To join one of these, a DA needs to be aware of the purpose
+   for which it was intended.
+
+      "ARPA" is a temporary domain.  It is by default appended to the
+      names of hosts that have not yet joined a domain.  When the system
+      was begun in 1984, the names of all hosts in the Official DoD
+      Internet Host Table maintained by the NIC were changed by adding
+      of the label ".ARPA" in order to accelerate a transition to the
+      domain-naming system.  Another reason for the blanket name changes
+      was to force hosts to become accustomed to using the new style
+      names and to modify their network software, if necessary.  This
+      was done on a network-wide basis and was directed by DCA in DDN
+      Management Bulletin No. 22.  Hosts that fall into this domain will
+      eventually move to other branches of the domain tree.
+
+
+
+
+
+Stahl                                                           [Page 4]
+
+RFC 1032              DOMAIN ADMINISTRATORS GUIDE          November 1987
+
+
+      "COM" is meant to incorporate subdomains of companies and
+      businesses.
+
+      "EDU" was initiated to accommodate subdomains set up by
+      universities and other educational institutions.
+
+      "GOV" exists to act as parent domain for subdomains set up by
+      government agencies.
+
+      "MIL" was initiated to act as parent to subdomains that are
+      developed by military organizations.
+
+      "NET" was introduced as a parent domain for various network-type
+      organizations.  Organizations that belong within this top-level
+      domain are generic or network-specific, such as network service
+      centers and consortia.  "NET" also encompasses network
+      management-related organizations, such as information centers and
+      operations centers.
+
+      "ORG" exists as a parent to subdomains that do not clearly fall
+      within the other top-level domains.  This may include technical-
+      support groups, professional societies, or similar organizations.
+
+   One of the guidelines in effect in the domain-naming system is that a
+   host should have only one name regardless of what networks it is
+   connected to.  This implies, that, in general, domain names should
+   not include routing information or addresses.  For example, a host
+   that has one network connection to the Internet and another to BITNET
+   should use the same name when talking to either network.  For a
+   description of the syntax of domain names, please refer to Section 3
+   of RFC-1034.
+
+VERIFICATION OF DATA
+
+   The verification process can be accomplished in several ways.  One of
+   these is through the NIC WHOIS server.  If he has access to WHOIS,
+   the DA can type the command "whois domain <domain name><return>".
+   The reply from WHOIS will supply the following: the name and address
+   of the organization "owning" the domain; the name of the domain; its
+   administrative, technical, and zone contacts; the host names and
+   network addresses of sites providing name service for the domain.
+
+
+
+
+
+
+
+
+
+
+Stahl                                                           [Page 5]
+
+RFC 1032              DOMAIN ADMINISTRATORS GUIDE          November 1987
+
+
+         Example:
+
+         @whois domain rice.edu<Return>
+
+            Rice University (RICE-DOM)
+            Advanced Studies and Research
+            Houston, TX 77001
+
+            Domain Name: RICE.EDU
+
+               Administrative Contact:
+               Kennedy, Ken  (KK28)  Kennedy@LLL-CRG.ARPA (713) 527-4834
+               Technical Contact, Zone Contact:
+               Riffle, Vicky R.  (VRR)  rif@RICE.EDU
+               (713) 527-8101 ext 3844
+
+            Domain servers:
+
+            RICE.EDU                     128.42.5.1
+            PENDRAGON.CS.PURDUE.EDU      128.10.2.5
+
+
+   Alternatively, the DA can send an electronic mail message to
+   SERVICE@SRI-NIC.ARPA.  In the subject line of the message header, the
+   DA should type "whois domain <domain name>".  The requested
+   information will be returned via electronic mail.  This method is
+   convenient for sites that do not have access to the NIC WHOIS
+   service.
+
+   The initial application for domain authorization should be submitted
+   via electronic mail, if possible, to HOSTMASTER@SRI-NIC.ARPA.  The
+   questionnaire described in the appendix may be used or a separate
+   application can be FTPed from host SRI-NIC.ARPA.  The information
+   provided by the administrator will be reviewed by hostmaster
+   personnel for completeness.  There will most likely be a few
+   exchanges of correspondence via electronic mail, the preferred method
+   of communication, prior to authorization of the domain.
+
+HOW TO GET MORE INFORMATION
+
+   An informational table of the top-level domains and their root
+   servers is contained in the file NETINFO:DOMAINS.TXT online at SRI-
+   NIC.ARPA. This table can be obtained by FTPing the file.
+   Alternatively, the information can be acquired by opening a TCP or
+   UDP connection to the NIC Host Name Server, port 101 on SRI-NIC.ARPA,
+   and invoking the command "ALL-DOM".
+
+
+
+
+
+Stahl                                                           [Page 6]
+
+RFC 1032              DOMAIN ADMINISTRATORS GUIDE          November 1987
+
+
+   The following online files, all available by FTP from SRI-NIC.ARPA,
+   contain pertinent domain information:
+
+      - NETINFO:DOMAINS.TXT, a table of all top-level domains and the
+        network addresses of the machines providing domain name
+        service for them.  It is updated each time a new top-level
+        domain is approved.
+
+      - NETINFO:DOMAIN-INFO.TXT contains a concise list of all
+        top-level and second-level domain names registered with the
+        NIC and is updated monthly.
+
+      - NETINFO:DOMAIN-CONTACTS.TXT also contains a list of all the
+        top level and second-level domains, but includes the
+        administrative, technical and zone contacts for each as well.
+
+      - NETINFO:DOMAIN-TEMPLATE.TXT contains the questionnaire to be
+        completed before registering a top-level or second-level
+        domain.
+
+   For either general or specific information on the domain system, do
+   one or more of the following:
+
+      1. Send electronic mail to HOSTMASTER@SRI-NIC.ARPA
+
+      2. Call the toll-free NIC hotline at (800) 235-3155
+
+      3. Use FTP to get background RFCs and other files maintained
+         online at the NIC.  Some pertinent RFCs are listed below in
+         the REFERENCES section of this memo.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Stahl                                                           [Page 7]
+
+RFC 1032              DOMAIN ADMINISTRATORS GUIDE          November 1987
+
+
+REFERENCES
+
+   The references listed here provide important background information
+   on the domain-naming system.  Path names of the online files
+   available via anonymous FTP from the SRI-NIC.ARPA host are noted in
+   brackets.
+
+      1. Defense Communications Agency DDN Defense Communications
+         System, DDN Management Bulletin No. 22, Domain Names
+         Transition, March 1984.
+         [ DDN-NEWS:DDN-MGT-BULLETIN-22.TXT ]
+
+      2. Defense Communications Agency DDN Defense Communications
+         System, DDN Management Bulletin No. 32, Phase I of the Domain
+         Name Implementation, January 1987.
+         [ DDN-NEWS:DDN-MGT-BULLETIN-32.TXT ]
+
+      3. Harrenstien, K., M. Stahl, and E. Feinler, "Hostname
+         Server", RFC-953, DDN Network Information Center, SRI
+         International, October 1985.  [ RFC:RFC953.TXT ]
+
+      4. Harrenstien, K., M. Stahl, and E. Feinler, "Official DoD
+         Internet Host Table Specification", RFC-952, DDN Network
+         Information Center, SRI International, October 1985.
+         [ RFC:RFC952.TXT ]
+
+      5. ISO, "Codes for the Representation of Names of Countries",
+         ISO-3166, International Standards Organization, May 1981.
+         [ Not online ]
+
+      6. Lazear, W.D., "MILNET Name Domain Transition", RFC-1031,
+         Mitre Corporation, October 1987.  [ RFC:RFC1031.TXT ]
+
+      7. Lottor, M.K., "Domain Administrators Operations Guide",
+         RFC-1033, DDN Network Information Center, SRI International,
+         July 1987.  [ RFC:RFC1033.TXT ]
+
+      8. Mockapetris, P., "Domain Names - Concepts and Facilities",
+         RFC-1034, USC Information Sciences Institute, October 1987.
+         [ RFC:RFC1034.TXT ]
+
+      9. Mockapetris, P., "Domain Names - Implementation and
+         Specification", RFC-1035, USC Information Sciences Institute,
+         October 1987.  [ RFC:RFC1035.TXT ]
+
+     10. Mockapetris, P., "The Domain Name System", Proceedings of the
+         IFIP 6.5 Working Conference on Computer Message Services,
+         Nottingham, England, May 1984.  Also as ISI/RS-84-133, June
+
+
+
+Stahl                                                           [Page 8]
+
+RFC 1032              DOMAIN ADMINISTRATORS GUIDE          November 1987
+
+
+         1984.  [ Not online ]
+
+     11. Mockapetris, P., J. Postel, and P. Kirton, "Name Server
+         Design for Distributed Systems", Proceedings of the Seventh
+         International Conference on Computer Communication, October
+         30 to November 3 1984, Sidney, Australia.  Also as
+         ISI/RS-84-132, June 1984.  [ Not online ]
+
+     12. Partridge, C., "Mail Routing and the Domain System", RFC-974,
+         CSNET-CIC, BBN Laboratories, January 1986.
+         [ RFC:RFC974.TXT ]
+
+     13. Postel, J., "The Domain Names Plan and Schedule", RFC-881,
+         USC Information Sciences Institute, November 1983.
+         [ RFC:RFC881.TXT ]
+
+     14. Reynolds, J., and Postel, J., "Assigned Numbers", RFC-1010
+         USC Information Sciences Institute, May 1986.
+         [ RFC:RFC1010.TXT ]
+
+     15. Romano, S., and Stahl, M., "Internet Numbers", RFC-1020,
+         SRI, November 1987.
+         [ RFC:RFC1020.TXT ]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Stahl                                                           [Page 9]
+
+RFC 1032              DOMAIN ADMINISTRATORS GUIDE          November 1987
+
+
+APPENDIX
+
+   The following questionnaire may be FTPed from SRI-NIC.ARPA as
+   NETINFO:DOMAIN-TEMPLATE.TXT.
+
+   ---------------------------------------------------------------------
+
+   To establish a domain, the following information must be sent to the
+   NIC Domain Registrar (HOSTMASTER@SRI-NIC.ARPA):
+
+   NOTE: The key people must have electronic mailboxes and NIC
+   "handles," unique NIC database identifiers.  If you have access to
+   "WHOIS", please check to see if you are registered and if so, make
+   sure the information is current.  Include only your handle and any
+   changes (if any) that need to be made in your entry.  If you do not
+   have access to "WHOIS", please provide all the information indicated
+   and a NIC handle will be assigned.
+
+   (1)  The name of the top-level domain to join.
+
+         For example:  COM
+
+   (2) The NIC handle of the administrative head of the organization.
+   Alternately, the person's name, title, mailing address, phone number,
+   organization, and network mailbox.  This is the contact point for
+   administrative and policy questions about the domain.  In the case of
+   a research project, this should be the principal investigator.
+
+         For example:
+
+            Administrator
+
+               Organization  The NetWorthy Corporation
+               Name          Penelope Q. Sassafrass
+               Title         President
+               Mail Address  The NetWorthy Corporation
+                             4676 Andrews Way, Suite 100
+                             Santa Clara, CA 94302-1212
+               Phone Number  (415) 123-4567
+               Net Mailbox   Sassafrass@ECHO.TNC.COM
+               NIC Handle    PQS
+
+   (3)  The NIC handle of the technical contact for the domain.
+   Alternately, the person's name, title, mailing address, phone number,
+   organization, and network mailbox.  This is the contact point for
+   problems concerning the domain or zone, as well as for updating
+   information about the domain or zone.
+
+
+
+
+Stahl                                                          [Page 10]
+
+RFC 1032              DOMAIN ADMINISTRATORS GUIDE          November 1987
+
+
+         For example:
+
+            Technical and Zone Contact
+
+               Organization  The NetWorthy Corporation
+               Name          Ansel A. Aardvark
+               Title         Executive Director
+               Mail Address  The NetWorthy Corporation
+                             4676 Andrews Way, Suite 100
+                             Santa Clara, CA. 94302-1212
+               Phone Number  (415) 123-6789
+               Net Mailbox   Aardvark@ECHO.TNC.COM
+               NIC Handle    AAA2
+
+   (4)  The name of the domain (up to 12 characters).  This is the name
+   that will be used in tables and lists associating the domain with the
+   domain server addresses.  [While, from a technical standpoint, domain
+   names can be quite long (programmers beware), shorter names are
+   easier for people to cope with.]
+
+         For example:  TNC
+
+   (5)  A description of the servers that provide the domain service for
+   translating names to addresses for hosts in this domain, and the date
+   they will be operational.
+
+         A good way to answer this question is to say "Our server is
+         supplied by person or company X and does whatever their standard
+         issue server does."
+
+            For example:  Our server is a copy of the one operated by
+            the NIC; it will be installed and made operational on
+            1 November 1987.
+
+   (6) Domains must provide at least two independent servers for the
+   domain.  Establishing the servers in physically separate locations
+   and on different PSNs is strongly recommended.  A description of the
+   server machine and its backup, including
+
+
+
+
+
+
+
+
+
+
+
+
+
+Stahl                                                          [Page 11]
+
+RFC 1032              DOMAIN ADMINISTRATORS GUIDE          November 1987
+
+
+         (a) Hardware and software (using keywords from the Assigned
+         Numbers RFC).
+
+         (b) Host domain name and network addresses (which host on which
+         network for each connected network).
+
+         (c) Any domain-style nicknames (please limit your domain-style
+         nickname request to one)
+
+         For example:
+
+            - Hardware and software
+
+               VAX-11/750  and  UNIX,    or
+               IBM-PC      and  MS-DOS,  or
+               DEC-1090    and  TOPS-20
+
+            - Host domain names and network addresses
+
+               BAR.FOO.COM 10.9.0.193 on ARPANET
+
+            - Domain-style nickname
+
+               BR.FOO.COM (same as BAR.FOO.COM 10.9.0.13 on ARPANET)
+
+   (7)  Planned mapping of names of any other network hosts, other than
+   the server machines, into the new domain's naming space.
+
+         For example:
+
+            BAR-FOO2.ARPA (10.8.0.193) -> FOO2.BAR.COM
+            BAR-FOO3.ARPA (10.7.0.193) -> FOO3.BAR.COM
+            BAR-FOO4.ARPA (10.6.0.193) -> FOO4.BAR.COM
+
+
+   (8)  An estimate of the number of hosts that will be in the domain.
+
+         (a) Initially
+         (b) Within one year
+         (c) Two years
+         (d) Five years.
+
+         For example:
+
+            (a) Initially  =   50
+            (b) One year   =  100
+            (c) Two years  =  200
+            (d) Five years =  500
+
+
+
+Stahl                                                          [Page 12]
+
+RFC 1032              DOMAIN ADMINISTRATORS GUIDE          November 1987
+
+
+   (9)  The date you expect the fully qualified domain name to become
+   the official host name in HOSTS.TXT.
+
+         Please note: If changing to a fully qualified domain name (e.g.,
+         FOO.BAR.COM) causes a change in the official host name of an
+         ARPANET or MILNET host, DCA approval must be obtained beforehand.
+         Allow 10 working days for your requested changes to be processed.
+
+         ARPANET sites should contact ARPANETMGR@DDN1.ARPA.  MILNET sites
+         should contact HOSTMASTER@SRI-NIC.ARPA, 800-235-3155, for
+         further instructions.
+
+   (10) Please describe your organization briefly.
+
+         For example: The NetWorthy Corporation is a consulting
+         organization of people working with UNIX and the C language in an
+         electronic networking environment.  It sponsors two technical
+         conferences annually and distributes a bimonthly newsletter.
+
+   ---------------------------------------------------------------------
+
+   This example of a completed application corresponds to the examples
+   found in the companion document RFC-1033, "Domain Administrators
+   Operations Guide."
+
+   (1)  The name of the top-level domain to join.
+
+            COM
+
+   (2)  The NIC handle of the administrative contact person.
+
+            NIC Handle    JAKE
+
+   (3)  The NIC handle of the domain's technical and zone
+         contact person.
+
+            NIC Handle    DLE6
+
+   (4)  The name of the domain.
+
+            SRI
+
+   (5)  A description of the servers.
+
+            Our server is the TOPS20 server JEEVES supplied by ISI; it
+            will be installed and made operational on 1 July 1987.
+
+
+
+
+
+Stahl                                                          [Page 13]
+
+RFC 1032              DOMAIN ADMINISTRATORS GUIDE          November 1987
+
+
+   (6)  A description of the server machine and its backup:
+
+            (a) Hardware and software
+
+               DEC-1090T   and  TOPS20
+               DEC-2065    and  TOPS20
+
+            (b) Host domain name and network address
+
+               KL.SRI.COM  10.1.0.2 on ARPANET, 128.18.10.6 on SRINET
+               STRIPE.SRI.COM  10.4.0.2 on ARPANET, 128.18.10.4 on SRINET
+
+            (c) Domain-style nickname
+
+               None
+
+   (7)  Planned mapping of names of any other network hosts, other than
+   the server machines, into the new domain's naming space.
+
+            SRI-Blackjack.ARPA (128.18.2.1) -> Blackjack.SRI.COM
+            SRI-CSL.ARPA (192.12.33.2) -> CSL.SRI.COM
+
+   (8)  An estimate of the number of hosts that will be directly within
+   this domain.
+
+            (a) Initially  =   50
+            (b) One year   =  100
+            (c) Two years  =  200
+            (d) Five years =  500
+
+   (9)  A date when you expect the fully qualified domain name to become
+   the official host name in HOSTS.TXT.
+
+            31 September 1987
+
+   (10)  Brief description of organization.
+
+            SRI International is an independent, nonprofit, scientific
+            research organization.  It performs basic and applied research
+            for government and commercial clients, and contributes to
+            worldwide economic, scientific, industrial, and social progress
+            through research and related services.
+
+
+
+
+
+
+
+
+
+Stahl                                                          [Page 14]
+
diff --git a/doc/rfc/rfc1033.txt b/doc/rfc/rfc1033.txt
new file mode 100644
index 0000000..37029fd
--- /dev/null
+++ b/doc/rfc/rfc1033.txt
@@ -0,0 +1,1229 @@
+Network Working Group                                         M. Lottor
+Request For Comments:  1033                           SRI International
+                                                          November 1987
+
+
+                 DOMAIN ADMINISTRATORS OPERATIONS GUIDE
+
+
+
+STATUS OF THIS MEMO
+
+   This RFC provides guidelines for domain administrators in operating a
+   domain server and maintaining their portion of the hierarchical
+   database.  Familiarity with the domain system is assumed.
+   Distribution of this memo is unlimited.
+
+ACKNOWLEDGMENTS
+
+   This memo is a formatted collection of notes and excerpts from the
+   references listed at the end of this document.  Of particular mention
+   are Paul Mockapetris and Kevin Dunlap.
+
+INTRODUCTION
+
+   A domain server requires a few files to get started.  It will
+   normally have some number of boot/startup files (also known as the
+   "safety belt" files).  One section will contain a list of possible
+   root servers that the server will use to find the up-to-date list of
+   root servers.  Another section will list the zone files to be loaded
+   into the server for your local domain information.  A zone file
+   typically contains all the data for a particular domain.  This guide
+   describes the data formats that can be used in zone files and
+   suggested parameters to use for certain fields.  If you are
+   attempting to do anything advanced or tricky, consult the appropriate
+   domain RFC's for more details.
+
+   Note:  Each implementation of domain software may require different
+   files.  Zone files are standardized but some servers may require
+   other startup files.  See the appropriate documentation that comes
+   with your software.  See the appendix for some specific examples.
+
+ZONES
+
+   A zone defines the contents of a contiguous section of the domain
+   space, usually bounded by administrative boundaries.  There will
+   typically be a separate data file for each zone.  The data contained
+   in a zone file is composed of entries called Resource Records (RRs).
+
+
+
+
+Lottor                                                          [Page 1]
+
+RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
+
+
+   You may only put data in your domain server that you are
+   authoritative for.  You must not add entries for domains other than
+   your own (except for the special case of "glue records").
+
+   A domain server will probably read a file on start-up that lists the
+   zones it should load into its database.  The format of this file is
+   not standardized and is different for most domain server
+   implementations.  For each zone it will normally contain the domain
+   name of the zone and the file name that contains the data to load for
+   the zone.
+
+ROOT SERVERS
+
+   A resolver will need to find the root servers when it first starts.
+   When the resolver boots, it will typically read a list of possible
+   root servers from a file.
+
+   The resolver will cycle through the list trying to contact each one.
+   When it finds a root server, it will ask it for the current list of
+   root servers.  It will then discard the list of root servers it read
+   from the data file and replace it with the current list it received.
+
+   Root servers will not change very often.  You can get the names of
+   current root servers from the NIC.
+
+   FTP the file NETINFO:ROOT-SERVERS.TXT or send a mail request to
+   NIC@SRI-NIC.ARPA.
+
+   As of this date (June 1987) they are:
+
+           SRI-NIC.ARPA       10.0.0.51    26.0.0.73
+           C.ISI.EDU          10.0.0.52
+           BRL-AOS.ARPA       192.5.25.82  192.5.22.82   128.20.1.2
+           A.ISI.EDU          26.3.0.103
+
+RESOURCE RECORDS
+
+   Records in the zone data files are called resource records (RRs).
+   They are specified in RFC-883 and RFC-973.  An RR has a standard
+   format as shown:
+
+           <name>   [<ttl>]   [<class>]   <type>   <data>
+
+   The record is divided into fields which are separated by white space.
+
+      <name>
+
+         The name field defines what domain name applies to the given
+
+
+
+Lottor                                                          [Page 2]
+
+RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
+
+
+         RR.  In some cases the name field can be left blank and it will
+         default to the name field of the previous RR.
+
+      <ttl>
+
+         TTL stands for Time To Live.  It specifies how long a domain
+         resolver should cache the RR before it throws it out and asks a
+         domain server again.  See the section on TTL's.  If you leave
+         the TTL field blank it will default to the minimum time
+         specified in the SOA record (described later).
+
+      <class>
+
+         The class field specifies the protocol group.  If left blank it
+         will default to the last class specified.
+
+      <type>
+
+         The type field specifies what type of data is in the RR.  See
+         the section on types.
+
+      <data>
+
+         The data field is defined differently for each type and class
+         of data.  Popular RR data formats are described later.
+
+   The domain system does not guarantee to preserve the order of
+   resource records.  Listing RRs (such as multiple address records) in
+   a certain order does not guarantee they will be used in that order.
+
+   Case is preserved in names and data fields when loaded into the name
+   server.  All comparisons and lookups in the name server are case
+   insensitive.
+
+   Parenthesis ("(",")") are used to group data that crosses a line
+   boundary.
+
+   A semicolon (";") starts a comment; the remainder of the line is
+   ignored.
+
+   The asterisk ("*") is used for wildcarding.
+
+   The at-sign ("@") denotes the current default domain name.
+
+
+
+
+
+
+
+
+Lottor                                                          [Page 3]
+
+RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
+
+
+NAMES
+
+   A domain name is a sequence of labels separated by dots.
+
+   Domain names in the zone files can be one of two types, either
+   absolute or relative.  An absolute name is the fully qualified domain
+   name and is terminated with a period.  A relative name does not
+   terminate with a period, and the current default domain is appended
+   to it.  The default domain is usually the name of the domain that was
+   specified in the boot file that loads each zone.
+
+   The domain system allows a label to contain any 8-bit character.
+   Although the domain system has no restrictions, other protocols such
+   as SMTP do have name restrictions.  Because of other protocol
+   restrictions, only the following characters are recommended for use
+   in a host name (besides the dot separator):
+
+           "A-Z", "a-z", "0-9", dash and underscore
+
+TTL's  (Time To Live)
+
+   It is important that TTLs are set to appropriate values.  The TTL is
+   the time (in seconds) that a resolver will use the data it got from
+   your server before it asks your server again.  If you set the value
+   too low, your server will get loaded down with lots of repeat
+   requests.  If you set it too high, then information you change will
+   not get distributed in a reasonable amount of time.  If you leave the
+   TTL field blank, it will default to what is specified in the SOA
+   record for the zone.
+
+   Most host information does not change much over long time periods.  A
+   good way to set up your TTLs would be to set them at a high value,
+   and then lower the value if you know a change will be coming soon.
+   You might set most TTLs to anywhere between a day (86400) and a week
+   (604800).  Then, if you know some data will be changing in the near
+   future, set the TTL for that RR down to a lower value (an hour to a
+   day) until the change takes place, and then put it back up to its
+   previous value.
+
+   Also, all RRs with the same name, class, and type should have the
+   same TTL value.
+
+CLASSES
+
+   The domain system was designed to be protocol independent.  The class
+   field is used to identify the protocol group that each RR is in.
+
+   The class of interest to people using TCP/IP software is the class
+
+
+
+Lottor                                                          [Page 4]
+
+RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
+
+
+   "Internet".  Its standard designation is "IN".
+
+   A zone file should only contain RRs of the same class.
+
+TYPES
+
+   There are many defined RR types.  For a complete list, see the domain
+   specification RFCs.  Here is a list of current commonly used types.
+   The data for each type is described in the data section.
+
+                Designation                Description
+              ==========================================
+               SOA                 Start Of Authority
+               NS                  Name Server
+
+               A                   Internet Address
+               CNAME               Canonical Name (nickname pointer)
+               HINFO               Host Information
+               WKS                 Well Known Services
+
+               MX                  Mail Exchanger
+
+               PTR                 Pointer
+
+SOA  (Start Of Authority)
+
+           <name>  [<ttl>]  [<class>]  SOA  <origin>  <person>  (
+                           <serial>
+                           <refresh>
+                           <retry>
+                           <expire>
+                           <minimum> )
+
+   The Start Of Authority record designates the start of a zone.  The
+   zone ends at the next SOA record.
+
+   <name> is the name of the zone.
+
+   <origin> is the name of the host on which the master zone file
+   resides.
+
+   <person> is a mailbox for the person responsible for the zone.  It is
+   formatted like a mailing address but the at-sign that normally
+   separates the user from the host name is replaced with a dot.
+
+   <serial> is the version number of the zone file.  It should be
+   incremented anytime a change is made to data in the zone.
+
+
+
+
+Lottor                                                          [Page 5]
+
+RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
+
+
+   <refresh> is how long, in seconds, a secondary name server is to
+   check with the primary name server to see if an update is needed.  A
+   good value here would be one hour (3600).
+
+   <retry> is how long, in seconds, a secondary name server is to retry
+   after a failure to check for a refresh.  A good value here would be
+   10 minutes (600).
+
+   <expire> is the upper limit, in seconds, that a secondary name server
+   is to use the data before it expires for lack of getting a refresh.
+   You want this to be rather large, and a nice value is 3600000, about
+   42 days.
+
+   <minimum> is the minimum number of seconds to be used for TTL values
+   in RRs.  A minimum of at least a day is a good value here (86400).
+
+   There should only be one SOA record per zone.  A sample SOA record
+   would look something like:
+
+           @   IN   SOA   SRI-NIC.ARPA.   HOSTMASTER.SRI-NIC.ARPA. (
+                           45         ;serial
+                           3600       ;refresh
+                           600        ;retry
+                           3600000    ;expire
+                           86400 )    ;minimum
+
+
+NS  (Name Server)
+
+           <domain>   [<ttl>] [<class>]   NS   <server>
+
+   The NS record lists the name of a machine that provides domain
+   service for a particular domain.  The name associated with the RR is
+   the domain name and the data portion is the name of a host that
+   provides the service.  If machines SRI-NIC.ARPA and C.ISI.EDU provide
+   name lookup service for the domain COM then the following entries
+   would be used:
+
+           COM.    NS      SRI-NIC.ARPA.
+                   NS      C.ISI.EDU.
+
+   Note that the machines providing name service do not have to live in
+   the named domain.  There should be one NS record for each server for
+   a domain.  Also note that the name "COM" defaults for the second NS
+   record.
+
+   NS records for a domain exist in both the zone that delegates the
+   domain, and in the domain itself.
+
+
+
+Lottor                                                          [Page 6]
+
+RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
+
+
+GLUE RECORDS
+
+   If the name server host for a particular domain is itself inside the
+   domain, then a 'glue' record will be needed.  A glue record is an A
+   (address) RR that specifies the address of the server.  Glue records
+   are only needed in the server delegating the domain, not in the
+   domain itself.  If for example the name server for domain SRI.COM was
+   KL.SRI.COM, then the NS record would look like this, but you will
+   also need to have the following A record.
+
+           SRI.COM.	NS	KL.SRI.COM.
+           KL.SRI.COM.  A	10.1.0.2
+
+
+A  (Address)
+
+           <host>   [<ttl>] [<class>]   A   <address>
+
+   The data for an A record is an internet address in dotted decimal
+   form.  A sample A record might look like:
+
+           SRI-NIC.ARPA.           A       10.0.0.51
+
+   There should be one A record for each address of a host.
+
+CNAME ( Canonical Name)
+
+           <nickname>   [<ttl>] [<class>]   CNAME   <host>
+
+   The CNAME record is used for nicknames.  The name associated with the
+   RR is the nickname.  The data portion is the official name.  For
+   example, a machine named SRI-NIC.ARPA may want to have the nickname
+   NIC.ARPA.  In that case, the following RR would be used:
+
+           NIC.ARPA.       CNAME   SRI-NIC.ARPA.
+
+   There must not be any other RRs associated with a nickname of the
+   same class.
+
+   Nicknames are also useful when a host changes it's name.  In that
+   case, it is usually a good idea to have a CNAME pointer so that
+   people still using the old name will get to the right place.
+
+
+
+
+
+
+
+
+
+Lottor                                                          [Page 7]
+
+RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
+
+
+HINFO (Host Info)
+
+           <host>   [<ttl>] [<class>]   HINFO   <hardware>   <software>
+
+   The HINFO record gives information about a particular host.  The data
+   is two strings separated by whitespace.  The first string is a
+   hardware description and the second is software.  The hardware is
+   usually a manufacturer name followed by a dash and model designation.
+   The software string is usually the name of the operating system.
+
+   Official HINFO types can be found in the latest Assigned Numbers RFC,
+   the latest of which is RFC-1010.  The Hardware type is called the
+   Machine name and the Software type is called the System name.
+
+   Some sample HINFO records:
+
+           SRI-NIC.ARPA.           HINFO   DEC-2060 TOPS20
+           UCBARPA.Berkeley.EDU.   HINFO   VAX-11/780 UNIX
+
+
+WKS (Well Known Services)
+
+           <host> [<ttl>] [<class>] WKS <address> <protocol> <services>
+
+   The WKS record is used to list Well Known Services a host provides.
+   WKS's are defined to be services on port numbers below 256.  The WKS
+   record lists what services are available at a certain address using a
+   certain protocol.  The common protocols are TCP or UDP.  A sample WKS
+   record for a host offering the same services on all address would
+   look like:
+
+   Official protocol names can be found in the latest Assigned Numbers
+   RFC, the latest of which is RFC-1010.
+
+           SRI-NIC.ARPA.   WKS  10.0.0.51  TCP  TELNET FTP SMTP
+                           WKS  10.0.0.51  UDP  TIME
+                           WKS  26.0.0.73  TCP  TELNET FTP SMTP
+                           WKS  26.0.0.73  UDP  TIME
+
+MX (Mail Exchanger)  (See RFC-974 for more details.)
+
+           <name>   [<ttl>] [<class>]   MX   <preference>   <host>
+
+   MX records specify where mail for a domain name should be delivered.
+   There may be multiple MX records for a particular name.  The
+   preference value specifies the order a mailer should try multiple MX
+   records when delivering mail.  Zero is the highest preference.
+   Multiple records for the same name may have the same preference.
+
+
+
+Lottor                                                          [Page 8]
+
+RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
+
+
+   A host BAR.FOO.COM may want its mail to be delivered to the host
+   PO.FOO.COM and would then use the MX record:
+
+           BAR.FOO.COM.    MX      10      PO.FOO.COM.
+
+   A host BAZ.FOO.COM may want its mail to be delivered to one of three
+   different machines, in the following order:
+
+           BAZ.FOO.COM.    MX      10      PO1.FOO.COM.
+                           MX      20      PO2.FOO.COM.
+                           MX      30      PO3.FOO.COM.
+
+   An entire domain of hosts not connected to the Internet may want
+   their mail to go through a mail gateway that knows how to deliver
+   mail to them.  If they would like mail addressed to any host in the
+   domain FOO.COM to go through the mail gateway they might use:
+
+           FOO.COM.        MX       10     RELAY.CS.NET.
+           *.FOO.COM.      MX       20     RELAY.CS.NET.
+
+   Note that you can specify a wildcard in the MX record to match on
+   anything in FOO.COM, but that it won't match a plain FOO.COM.
+
+IN-ADDR.ARPA
+
+   The structure of names in the domain system is set up in a
+   hierarchical way such that the address of a name can be found by
+   tracing down the domain tree contacting a server for each label of
+   the name.  Because of this 'indexing' based on name, there is no easy
+   way to translate a host address back into its host name.
+
+   In order to do the reverse translation easily, a domain was created
+   that uses hosts' addresses as part of a name that then points to the
+   data for that host.  In this way, there is now an 'index' to hosts'
+   RRs based on their address.  This address mapping domain is called
+   IN-ADDR.ARPA.  Within that domain are subdomains for each network,
+   based on network number.  Also, for consistency and natural
+   groupings, the 4 octets of a host number are reversed.
+
+   For example, the ARPANET is net 10.  That means there is a domain
+   called 10.IN-ADDR.ARPA.  Within this domain there is a PTR RR at
+   51.0.0.10.IN-ADDR that points to the RRs for the host SRI-NIC.ARPA
+   (who's address is 10.0.0.51).  Since the NIC is also on the MILNET
+   (Net 26, address 26.0.0.73), there is also a PTR RR at 73.0.0.26.IN-
+   ADDR.ARPA that points to the same RR's for SRI-NIC.ARPA.  The format
+   of these special pointers is defined below along with the examples
+   for the NIC.
+
+
+
+
+Lottor                                                          [Page 9]
+
+RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
+
+
+PTR
+
+           <special-name>   [<ttl>] [<class>]   PTR   <name>
+
+   The PTR record is used to let special names point to some other
+   location in the domain tree.  They are mainly used in the IN-
+   ADDR.ARPA records for translation of addresses to names.  PTR's
+   should use official names and not aliases.
+
+   For example, host SRI-NIC.ARPA with addresses 10.0.0.51 and 26.0.0.73
+   would have the following records in the respective zone files for net
+   10 and net 26:
+
+           51.0.0.10.IN-ADDR.ARPA.  PTR   SRI-NIC.ARPA.
+           73.0.0.26.IN-ADDR.ARPA.  PTR   SRI-NIC.ARPA.
+
+GATEWAY PTR's
+
+   The IN-ADDR tree is also used to locate gateways on a particular
+   network.  Gateways have the same kind of PTR RRs as hosts (as above)
+   but in addition they have other PTRs used to locate them by network
+   number alone.  These records have only 1, 2, or 3 octets as part of
+   the name depending on whether they are class A, B, or C networks,
+   respectively.
+
+   Lets take the SRI-CSL gateway for example.  It connects 3 different
+   networks, one class A, one class B and one class C.  It will have the
+   standard RR's for a host in the CSL.SRI.COM zone:
+
+           GW.CSL.SRI.COM.    A    10.2.0.2
+                              A    128.18.1.1
+                              A    192.12.33.2
+
+   Also, in 3 different zones (one for each network), it will have one
+   of the following number to name translation pointers:
+
+           2.0.2.10.IN-ADDR.ARPA.      PTR   GW.CSL.SRI.COM.
+           1.1.18.128.IN-ADDR.ARPA.    PTR   GW.CSL.SRI.COM.
+           1.33.12.192.IN-ADDR.ARPA.   PTR   GW.CSL.SRI.COM.
+
+   In addition, in each of the same 3 zones will be one of the following
+   gateway location pointers:
+
+           10.IN-ADDR.ARPA.            PTR   GW.CSL.SRI.COM.
+           18.128.IN-ADDR.ARPA.        PTR   GW.CSL.SRI.COM.
+           33.12.192.IN-ADDR.ARPA.     PTR   GW.CSL.SRI.COM.
+
+
+
+
+
+Lottor                                                         [Page 10]
+
+RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
+
+
+INSTRUCTIONS
+
+   Adding a subdomain.
+
+      To add a new subdomain to your domain:
+
+         Setup the other domain server and/or the new zone file.
+
+         Add an NS record for each server of the new domain to the zone
+         file of the parent domain.
+
+         Add any necessary glue RRs.
+
+   Adding a host.
+
+      To add a new host to your zone files:
+
+         Edit the appropriate zone file for the domain the host is in.
+
+         Add an entry for each address of the host.
+
+         Optionally add CNAME, HINFO, WKS, and MX records.
+
+         Add the reverse IN-ADDR entry for each host address in the
+         appropriate zone files for each network the host in on.
+
+   Deleting a host.
+
+      To delete a host from the zone files:
+
+         Remove all the hosts' resource records from the zone file of
+         the domain the host is in.
+
+         Remove all the hosts' PTR records from the IN-ADDR zone files
+         for each network the host was on.
+
+   Adding gateways.
+
+         Follow instructions for adding a host.
+
+         Add the gateway location PTR records for each network the
+         gateway is on.
+
+   Deleting gateways.
+
+         Follow instructions for deleting a host.
+
+         Also delete the gateway location PTR records for each network
+
+
+
+Lottor                                                         [Page 11]
+
+RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
+
+
+         the gateway was on.
+
+COMPLAINTS
+
+   These are the suggested steps you should take if you are having
+   problems that you believe are caused by someone else's name server:
+
+
+   1.  Complain privately to the responsible person for the domain.  You
+   can find their mailing address in the SOA record for the domain.
+
+   2.  Complain publicly to the responsible person for the domain.
+
+   3.  Ask the NIC for the administrative person responsible for the
+   domain.  Complain.  You can also find domain contacts on the NIC in
+   the file NETINFO:DOMAIN-CONTACTS.TXT
+
+   4.  Complain to the parent domain authorities.
+
+   5.  Ask the parent authorities to excommunicate the domain.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lottor                                                         [Page 12]
+
+RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
+
+
+EXAMPLE DOMAIN SERVER DATABASE FILES
+
+   The following examples show how zone files are set up for a typical
+   organization.  SRI will be used as the example organization.  SRI has
+   decided to divided their domain SRI.COM into a few subdomains, one
+   for each group that wants one.  The subdomains are CSL and ISTC.
+
+   Note the following interesting items:
+
+      There are both hosts and domains under SRI.COM.
+
+      CSL.SRI.COM is both a domain name and a host name.
+
+      All the domains are serviced by the same pair of domain servers.
+
+      All hosts at SRI are on net 128.18 except hosts in the CSL domain
+      which are on net 192.12.33.  Note that a domain does not have to
+      correspond to a physical network.
+
+      The examples do not necessarily correspond to actual data in use
+      by the SRI domain.
+
+                       SRI Domain Organization
+
+                               +-------+
+                               |  COM  |
+                               +-------+
+                                   |
+                               +-------+
+                               |  SRI  |
+                               +-------+
+                                   |
+                        +----------++-----------+
+                        |           |           |
+                    +-------+    +------+   +-------+
+                    |  CSL  |    | ISTC |   | Hosts |
+                    +-------+    +------+   +-------+
+                        |           |
+                    +-------+    +-------+
+                    | Hosts |    | Hosts |
+                    +-------+    +-------+
+
+
+
+
+
+
+
+
+
+
+Lottor                                                         [Page 13]
+
+RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
+
+
+   [File "CONFIG.CMD".  Since bootstrap files are not standardized, this
+   file is presented using a pseudo configuration file syntax.]
+
+   load root server list             from file ROOT.SERVERS
+   load zone SRI.COM.                from file SRI.ZONE
+   load zone CSL.SRI.COM.            from file CSL.ZONE
+   load zone ISTC.SRI.COM.           from file ISTC.ZONE
+   load zone 18.128.IN-ADDR.ARPA.    from file SRINET.ZONE
+   load zone 33.12.192.IN-ADDR.ARPA. from file SRI-CSL-NET.ZONE
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lottor                                                         [Page 14]
+
+RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
+
+
+   [File "ROOT.SERVERS".  Again, the format of this file is not
+   standardized.]
+
+   ;list of possible root servers
+   SRI-NIC.ARPA       10.0.0.51    26.0.0.73
+   C.ISI.EDU          10.0.0.52
+   BRL-AOS.ARPA       192.5.25.82  192.5.22.82   128.20.1.2
+   A.ISI.EDU          26.3.0.103
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lottor                                                         [Page 15]
+
+RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
+
+
+   [File "SRI.ZONE"]
+
+   SRI.COM.        IN      SOA     KL.SRI.COM. DLE.STRIPE.SRI.COM. (
+                                   870407  ;serial
+                                   1800    ;refresh every 30 minutes
+                                   600     ;retry every 10 minutes
+                                   604800  ;expire after a week
+                                   86400   ;default of an hour
+                                   )
+
+   SRI.COM.        NS      KL.SRI.COM.
+                   NS      STRIPE.SRI.COM.
+                   MX      10      KL.SRI.COM.
+
+   ;SRI.COM hosts
+
+   KL              A       10.1.0.2
+                   A       128.18.10.6
+                   MX      10      KL.SRI.COM.
+
+   STRIPE          A       10.4.0.2
+   STRIPE          A       128.18.10.4
+                   MX      10      STRIPE.SRI.COM.
+
+   NIC             CNAME   SRI-NIC.ARPA.
+
+   Blackjack       A       128.18.2.1
+                   HINFO   VAX-11/780      UNIX
+                   WKS     128.18.2.1      TCP TELNET FTP
+
+   CSL             A       192.12.33.2
+                   HINFO   FOONLY-F4       TOPS20
+                   WKS     192.12.33.2     TCP TELNET FTP SMTP FINGER
+                   MX      10      CSL.SRI.COM.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lottor                                                         [Page 16]
+
+RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
+
+
+   [File "CSL.ZONE"]
+
+   CSL.SRI.COM.    IN      SOA     KL.SRI.COM. DLE.STRIPE.SRI.COM. (
+                                   870330  ;serial
+                                   1800    ;refresh every 30 minutes
+                                   600     ;retry every 10 minutes
+                                   604800  ;expire after a week
+                                   86400   ;default of a day
+                                   )
+
+   CSL.SRI.COM.    NS              KL.SRI.COM.
+                   NS              STRIPE.SRI.COM.
+                   A               192.12.33.2
+
+   ;CSL.SRI.COM hosts
+
+   A               CNAME   CSL.SRI.COM.
+   B               A       192.12.33.3
+                   HINFO   FOONLY-F4       TOPS20
+                   WKS     192.12.33.3     TCP TELNET FTP SMTP
+   GW              A       10.2.0.2
+                   A       192.12.33.1
+                   A       128.18.1.1
+                   HINFO   PDP-11/23       MOS
+   SMELLY          A       192.12.33.4
+                   HINFO   IMAGEN          IMAGEN
+   SQUIRREL        A       192.12.33.5
+                   HINFO   XEROX-1100      INTERLISP
+   VENUS           A       192.12.33.7
+                   HINFO   SYMBOLICS-3600  LISPM
+   HELIUM          A       192.12.33.30
+                   HINFO   SUN-3/160       UNIX
+   ARGON           A       192.12.33.31
+                   HINFO   SUN-3/75        UNIX
+   RADON           A       192.12.33.32
+                   HINFO   SUN-3/75        UNIX
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lottor                                                         [Page 17]
+
+RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
+
+
+   [File "ISTC.ZONE"]
+
+   ISTC.SRI.COM.   IN  SOA     KL.SRI.COM. roemers.JOYCE.ISTC.SRI.COM. (
+                               870406      ;serial
+                               1800        ;refresh every 30 minutes
+                               600         ;retry every 10 minutes
+                               604800      ;expire after a week
+                               86400       ;default of a day
+                               )
+
+   ISTC.SRI.COM.   NS              KL.SRI.COM.
+                   NS              STRIPE.SRI.COM.
+                   MX              10      SPAM.ISTC.SRI.COM.
+
+   ; ISTC hosts
+
+   joyce           A       128.18.4.2
+                   HINFO   VAX-11/750 UNIX
+   bozo            A       128.18.0.6
+                   HINFO   SUN UNIX
+   sundae          A       128.18.0.11
+                   HINFO   SUN UNIX
+   tsca            A       128.18.0.201
+                   A       10.3.0.2
+                   HINFO   VAX-11/750 UNIX
+                   MX      10  TSCA.ISTC.SRI.COM.
+   tsc             CNAME   tsca
+   prmh            A       128.18.0.203
+                   A       10.2.0.51
+                   HINFO   PDP-11/44 UNIX
+   spam            A       128.18.4.3
+                   A       10.2.0.107
+                   HINFO   VAX-11/780 UNIX
+                   MX      10  SPAM.ISTC.SRI.COM.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lottor                                                         [Page 18]
+
+RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
+
+
+   [File "SRINET.ZONE"]
+
+   18.128.IN-ADDR.ARPA.    IN  SOA  KL.SRI.COM  DLE.STRIPE.SRI.COM. (
+                               870406  ;serial
+                               1800    ;refresh every 30 minutes
+                               600     ;retry every 10 minutes
+                               604800  ;expire after a week
+                               86400   ;default of a day
+                               )
+
+   18.128.IN-ADDR.ARPA.    NS      KL.SRI.COM.
+                           NS      STRIPE.SRI.COM.
+                           PTR     GW.CSL.SRI.COM.
+
+   ; SRINET [128.18.0.0] Address Translations
+
+   ; SRI.COM Hosts
+   1.2.18.128.IN-ADDR.ARPA.        PTR     Blackjack.SRI.COM.
+
+   ; ISTC.SRI.COM Hosts
+   2.4.18.128.IN-ADDR.ARPA.        PTR     joyce.ISTC.SRI.COM.
+   6.0.18.128.IN-ADDR.ARPA.        PTR     bozo.ISTC.SRI.COM.
+   11.0.18.128.IN-ADDR.ARPA.       PTR     sundae.ISTC.SRI.COM.
+   201.0.18.128.IN-ADDR.ARPA.      PTR     tsca.ISTC.SRI.COM.
+   203.0.18.128.IN-ADDR.ARPA.      PTR     prmh.ISTC.SRI.COM.
+   3.4.18.128.IN-ADDR.ARPA.        PTR     spam.ISTC.SRI.COM.
+
+   ; CSL.SRI.COM Hosts
+   1.1.18.128.IN-ADDR.ARPA.        PTR     GW.CSL.SRI.COM.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lottor                                                         [Page 19]
+
+RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
+
+
+   [File "SRI-CSL-NET.ZONE"]
+
+   33.12.192.IN-ADDR.ARPA. IN  SOA KL.SRI.COM  DLE.STRIPE.SRI.COM. (
+                               870404  ;serial
+                               1800    ;refresh every 30 minutes
+                               600     ;retry every 10 minutes
+                               604800  ;expire after a week
+                               86400   ;default of a day
+                               )
+
+   33.12.192.IN-ADDR.ARPA. NS      KL.SRI.COM.
+                           NS      STRIPE.SRI.COM.
+                           PTR     GW.CSL.SRI.COM.
+
+   ; SRI-CSL-NET [192.12.33.0] Address Translations
+
+   ; SRI.COM Hosts
+   2.33.12.192.IN-ADDR.ARPA.       PTR     CSL.SRI.COM.
+
+   ; CSL.SRI.COM Hosts
+   1.33.12.192.IN-ADDR.ARPA.       PTR     GW.CSL.SRI.COM.
+   3.33.12.192.IN-ADDR.ARPA.       PTR     B.CSL.SRI.COM.
+   4.33.12.192.IN-ADDR.ARPA.       PTR     SMELLY.CSL.SRI.COM.
+   5.33.12.192.IN-ADDR.ARPA.       PTR     SQUIRREL.CSL.SRI.COM.
+   7.33.12.192.IN-ADDR.ARPA.       PTR     VENUS.CSL.SRI.COM.
+   30.33.12.192.IN-ADDR.ARPA.      PTR     HELIUM.CSL.SRI.COM.
+   31.33.12.192.IN-ADDR.ARPA.      PTR     ARGON.CSL.SRI.COM.
+   32.33.12.192.IN-ADDR.ARPA.      PTR     RADON.CSL.SRI.COM.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lottor                                                         [Page 20]
+
+RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
+
+
+APPENDIX
+
+   BIND (Berkeley Internet Name Domain server) distributed with 4.3 BSD
+   UNIX
+
+   This section describes two BIND implementation specific files; the
+   boot file and the cache file.  BIND has other options, files, and
+   specifications that are not described here.  See the Name Server
+   Operations Guide for BIND for details.
+
+   The boot file for BIND is usually called "named.boot".  This
+   corresponds to file "CONFIG.CMD" in the example section.
+
+           --------------------------------------------------------
+           cache         .                         named.ca
+           primary       SRI.COM                   SRI.ZONE
+           primary       CSL.SRI.COM               CSL.ZONE
+           primary       ISTC.SRI.COM              ISTC.ZONE
+           primary       18.128.IN-ADDR.ARPA       SRINET.ZONE
+           primary       33.12.192.IN-ADDR.ARPA    SRI-CSL-NET.ZONE
+           --------------------------------------------------------
+
+   The cache file for BIND is usually called "named.ca".  This
+   corresponds to file "ROOT.SERVERS" in the example section.
+
+           -------------------------------------------------
+           ;list of possible root servers
+           .       1          IN   NS   SRI-NIC.ARPA.
+                                   NS   C.ISI.EDU.
+                                   NS   BRL-AOS.ARPA.
+                                   NS   C.ISI.EDU.
+           ;and their addresses
+           SRI-NIC.ARPA.           A    10.0.0.51
+                                   A    26.0.0.73
+           C.ISI.EDU.              A    10.0.0.52
+           BRL-AOS.ARPA.           A    192.5.25.82
+                                   A    192.5.22.82
+                                   A    128.20.1.2
+           A.ISI.EDU.              A    26.3.0.103
+           -------------------------------------------------
+
+
+
+
+
+
+
+
+
+
+
+Lottor                                                         [Page 21]
+
+RFC 1033                DOMAIN OPERATIONS GUIDE            November 1987
+
+
+REFERENCES
+
+   [1]  Dunlap, K., "Name Server Operations Guide for BIND", CSRG,
+        Department of Electrical Engineering and Computer Sciences,
+        University of California, Berkeley, California.
+
+   [2]  Partridge, C., "Mail Routing and the Domain System", RFC-974,
+        CSNET CIC BBN Laboratories, January 1986.
+
+   [3]  Mockapetris, P., "Domains Names - Concepts and Facilities",
+        RFC-1034, USC/Information Sciences Institute, November 1987.
+
+   [4]  Mockapetris, P., "Domain Names - Implementations Specification",
+        RFC-1035, USC/Information Sciences Institute, November 1987.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lottor                                                         [Page 22]
+
diff --git a/doc/rfc/rfc1034.txt b/doc/rfc/rfc1034.txt
new file mode 100644
index 0000000..55cdb21
--- /dev/null
+++ b/doc/rfc/rfc1034.txt
@@ -0,0 +1,3077 @@
+Network Working Group                                     P. Mockapetris
+Request for Comments: 1034                                           ISI
+Obsoletes: RFCs 882, 883, 973                              November 1987
+
+
+                 DOMAIN NAMES - CONCEPTS AND FACILITIES
+
+
+
+1. STATUS OF THIS MEMO
+
+This RFC is an introduction to the Domain Name System (DNS), and omits
+many details which can be found in a companion RFC, "Domain Names -
+Implementation and Specification" [RFC-1035].  That RFC assumes that the
+reader is familiar with the concepts discussed in this memo.
+
+A subset of DNS functions and data types constitute an official
+protocol.  The official protocol includes standard queries and their
+responses and most of the Internet class data formats (e.g., host
+addresses).
+
+However, the domain system is intentionally extensible.  Researchers are
+continuously proposing, implementing and experimenting with new data
+types, query types, classes, functions, etc.  Thus while the components
+of the official protocol are expected to stay essentially unchanged and
+operate as a production service, experimental behavior should always be
+expected in extensions beyond the official protocol.  Experimental or
+obsolete features are clearly marked in these RFCs, and such information
+should be used with caution.
+
+The reader is especially cautioned not to depend on the values which
+appear in examples to be current or complete, since their purpose is
+primarily pedagogical.  Distribution of this memo is unlimited.
+
+2. INTRODUCTION
+
+This RFC introduces domain style names, their use for Internet mail and
+host address support, and the protocols and servers used to implement
+domain name facilities.
+
+2.1. The history of domain names
+
+The impetus for the development of the domain system was growth in the
+Internet:
+
+   - Host name to address mappings were maintained by the Network
+     Information Center (NIC) in a single file (HOSTS.TXT) which
+     was FTPed by all hosts [RFC-952, RFC-953].  The total network
+
+
+
+Mockapetris                                                     [Page 1]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+     bandwidth consumed in distributing a new version by this
+     scheme is proportional to the square of the number of hosts in
+     the network, and even when multiple levels of FTP are used,
+     the outgoing FTP load on the NIC host is considerable.
+     Explosive growth in the number of hosts didn't bode well for
+     the future.
+
+   - The network population was also changing in character.  The
+     timeshared hosts that made up the original ARPANET were being
+     replaced with local networks of workstations.  Local
+     organizations were administering their own names and
+     addresses, but had to wait for the NIC to change HOSTS.TXT to
+     make changes visible to the Internet at large.  Organizations
+     also wanted some local structure on the name space.
+
+   - The applications on the Internet were getting more
+     sophisticated and creating a need for general purpose name
+     service.
+
+
+The result was several ideas about name spaces and their management
+[IEN-116, RFC-799, RFC-819, RFC-830].  The proposals varied, but a
+common thread was the idea of a hierarchical name space, with the
+hierarchy roughly corresponding to organizational structure, and names
+using "."  as the character to mark the boundary between hierarchy
+levels.  A design using a distributed database and generalized resources
+was described in [RFC-882, RFC-883].  Based on experience with several
+implementations, the system evolved into the scheme described in this
+memo.
+
+The terms "domain" or "domain name" are used in many contexts beyond the
+DNS described here.  Very often, the term domain name is used to refer
+to a name with structure indicated by dots, but no relation to the DNS.
+This is particularly true in mail addressing [Quarterman 86].
+
+2.2. DNS design goals
+
+The design goals of the DNS influence its structure.  They are:
+
+   - The primary goal is a consistent name space which will be used
+     for referring to resources.  In order to avoid the problems
+     caused by ad hoc encodings, names should not be required to
+     contain network identifiers, addresses, routes, or similar
+     information as part of the name.
+
+   - The sheer size of the database and frequency of updates
+     suggest that it must be maintained in a distributed manner,
+     with local caching to improve performance.  Approaches that
+
+
+
+Mockapetris                                                     [Page 2]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+     attempt to collect a consistent copy of the entire database
+     will become more and more expensive and difficult, and hence
+     should be avoided.  The same principle holds for the structure
+     of the name space, and in particular mechanisms for creating
+     and deleting names; these should also be distributed.
+
+   - Where there tradeoffs between the cost of acquiring data, the
+     speed of updates, and the accuracy of caches, the source of
+     the data should control the tradeoff.
+
+   - The costs of implementing such a facility dictate that it be
+     generally useful, and not restricted to a single application.
+     We should be able to use names to retrieve host addresses,
+     mailbox data, and other as yet undetermined information.  All
+     data associated with a name is tagged with a type, and queries
+     can be limited to a single type.
+
+   - Because we want the name space to be useful in dissimilar
+     networks and applications, we provide the ability to use the
+     same name space with different protocol families or
+     management.  For example, host address formats differ between
+     protocols, though all protocols have the notion of address.
+     The DNS tags all data with a class as well as the type, so
+     that we can allow parallel use of different formats for data
+     of type address.
+
+   - We want name server transactions to be independent of the
+     communications system that carries them.  Some systems may
+     wish to use datagrams for queries and responses, and only
+     establish virtual circuits for transactions that need the
+     reliability (e.g., database updates, long transactions); other
+     systems will use virtual circuits exclusively.
+
+   - The system should be useful across a wide spectrum of host
+     capabilities.  Both personal computers and large timeshared
+     hosts should be able to use the system, though perhaps in
+     different ways.
+
+2.3. Assumptions about usage
+
+The organization of the domain system derives from some assumptions
+about the needs and usage patterns of its user community and is designed
+to avoid many of the the complicated problems found in general purpose
+database systems.
+
+The assumptions are:
+
+   - The size of the total database will initially be proportional
+
+
+
+Mockapetris                                                     [Page 3]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+     to the number of hosts using the system, but will eventually
+     grow to be proportional to the number of users on those hosts
+     as mailboxes and other information are added to the domain
+     system.
+
+   - Most of the data in the system will change very slowly (e.g.,
+     mailbox bindings, host addresses), but that the system should
+     be able to deal with subsets that change more rapidly (on the
+     order of seconds or minutes).
+
+   - The administrative boundaries used to distribute
+     responsibility for the database will usually correspond to
+     organizations that have one or more hosts.  Each organization
+     that has responsibility for a particular set of domains will
+     provide redundant name servers, either on the organization's
+     own hosts or other hosts that the organization arranges to
+     use.
+
+   - Clients of the domain system should be able to identify
+     trusted name servers they prefer to use before accepting
+     referrals to name servers outside of this "trusted" set.
+
+   - Access to information is more critical than instantaneous
+     updates or guarantees of consistency.  Hence the update
+     process allows updates to percolate out through the users of
+     the domain system rather than guaranteeing that all copies are
+     simultaneously updated.  When updates are unavailable due to
+     network or host failure, the usual course is to believe old
+     information while continuing efforts to update it.  The
+     general model is that copies are distributed with timeouts for
+     refreshing.  The distributor sets the timeout value and the
+     recipient of the distribution is responsible for performing
+     the refresh.  In special situations, very short intervals can
+     be specified, or the owner can prohibit copies.
+
+   - In any system that has a distributed database, a particular
+     name server may be presented with a query that can only be
+     answered by some other server.  The two general approaches to
+     dealing with this problem are "recursive", in which the first
+     server pursues the query for the client at another server, and
+     "iterative", in which the server refers the client to another
+     server and lets the client pursue the query.  Both approaches
+     have advantages and disadvantages, but the iterative approach
+     is preferred for the datagram style of access.  The domain
+     system requires implementation of the iterative approach, but
+     allows the recursive approach as an option.
+
+
+
+
+
+Mockapetris                                                     [Page 4]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+The domain system assumes that all data originates in master files
+scattered through the hosts that use the domain system.  These master
+files are updated by local system administrators.  Master files are text
+files that are read by a local name server, and hence become available
+through the name servers to users of the domain system.  The user
+programs access name servers through standard programs called resolvers.
+
+The standard format of master files allows them to be exchanged between
+hosts (via FTP, mail, or some other mechanism); this facility is useful
+when an organization wants a domain, but doesn't want to support a name
+server.  The organization can maintain the master files locally using a
+text editor, transfer them to a foreign host which runs a name server,
+and then arrange with the system administrator of the name server to get
+the files loaded.
+
+Each host's name servers and resolvers are configured by a local system
+administrator [RFC-1033].  For a name server, this configuration data
+includes the identity of local master files and instructions on which
+non-local master files are to be loaded from foreign servers.  The name
+server uses the master files or copies to load its zones.  For
+resolvers, the configuration data identifies the name servers which
+should be the primary sources of information.
+
+The domain system defines procedures for accessing the data and for
+referrals to other name servers.  The domain system also defines
+procedures for caching retrieved data and for periodic refreshing of
+data defined by the system administrator.
+
+The system administrators provide:
+
+   - The definition of zone boundaries.
+
+   - Master files of data.
+
+   - Updates to master files.
+
+   - Statements of the refresh policies desired.
+
+The domain system provides:
+
+   - Standard formats for resource data.
+
+   - Standard methods for querying the database.
+
+   - Standard methods for name servers to refresh local data from
+     foreign name servers.
+
+
+
+
+
+Mockapetris                                                     [Page 5]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+2.4. Elements of the DNS
+
+The DNS has three major components:
+
+   - The DOMAIN NAME SPACE and RESOURCE RECORDS, which are
+     specifications for a tree structured name space and data
+     associated with the names.  Conceptually, each node and leaf
+     of the domain name space tree names a set of information, and
+     query operations are attempts to extract specific types of
+     information from a particular set.  A query names the domain
+     name of interest and describes the type of resource
+     information that is desired.  For example, the Internet
+     uses some of its domain names to identify hosts; queries for
+     address resources return Internet host addresses.
+
+   - NAME SERVERS are server programs which hold information about
+     the domain tree's structure and set information.  A name
+     server may cache structure or set information about any part
+     of the domain tree, but in general a particular name server
+     has complete information about a subset of the domain space,
+     and pointers to other name servers that can be used to lead to
+     information from any part of the domain tree.  Name servers
+     know the parts of the domain tree for which they have complete
+     information; a name server is said to be an AUTHORITY for
+     these parts of the name space.  Authoritative information is
+     organized into units called ZONEs, and these zones can be
+     automatically distributed to the name servers which provide
+     redundant service for the data in a zone.
+
+   - RESOLVERS are programs that extract information from name
+     servers in response to client requests.  Resolvers must be
+     able to access at least one name server and use that name
+     server's information to answer a query directly, or pursue the
+     query using referrals to other name servers.  A resolver will
+     typically be a system routine that is directly accessible to
+     user programs; hence no protocol is necessary between the
+     resolver and the user program.
+
+These three components roughly correspond to the three layers or views
+of the domain system:
+
+   - From the user's point of view, the domain system is accessed
+     through a simple procedure or OS call to a local resolver.
+     The domain space consists of a single tree and the user can
+     request information from any section of the tree.
+
+   - From the resolver's point of view, the domain system is
+     composed of an unknown number of name servers.  Each name
+
+
+
+Mockapetris                                                     [Page 6]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+     server has one or more pieces of the whole domain tree's data,
+     but the resolver views each of these databases as essentially
+     static.
+
+   - From a name server's point of view, the domain system consists
+     of separate sets of local information called zones.  The name
+     server has local copies of some of the zones.  The name server
+     must periodically refresh its zones from master copies in
+     local files or foreign name servers.  The name server must
+     concurrently process queries that arrive from resolvers.
+
+In the interests of performance, implementations may couple these
+functions.  For example, a resolver on the same machine as a name server
+might share a database consisting of the the zones managed by the name
+server and the cache managed by the resolver.
+
+3. DOMAIN NAME SPACE and RESOURCE RECORDS
+
+3.1. Name space specifications and terminology
+
+The domain name space is a tree structure.  Each node and leaf on the
+tree corresponds to a resource set (which may be empty).  The domain
+system makes no distinctions between the uses of the interior nodes and
+leaves, and this memo uses the term "node" to refer to both.
+
+Each node has a label, which is zero to 63 octets in length.  Brother
+nodes may not have the same label, although the same label can be used
+for nodes which are not brothers.  One label is reserved, and that is
+the null (i.e., zero length) label used for the root.
+
+The domain name of a node is the list of the labels on the path from the
+node to the root of the tree.  By convention, the labels that compose a
+domain name are printed or read left to right, from the most specific
+(lowest, farthest from the root) to the least specific (highest, closest
+to the root).
+
+Internally, programs that manipulate domain names should represent them
+as sequences of labels, where each label is a length octet followed by
+an octet string.  Because all domain names end at the root, which has a
+null string for a label, these internal representations can use a length
+byte of zero to terminate a domain name.
+
+By convention, domain names can be stored with arbitrary case, but
+domain name comparisons for all present domain functions are done in a
+case-insensitive manner, assuming an ASCII character set, and a high
+order zero bit.  This means that you are free to create a node with
+label "A" or a node with label "a", but not both as brothers; you could
+refer to either using "a" or "A".  When you receive a domain name or
+
+
+
+Mockapetris                                                     [Page 7]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+label, you should preserve its case.  The rationale for this choice is
+that we may someday need to add full binary domain names for new
+services; existing services would not be changed.
+
+When a user needs to type a domain name, the length of each label is
+omitted and the labels are separated by dots (".").  Since a complete
+domain name ends with the root label, this leads to a printed form which
+ends in a dot.  We use this property to distinguish between:
+
+   - a character string which represents a complete domain name
+     (often called "absolute").  For example, "poneria.ISI.EDU."
+
+   - a character string that represents the starting labels of a
+     domain name which is incomplete, and should be completed by
+     local software using knowledge of the local domain (often
+     called "relative").  For example, "poneria" used in the
+     ISI.EDU domain.
+
+Relative names are either taken relative to a well known origin, or to a
+list of domains used as a search list.  Relative names appear mostly at
+the user interface, where their interpretation varies from
+implementation to implementation, and in master files, where they are
+relative to a single origin domain name.  The most common interpretation
+uses the root "." as either the single origin or as one of the members
+of the search list, so a multi-label relative name is often one where
+the trailing dot has been omitted to save typing.
+
+To simplify implementations, the total number of octets that represent a
+domain name (i.e., the sum of all label octets and label lengths) is
+limited to 255.
+
+A domain is identified by a domain name, and consists of that part of
+the domain name space that is at or below the domain name which
+specifies the domain.  A domain is a subdomain of another domain if it
+is contained within that domain.  This relationship can be tested by
+seeing if the subdomain's name ends with the containing domain's name.
+For example, A.B.C.D is a subdomain of B.C.D, C.D, D, and " ".
+
+3.2. Administrative guidelines on use
+
+As a matter of policy, the DNS technical specifications do not mandate a
+particular tree structure or rules for selecting labels; its goal is to
+be as general as possible, so that it can be used to build arbitrary
+applications.  In particular, the system was designed so that the name
+space did not have to be organized along the lines of network
+boundaries, name servers, etc.  The rationale for this is not that the
+name space should have no implied semantics, but rather that the choice
+of implied semantics should be left open to be used for the problem at
+
+
+
+Mockapetris                                                     [Page 8]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+hand, and that different parts of the tree can have different implied
+semantics.  For example, the IN-ADDR.ARPA domain is organized and
+distributed by network and host address because its role is to translate
+from network or host numbers to names; NetBIOS domains [RFC-1001, RFC-
+1002] are flat because that is appropriate for that application.
+
+However, there are some guidelines that apply to the "normal" parts of
+the name space used for hosts, mailboxes, etc., that will make the name
+space more uniform, provide for growth, and minimize problems as
+software is converted from the older host table.  The political
+decisions about the top levels of the tree originated in RFC-920.
+Current policy for the top levels is discussed in [RFC-1032].  MILNET
+conversion issues are covered in [RFC-1031].
+
+Lower domains which will eventually be broken into multiple zones should
+provide branching at the top of the domain so that the eventual
+decomposition can be done without renaming.  Node labels which use
+special characters, leading digits, etc., are likely to break older
+software which depends on more restrictive choices.
+
+3.3. Technical guidelines on use
+
+Before the DNS can be used to hold naming information for some kind of
+object, two needs must be met:
+
+   - A convention for mapping between object names and domain
+     names.  This describes how information about an object is
+     accessed.
+
+   - RR types and data formats for describing the object.
+
+These rules can be quite simple or fairly complex.  Very often, the
+designer must take into account existing formats and plan for upward
+compatibility for existing usage.  Multiple mappings or levels of
+mapping may be required.
+
+For hosts, the mapping depends on the existing syntax for host names
+which is a subset of the usual text representation for domain names,
+together with RR formats for describing host addresses, etc.  Because we
+need a reliable inverse mapping from address to host name, a special
+mapping for addresses into the IN-ADDR.ARPA domain is also defined.
+
+For mailboxes, the mapping is slightly more complex.  The usual mail
+address <local-part>@<mail-domain> is mapped into a domain name by
+converting <local-part> into a single label (regardles of dots it
+contains), converting <mail-domain> into a domain name using the usual
+text format for domain names (dots denote label breaks), and
+concatenating the two to form a single domain name.  Thus the mailbox
+
+
+
+Mockapetris                                                     [Page 9]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+HOSTMASTER@SRI-NIC.ARPA is represented as a domain name by
+HOSTMASTER.SRI-NIC.ARPA.  An appreciation for the reasons behind this
+design also must take into account the scheme for mail exchanges [RFC-
+974].
+
+The typical user is not concerned with defining these rules, but should
+understand that they usually are the result of numerous compromises
+between desires for upward compatibility with old usage, interactions
+between different object definitions, and the inevitable urge to add new
+features when defining the rules.  The way the DNS is used to support
+some object is often more crucial than the restrictions inherent in the
+DNS.
+
+3.4. Example name space
+
+The following figure shows a part of the current domain name space, and
+is used in many examples in this RFC.  Note that the tree is a very
+small subset of the actual name space.
+
+                                   |
+                                   |
+             +---------------------+------------------+
+             |                     |                  |
+            MIL                   EDU                ARPA
+             |                     |                  |
+             |                     |                  |
+       +-----+-----+               |     +------+-----+-----+
+       |     |     |               |     |      |           |
+      BRL  NOSC  DARPA             |  IN-ADDR  SRI-NIC     ACC
+                                   |
+       +--------+------------------+---------------+--------+
+       |        |                  |               |        |
+      UCI      MIT                 |              UDEL     YALE
+                |                 ISI
+                |                  |
+            +---+---+              |
+            |       |              |
+           LCS  ACHILLES  +--+-----+-----+--------+
+            |             |  |     |     |        |
+            XX            A  C   VAXA  VENERA Mockapetris
+
+In this example, the root domain has three immediate subdomains: MIL,
+EDU, and ARPA.  The LCS.MIT.EDU domain has one immediate subdomain named
+XX.LCS.MIT.EDU.  All of the leaves are also domains.
+
+3.5. Preferred name syntax
+
+The DNS specifications attempt to be as general as possible in the rules
+
+
+
+Mockapetris                                                    [Page 10]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+for constructing domain names.  The idea is that the name of any
+existing object can be expressed as a domain name with minimal changes.
+However, when assigning a domain name for an object, the prudent user
+will select a name which satisfies both the rules of the domain system
+and any existing rules for the object, whether these rules are published
+or implied by existing programs.
+
+For example, when naming a mail domain, the user should satisfy both the
+rules of this memo and those in RFC-822.  When creating a new host name,
+the old rules for HOSTS.TXT should be followed.  This avoids problems
+when old software is converted to use domain names.
+
+The following syntax will result in fewer problems with many
+applications that use domain names (e.g., mail, TELNET).
+
+<domain> ::= <subdomain> | " "
+
+<subdomain> ::= <label> | <subdomain> "." <label>
+
+<label> ::= <letter> [ [ <ldh-str> ] <let-dig> ]
+
+<ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str>
+
+<let-dig-hyp> ::= <let-dig> | "-"
+
+<let-dig> ::= <letter> | <digit>
+
+<letter> ::= any one of the 52 alphabetic characters A through Z in
+upper case and a through z in lower case
+
+<digit> ::= any one of the ten digits 0 through 9
+
+Note that while upper and lower case letters are allowed in domain
+names, no significance is attached to the case.  That is, two names with
+the same spelling but different case are to be treated as if identical.
+
+The labels must follow the rules for ARPANET host names.  They must
+start with a letter, end with a letter or digit, and have as interior
+characters only letters, digits, and hyphen.  There are also some
+restrictions on the length.  Labels must be 63 characters or less.
+
+For example, the following strings identify hosts in the Internet:
+
+A.ISI.EDU  XX.LCS.MIT.EDU  SRI-NIC.ARPA
+
+3.6. Resource Records
+
+A domain name identifies a node.  Each node has a set of resource
+
+
+
+Mockapetris                                                    [Page 11]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+information, which may be empty.  The set of resource information
+associated with a particular name is composed of separate resource
+records (RRs).  The order of RRs in a set is not significant, and need
+not be preserved by name servers, resolvers, or other parts of the DNS.
+
+When we talk about a specific RR, we assume it has the following:
+
+owner           which is the domain name where the RR is found.
+
+type            which is an encoded 16 bit value that specifies the type
+                of the resource in this resource record.  Types refer to
+                abstract resources.
+
+                This memo uses the following types:
+
+                A               a host address
+
+                CNAME           identifies the canonical name of an
+                                alias
+
+                HINFO           identifies the CPU and OS used by a host
+
+                MX              identifies a mail exchange for the
+                                domain.  See [RFC-974 for details.
+
+                NS
+                the authoritative name server for the domain
+
+                PTR
+                a pointer to another part of the domain name space
+
+                SOA
+                identifies the start of a zone of authority]
+
+class           which is an encoded 16 bit value which identifies a
+                protocol family or instance of a protocol.
+
+                This memo uses the following classes:
+
+                IN              the Internet system
+
+                CH              the Chaos system
+
+TTL             which is the time to live of the RR.  This field is a 32
+                bit integer in units of seconds, an is primarily used by
+                resolvers when they cache RRs.  The TTL describes how
+                long a RR can be cached before it should be discarded.
+
+
+
+
+Mockapetris                                                    [Page 12]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+RDATA           which is the type and sometimes class dependent data
+                which describes the resource:
+
+                A               For the IN class, a 32 bit IP address
+
+                                For the CH class, a domain name followed
+                                by a 16 bit octal Chaos address.
+
+                CNAME           a domain name.
+
+                MX              a 16 bit preference value (lower is
+                                better) followed by a host name willing
+                                to act as a mail exchange for the owner
+                                domain.
+
+                NS              a host name.
+
+                PTR             a domain name.
+
+                SOA             several fields.
+
+The owner name is often implicit, rather than forming an integral part
+of the RR.  For example, many name servers internally form tree or hash
+structures for the name space, and chain RRs off nodes.  The remaining
+RR parts are the fixed header (type, class, TTL) which is consistent for
+all RRs, and a variable part (RDATA) that fits the needs of the resource
+being described.
+
+The meaning of the TTL field is a time limit on how long an RR can be
+kept in a cache.  This limit does not apply to authoritative data in
+zones; it is also timed out, but by the refreshing policies for the
+zone.  The TTL is assigned by the administrator for the zone where the
+data originates.  While short TTLs can be used to minimize caching, and
+a zero TTL prohibits caching, the realities of Internet performance
+suggest that these times should be on the order of days for the typical
+host.  If a change can be anticipated, the TTL can be reduced prior to
+the change to minimize inconsistency during the change, and then
+increased back to its former value following the change.
+
+The data in the RDATA section of RRs is carried as a combination of
+binary strings and domain names.  The domain names are frequently used
+as "pointers" to other data in the DNS.
+
+3.6.1. Textual expression of RRs
+
+RRs are represented in binary form in the packets of the DNS protocol,
+and are usually represented in highly encoded form when stored in a name
+server or resolver.  In this memo, we adopt a style similar to that used
+
+
+
+Mockapetris                                                    [Page 13]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+in master files in order to show the contents of RRs.  In this format,
+most RRs are shown on a single line, although continuation lines are
+possible using parentheses.
+
+The start of the line gives the owner of the RR.  If a line begins with
+a blank, then the owner is assumed to be the same as that of the
+previous RR.  Blank lines are often included for readability.
+
+Following the owner, we list the TTL, type, and class of the RR.  Class
+and type use the mnemonics defined above, and TTL is an integer before
+the type field.  In order to avoid ambiguity in parsing, type and class
+mnemonics are disjoint, TTLs are integers, and the type mnemonic is
+always last. The IN class and TTL values are often omitted from examples
+in the interests of clarity.
+
+The resource data or RDATA section of the RR are given using knowledge
+of the typical representation for the data.
+
+For example, we might show the RRs carried in a message as:
+
+    ISI.EDU.        MX      10 VENERA.ISI.EDU.
+                    MX      10 VAXA.ISI.EDU.
+    VENERA.ISI.EDU. A       128.9.0.32
+                    A       10.1.0.52
+    VAXA.ISI.EDU.   A       10.2.0.27
+                    A       128.9.0.33
+
+The MX RRs have an RDATA section which consists of a 16 bit number
+followed by a domain name.  The address RRs use a standard IP address
+format to contain a 32 bit internet address.
+
+This example shows six RRs, with two RRs at each of three domain names.
+
+Similarly we might see:
+
+    XX.LCS.MIT.EDU. IN      A       10.0.0.44
+                    CH      A       MIT.EDU. 2420
+
+This example shows two addresses for XX.LCS.MIT.EDU, each of a different
+class.
+
+3.6.2. Aliases and canonical names
+
+In existing systems, hosts and other resources often have several names
+that identify the same resource.  For example, the names C.ISI.EDU and
+USC-ISIC.ARPA both identify the same host.  Similarly, in the case of
+mailboxes, many organizations provide many names that actually go to the
+same mailbox; for example Mockapetris@C.ISI.EDU, Mockapetris@B.ISI.EDU,
+
+
+
+Mockapetris                                                    [Page 14]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+and PVM@ISI.EDU all go to the same mailbox (although the mechanism
+behind this is somewhat complicated).
+
+Most of these systems have a notion that one of the equivalent set of
+names is the canonical or primary name and all others are aliases.
+
+The domain system provides such a feature using the canonical name
+(CNAME) RR.  A CNAME RR identifies its owner name as an alias, and
+specifies the corresponding canonical name in the RDATA section of the
+RR.  If a CNAME RR is present at a node, no other data should be
+present; this ensures that the data for a canonical name and its aliases
+cannot be different.  This rule also insures that a cached CNAME can be
+used without checking with an authoritative server for other RR types.
+
+CNAME RRs cause special action in DNS software.  When a name server
+fails to find a desired RR in the resource set associated with the
+domain name, it checks to see if the resource set consists of a CNAME
+record with a matching class.  If so, the name server includes the CNAME
+record in the response and restarts the query at the domain name
+specified in the data field of the CNAME record.  The one exception to
+this rule is that queries which match the CNAME type are not restarted.
+
+For example, suppose a name server was processing a query with for USC-
+ISIC.ARPA, asking for type A information, and had the following resource
+records:
+
+    USC-ISIC.ARPA   IN      CNAME   C.ISI.EDU
+
+    C.ISI.EDU       IN      A       10.0.0.52
+
+Both of these RRs would be returned in the response to the type A query,
+while a type CNAME or * query should return just the CNAME.
+
+Domain names in RRs which point at another name should always point at
+the primary name and not the alias.  This avoids extra indirections in
+accessing information.  For example, the address to name RR for the
+above host should be:
+
+    52.0.0.10.IN-ADDR.ARPA  IN      PTR     C.ISI.EDU
+
+rather than pointing at USC-ISIC.ARPA.  Of course, by the robustness
+principle, domain software should not fail when presented with CNAME
+chains or loops; CNAME chains should be followed and CNAME loops
+signalled as an error.
+
+3.7. Queries
+
+Queries are messages which may be sent to a name server to provoke a
+
+
+
+Mockapetris                                                    [Page 15]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+response.  In the Internet, queries are carried in UDP datagrams or over
+TCP connections.  The response by the name server either answers the
+question posed in the query, refers the requester to another set of name
+servers, or signals some error condition.
+
+In general, the user does not generate queries directly, but instead
+makes a request to a resolver which in turn sends one or more queries to
+name servers and deals with the error conditions and referrals that may
+result.  Of course, the possible questions which can be asked in a query
+does shape the kind of service a resolver can provide.
+
+DNS queries and responses are carried in a standard message format.  The
+message format has a header containing a number of fixed fields which
+are always present, and four sections which carry query parameters and
+RRs.
+
+The most important field in the header is a four bit field called an
+opcode which separates different queries.  Of the possible 16 values,
+one (standard query) is part of the official protocol, two (inverse
+query and status query) are options, one (completion) is obsolete, and
+the rest are unassigned.
+
+The four sections are:
+
+Question        Carries the query name and other query parameters.
+
+Answer          Carries RRs which directly answer the query.
+
+Authority       Carries RRs which describe other authoritative servers.
+                May optionally carry the SOA RR for the authoritative
+                data in the answer section.
+
+Additional      Carries RRs which may be helpful in using the RRs in the
+                other sections.
+
+Note that the content, but not the format, of these sections varies with
+header opcode.
+
+3.7.1. Standard queries
+
+A standard query specifies a target domain name (QNAME), query type
+(QTYPE), and query class (QCLASS) and asks for RRs which match.  This
+type of query makes up such a vast majority of DNS queries that we use
+the term "query" to mean standard query unless otherwise specified.  The
+QTYPE and QCLASS fields are each 16 bits long, and are a superset of
+defined types and classes.
+
+
+
+
+
+Mockapetris                                                    [Page 16]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+The QTYPE field may contain:
+
+<any type>      matches just that type. (e.g., A, PTR).
+
+AXFR            special zone transfer QTYPE.
+
+MAILB           matches all mail box related RRs (e.g. MB and MG).
+
+*               matches all RR types.
+
+The QCLASS field may contain:
+
+<any class>     matches just that class (e.g., IN, CH).
+
+*               matches aLL RR classes.
+
+Using the query domain name, QTYPE, and QCLASS, the name server looks
+for matching RRs.  In addition to relevant records, the name server may
+return RRs that point toward a name server that has the desired
+information or RRs that are expected to be useful in interpreting the
+relevant RRs.  For example, a name server that doesn't have the
+requested information may know a name server that does; a name server
+that returns a domain name in a relevant RR may also return the RR that
+binds that domain name to an address.
+
+For example, a mailer tying to send mail to Mockapetris@ISI.EDU might
+ask the resolver for mail information about ISI.EDU, resulting in a
+query for QNAME=ISI.EDU, QTYPE=MX, QCLASS=IN.  The response's answer
+section would be:
+
+    ISI.EDU.        MX      10 VENERA.ISI.EDU.
+                    MX      10 VAXA.ISI.EDU.
+
+while the additional section might be:
+
+    VAXA.ISI.EDU.   A       10.2.0.27
+                    A       128.9.0.33
+    VENERA.ISI.EDU. A       10.1.0.52
+                    A       128.9.0.32
+
+Because the server assumes that if the requester wants mail exchange
+information, it will probably want the addresses of the mail exchanges
+soon afterward.
+
+Note that the QCLASS=* construct requires special interpretation
+regarding authority.  Since a particular name server may not know all of
+the classes available in the domain system, it can never know if it is
+authoritative for all classes.  Hence responses to QCLASS=* queries can
+
+
+
+Mockapetris                                                    [Page 17]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+never be authoritative.
+
+3.7.2. Inverse queries (Optional)
+
+Name servers may also support inverse queries that map a particular
+resource to a domain name or domain names that have that resource.  For
+example, while a standard query might map a domain name to a SOA RR, the
+corresponding inverse query might map the SOA RR back to the domain
+name.
+
+Implementation of this service is optional in a name server, but all
+name servers must at least be able to understand an inverse query
+message and return a not-implemented error response.
+
+The domain system cannot guarantee the completeness or uniqueness of
+inverse queries because the domain system is organized by domain name
+rather than by host address or any other resource type.  Inverse queries
+are primarily useful for debugging and database maintenance activities.
+
+Inverse queries may not return the proper TTL, and do not indicate cases
+where the identified RR is one of a set (for example, one address for a
+host having multiple addresses).  Therefore, the RRs returned in inverse
+queries should never be cached.
+
+Inverse queries are NOT an acceptable method for mapping host addresses
+to host names; use the IN-ADDR.ARPA domain instead.
+
+A detailed discussion of inverse queries is contained in [RFC-1035].
+
+3.8. Status queries (Experimental)
+
+To be defined.
+
+3.9. Completion queries (Obsolete)
+
+The optional completion services described in RFCs 882 and 883 have been
+deleted.  Redesigned services may become available in the future, or the
+opcodes may be reclaimed for other use.
+
+4. NAME SERVERS
+
+4.1. Introduction
+
+Name servers are the repositories of information that make up the domain
+database.  The database is divided up into sections called zones, which
+are distributed among the name servers.  While name servers can have
+several optional functions and sources of data, the essential task of a
+name server is to answer queries using data in its zones.  By design,
+
+
+
+Mockapetris                                                    [Page 18]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+name servers can answer queries in a simple manner; the response can
+always be generated using only local data, and either contains the
+answer to the question or a referral to other name servers "closer" to
+the desired information.
+
+A given zone will be available from several name servers to insure its
+availability in spite of host or communication link failure.  By
+administrative fiat, we require every zone to be available on at least
+two servers, and many zones have more redundancy than that.
+
+A given name server will typically support one or more zones, but this
+gives it authoritative information about only a small section of the
+domain tree.  It may also have some cached non-authoritative data about
+other parts of the tree.  The name server marks its responses to queries
+so that the requester can tell whether the response comes from
+authoritative data or not.
+
+4.2. How the database is divided into zones
+
+The domain database is partitioned in two ways: by class, and by "cuts"
+made in the name space between nodes.
+
+The class partition is simple.  The database for any class is organized,
+delegated, and maintained separately from all other classes.  Since, by
+convention, the name spaces are the same for all classes, the separate
+classes can be thought of as an array of parallel namespace trees.  Note
+that the data attached to nodes will be different for these different
+parallel classes.  The most common reasons for creating a new class are
+the necessity for a new data format for existing types or a desire for a
+separately managed version of the existing name space.
+
+Within a class, "cuts" in the name space can be made between any two
+adjacent nodes.  After all cuts are made, each group of connected name
+space is a separate zone.  The zone is said to be authoritative for all
+names in the connected region.  Note that the "cuts" in the name space
+may be in different places for different classes, the name servers may
+be different, etc.
+
+These rules mean that every zone has at least one node, and hence domain
+name, for which it is authoritative, and all of the nodes in a
+particular zone are connected.  Given, the tree structure, every zone
+has a highest node which is closer to the root than any other node in
+the zone.  The name of this node is often used to identify the zone.
+
+It would be possible, though not particularly useful, to partition the
+name space so that each domain name was in a separate zone or so that
+all nodes were in a single zone.  Instead, the database is partitioned
+at points where a particular organization wants to take over control of
+
+
+
+Mockapetris                                                    [Page 19]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+a subtree.  Once an organization controls its own zone it can
+unilaterally change the data in the zone, grow new tree sections
+connected to the zone, delete existing nodes, or delegate new subzones
+under its zone.
+
+If the organization has substructure, it may want to make further
+internal partitions to achieve nested delegations of name space control.
+In some cases, such divisions are made purely to make database
+maintenance more convenient.
+
+4.2.1. Technical considerations
+
+The data that describes a zone has four major parts:
+
+   - Authoritative data for all nodes within the zone.
+
+   - Data that defines the top node of the zone (can be thought of
+     as part of the authoritative data).
+
+   - Data that describes delegated subzones, i.e., cuts around the
+     bottom of the zone.
+
+   - Data that allows access to name servers for subzones
+     (sometimes called "glue" data).
+
+All of this data is expressed in the form of RRs, so a zone can be
+completely described in terms of a set of RRs.  Whole zones can be
+transferred between name servers by transferring the RRs, either carried
+in a series of messages or by FTPing a master file which is a textual
+representation.
+
+The authoritative data for a zone is simply all of the RRs attached to
+all of the nodes from the top node of the zone down to leaf nodes or
+nodes above cuts around the bottom edge of the zone.
+
+Though logically part of the authoritative data, the RRs that describe
+the top node of the zone are especially important to the zone's
+management.  These RRs are of two types: name server RRs that list, one
+per RR, all of the servers for the zone, and a single SOA RR that
+describes zone management parameters.
+
+The RRs that describe cuts around the bottom of the zone are NS RRs that
+name the servers for the subzones.  Since the cuts are between nodes,
+these RRs are NOT part of the authoritative data of the zone, and should
+be exactly the same as the corresponding RRs in the top node of the
+subzone.  Since name servers are always associated with zone boundaries,
+NS RRs are only found at nodes which are the top node of some zone.  In
+the data that makes up a zone, NS RRs are found at the top node of the
+
+
+
+Mockapetris                                                    [Page 20]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+zone (and are authoritative) and at cuts around the bottom of the zone
+(where they are not authoritative), but never in between.
+
+One of the goals of the zone structure is that any zone have all the
+data required to set up communications with the name servers for any
+subzones.  That is, parent zones have all the information needed to
+access servers for their children zones.  The NS RRs that name the
+servers for subzones are often not enough for this task since they name
+the servers, but do not give their addresses.  In particular, if the
+name of the name server is itself in the subzone, we could be faced with
+the situation where the NS RRs tell us that in order to learn a name
+server's address, we should contact the server using the address we wish
+to learn.  To fix this problem, a zone contains "glue" RRs which are not
+part of the authoritative data, and are address RRs for the servers.
+These RRs are only necessary if the name server's name is "below" the
+cut, and are only used as part of a referral response.
+
+4.2.2. Administrative considerations
+
+When some organization wants to control its own domain, the first step
+is to identify the proper parent zone, and get the parent zone's owners
+to agree to the delegation of control.  While there are no particular
+technical constraints dealing with where in the tree this can be done,
+there are some administrative groupings discussed in [RFC-1032] which
+deal with top level organization, and middle level zones are free to
+create their own rules.  For example, one university might choose to use
+a single zone, while another might choose to organize by subzones
+dedicated to individual departments or schools.  [RFC-1033] catalogs
+available DNS software an discusses administration procedures.
+
+Once the proper name for the new subzone is selected, the new owners
+should be required to demonstrate redundant name server support.  Note
+that there is no requirement that the servers for a zone reside in a
+host which has a name in that domain.  In many cases, a zone will be
+more accessible to the internet at large if its servers are widely
+distributed rather than being within the physical facilities controlled
+by the same organization that manages the zone.  For example, in the
+current DNS, one of the name servers for the United Kingdom, or UK
+domain, is found in the US.  This allows US hosts to get UK data without
+using limited transatlantic bandwidth.
+
+As the last installation step, the delegation NS RRs and glue RRs
+necessary to make the delegation effective should be added to the parent
+zone.  The administrators of both zones should insure that the NS and
+glue RRs which mark both sides of the cut are consistent and remain so.
+
+4.3. Name server internals
+
+
+
+
+Mockapetris                                                    [Page 21]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+4.3.1. Queries and responses
+
+The principal activity of name servers is to answer standard queries.
+Both the query and its response are carried in a standard message format
+which is described in [RFC-1035].  The query contains a QTYPE, QCLASS,
+and QNAME, which describe the types and classes of desired information
+and the name of interest.
+
+The way that the name server answers the query depends upon whether it
+is operating in recursive mode or not:
+
+   - The simplest mode for the server is non-recursive, since it
+     can answer queries using only local information: the response
+     contains an error, the answer, or a referral to some other
+     server "closer" to the answer.  All name servers must
+     implement non-recursive queries.
+
+   - The simplest mode for the client is recursive, since in this
+     mode the name server acts in the role of a resolver and
+     returns either an error or the answer, but never referrals.
+     This service is optional in a name server, and the name server
+     may also choose to restrict the clients which can use
+     recursive mode.
+
+Recursive service is helpful in several situations:
+
+   - a relatively simple requester that lacks the ability to use
+     anything other than a direct answer to the question.
+
+   - a request that needs to cross protocol or other boundaries and
+     can be sent to a server which can act as intermediary.
+
+   - a network where we want to concentrate the cache rather than
+     having a separate cache for each client.
+
+Non-recursive service is appropriate if the requester is capable of
+pursuing referrals and interested in information which will aid future
+requests.
+
+The use of recursive mode is limited to cases where both the client and
+the name server agree to its use.  The agreement is negotiated through
+the use of two bits in query and response messages:
+
+   - The recursion available, or RA bit, is set or cleared by a
+     name server in all responses.  The bit is true if the name
+     server is willing to provide recursive service for the client,
+     regardless of whether the client requested recursive service.
+     That is, RA signals availability rather than use.
+
+
+
+Mockapetris                                                    [Page 22]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+   - Queries contain a bit called recursion desired or RD.  This
+     bit specifies specifies whether the requester wants recursive
+     service for this query.  Clients may request recursive service
+     from any name server, though they should depend upon receiving
+     it only from servers which have previously sent an RA, or
+     servers which have agreed to provide service through private
+     agreement or some other means outside of the DNS protocol.
+
+The recursive mode occurs when a query with RD set arrives at a server
+which is willing to provide recursive service; the client can verify
+that recursive mode was used by checking that both RA and RD are set in
+the reply.  Note that the name server should never perform recursive
+service unless asked via RD, since this interferes with trouble shooting
+of name servers and their databases.
+
+If recursive service is requested and available, the recursive response
+to a query will be one of the following:
+
+   - The answer to the query, possibly preface by one or more CNAME
+     RRs that specify aliases encountered on the way to an answer.
+
+   - A name error indicating that the name does not exist.  This
+     may include CNAME RRs that indicate that the original query
+     name was an alias for a name which does not exist.
+
+   - A temporary error indication.
+
+If recursive service is not requested or is not available, the non-
+recursive response will be one of the following:
+
+   - An authoritative name error indicating that the name does not
+     exist.
+
+   - A temporary error indication.
+
+   - Some combination of:
+
+     RRs that answer the question, together with an indication
+     whether the data comes from a zone or is cached.
+
+     A referral to name servers which have zones which are closer
+     ancestors to the name than the server sending the reply.
+
+   - RRs that the name server thinks will prove useful to the
+     requester.
+
+
+
+
+
+
+Mockapetris                                                    [Page 23]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+4.3.2. Algorithm
+
+The actual algorithm used by the name server will depend on the local OS
+and data structures used to store RRs.  The following algorithm assumes
+that the RRs are organized in several tree structures, one for each
+zone, and another for the cache:
+
+   1. Set or clear the value of recursion available in the response
+      depending on whether the name server is willing to provide
+      recursive service.  If recursive service is available and
+      requested via the RD bit in the query, go to step 5,
+      otherwise step 2.
+
+   2. Search the available zones for the zone which is the nearest
+      ancestor to QNAME.  If such a zone is found, go to step 3,
+      otherwise step 4.
+
+   3. Start matching down, label by label, in the zone.  The
+      matching process can terminate several ways:
+
+         a. If the whole of QNAME is matched, we have found the
+            node.
+
+            If the data at the node is a CNAME, and QTYPE doesn't
+            match CNAME, copy the CNAME RR into the answer section
+            of the response, change QNAME to the canonical name in
+            the CNAME RR, and go back to step 1.
+
+            Otherwise, copy all RRs which match QTYPE into the
+            answer section and go to step 6.
+
+         b. If a match would take us out of the authoritative data,
+            we have a referral.  This happens when we encounter a
+            node with NS RRs marking cuts along the bottom of a
+            zone.
+
+            Copy the NS RRs for the subzone into the authority
+            section of the reply.  Put whatever addresses are
+            available into the additional section, using glue RRs
+            if the addresses are not available from authoritative
+            data or the cache.  Go to step 4.
+
+         c. If at some label, a match is impossible (i.e., the
+            corresponding label does not exist), look to see if a
+            the "*" label exists.
+
+            If the "*" label does not exist, check whether the name
+            we are looking for is the original QNAME in the query
+
+
+
+Mockapetris                                                    [Page 24]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+            or a name we have followed due to a CNAME.  If the name
+            is original, set an authoritative name error in the
+            response and exit.  Otherwise just exit.
+
+            If the "*" label does exist, match RRs at that node
+            against QTYPE.  If any match, copy them into the answer
+            section, but set the owner of the RR to be QNAME, and
+            not the node with the "*" label.  Go to step 6.
+
+   4. Start matching down in the cache.  If QNAME is found in the
+      cache, copy all RRs attached to it that match QTYPE into the
+      answer section.  If there was no delegation from
+      authoritative data, look for the best one from the cache, and
+      put it in the authority section.  Go to step 6.
+
+   5. Using the local resolver or a copy of its algorithm (see
+      resolver section of this memo) to answer the query.  Store
+      the results, including any intermediate CNAMEs, in the answer
+      section of the response.
+
+   6. Using local data only, attempt to add other RRs which may be
+      useful to the additional section of the query.  Exit.
+
+4.3.3. Wildcards
+
+In the previous algorithm, special treatment was given to RRs with owner
+names starting with the label "*".  Such RRs are called wildcards.
+Wildcard RRs can be thought of as instructions for synthesizing RRs.
+When the appropriate conditions are met, the name server creates RRs
+with an owner name equal to the query name and contents taken from the
+wildcard RRs.
+
+This facility is most often used to create a zone which will be used to
+forward mail from the Internet to some other mail system.  The general
+idea is that any name in that zone which is presented to server in a
+query will be assumed to exist, with certain properties, unless explicit
+evidence exists to the contrary.  Note that the use of the term zone
+here, instead of domain, is intentional; such defaults do not propagate
+across zone boundaries, although a subzone may choose to achieve that
+appearance by setting up similar defaults.
+
+The contents of the wildcard RRs follows the usual rules and formats for
+RRs.  The wildcards in the zone have an owner name that controls the
+query names they will match.  The owner name of the wildcard RRs is of
+the form "*.<anydomain>", where <anydomain> is any domain name.
+<anydomain> should not contain other * labels, and should be in the
+authoritative data of the zone.  The wildcards potentially apply to
+descendants of <anydomain>, but not to <anydomain> itself.  Another way
+
+
+
+Mockapetris                                                    [Page 25]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+to look at this is that the "*" label always matches at least one whole
+label and sometimes more, but always whole labels.
+
+Wildcard RRs do not apply:
+
+   - When the query is in another zone.  That is, delegation cancels
+     the wildcard defaults.
+
+   - When the query name or a name between the wildcard domain and
+     the query name is know to exist.  For example, if a wildcard
+     RR has an owner name of "*.X", and the zone also contains RRs
+     attached to B.X, the wildcards would apply to queries for name
+     Z.X (presuming there is no explicit information for Z.X), but
+     not to B.X, A.B.X, or X.
+
+A * label appearing in a query name has no special effect, but can be
+used to test for wildcards in an authoritative zone; such a query is the
+only way to get a response containing RRs with an owner name with * in
+it.  The result of such a query should not be cached.
+
+Note that the contents of the wildcard RRs are not modified when used to
+synthesize RRs.
+
+To illustrate the use of wildcard RRs, suppose a large company with a
+large, non-IP/TCP, network wanted to create a mail gateway.  If the
+company was called X.COM, and IP/TCP capable gateway machine was called
+A.X.COM, the following RRs might be entered into the COM zone:
+
+    X.COM           MX      10      A.X.COM
+
+    *.X.COM         MX      10      A.X.COM
+
+    A.X.COM         A       1.2.3.4
+    A.X.COM         MX      10      A.X.COM
+
+    *.A.X.COM       MX      10      A.X.COM
+
+This would cause any MX query for any domain name ending in X.COM to
+return an MX RR pointing at A.X.COM.  Two wildcard RRs are required
+since the effect of the wildcard at *.X.COM is inhibited in the A.X.COM
+subtree by the explicit data for A.X.COM.  Note also that the explicit
+MX data at X.COM and A.X.COM is required, and that none of the RRs above
+would match a query name of XX.COM.
+
+4.3.4. Negative response caching (Optional)
+
+The DNS provides an optional service which allows name servers to
+distribute, and resolvers to cache, negative results with TTLs.  For
+
+
+
+Mockapetris                                                    [Page 26]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+example, a name server can distribute a TTL along with a name error
+indication, and a resolver receiving such information is allowed to
+assume that the name does not exist during the TTL period without
+consulting authoritative data.  Similarly, a resolver can make a query
+with a QTYPE which matches multiple types, and cache the fact that some
+of the types are not present.
+
+This feature can be particularly important in a system which implements
+naming shorthands that use search lists beacuse a popular shorthand,
+which happens to require a suffix toward the end of the search list,
+will generate multiple name errors whenever it is used.
+
+The method is that a name server may add an SOA RR to the additional
+section of a response when that response is authoritative.  The SOA must
+be that of the zone which was the source of the authoritative data in
+the answer section, or name error if applicable.  The MINIMUM field of
+the SOA controls the length of time that the negative result may be
+cached.
+
+Note that in some circumstances, the answer section may contain multiple
+owner names.  In this case, the SOA mechanism should only be used for
+the data which matches QNAME, which is the only authoritative data in
+this section.
+
+Name servers and resolvers should never attempt to add SOAs to the
+additional section of a non-authoritative response, or attempt to infer
+results which are not directly stated in an authoritative response.
+There are several reasons for this, including: cached information isn't
+usually enough to match up RRs and their zone names, SOA RRs may be
+cached due to direct SOA queries, and name servers are not required to
+output the SOAs in the authority section.
+
+This feature is optional, although a refined version is expected to
+become part of the standard protocol in the future.  Name servers are
+not required to add the SOA RRs in all authoritative responses, nor are
+resolvers required to cache negative results.  Both are recommended.
+All resolvers and recursive name servers are required to at least be
+able to ignore the SOA RR when it is present in a response.
+
+Some experiments have also been proposed which will use this feature.
+The idea is that if cached data is known to come from a particular zone,
+and if an authoritative copy of the zone's SOA is obtained, and if the
+zone's SERIAL has not changed since the data was cached, then the TTL of
+the cached data can be reset to the zone MINIMUM value if it is smaller.
+This usage is mentioned for planning purposes only, and is not
+recommended as yet.
+
+
+
+
+
+Mockapetris                                                    [Page 27]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+4.3.5. Zone maintenance and transfers
+
+Part of the job of a zone administrator is to maintain the zones at all
+of the name servers which are authoritative for the zone.  When the
+inevitable changes are made, they must be distributed to all of the name
+servers.  While this distribution can be accomplished using FTP or some
+other ad hoc procedure, the preferred method is the zone transfer part
+of the DNS protocol.
+
+The general model of automatic zone transfer or refreshing is that one
+of the name servers is the master or primary for the zone.  Changes are
+coordinated at the primary, typically by editing a master file for the
+zone.  After editing, the administrator signals the master server to
+load the new zone.  The other non-master or secondary servers for the
+zone periodically check for changes (at a selectable interval) and
+obtain new zone copies when changes have been made.
+
+To detect changes, secondaries just check the SERIAL field of the SOA
+for the zone.  In addition to whatever other changes are made, the
+SERIAL field in the SOA of the zone is always advanced whenever any
+change is made to the zone.  The advancing can be a simple increment, or
+could be based on the write date and time of the master file, etc.  The
+purpose is to make it possible to determine which of two copies of a
+zone is more recent by comparing serial numbers.  Serial number advances
+and comparisons use sequence space arithmetic, so there is a theoretic
+limit on how fast a zone can be updated, basically that old copies must
+die out before the serial number covers half of its 32 bit range.  In
+practice, the only concern is that the compare operation deals properly
+with comparisons around the boundary between the most positive and most
+negative 32 bit numbers.
+
+The periodic polling of the secondary servers is controlled by
+parameters in the SOA RR for the zone, which set the minimum acceptable
+polling intervals.  The parameters are called REFRESH, RETRY, and
+EXPIRE.  Whenever a new zone is loaded in a secondary, the secondary
+waits REFRESH seconds before checking with the primary for a new serial.
+If this check cannot be completed, new checks are started every RETRY
+seconds.  The check is a simple query to the primary for the SOA RR of
+the zone.  If the serial field in the secondary's zone copy is equal to
+the serial returned by the primary, then no changes have occurred, and
+the REFRESH interval wait is restarted.  If the secondary finds it
+impossible to perform a serial check for the EXPIRE interval, it must
+assume that its copy of the zone is obsolete an discard it.
+
+When the poll shows that the zone has changed, then the secondary server
+must request a zone transfer via an AXFR request for the zone.  The AXFR
+may cause an error, such as refused, but normally is answered by a
+sequence of response messages.  The first and last messages must contain
+
+
+
+Mockapetris                                                    [Page 28]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+the data for the top authoritative node of the zone.  Intermediate
+messages carry all of the other RRs from the zone, including both
+authoritative and non-authoritative RRs.  The stream of messages allows
+the secondary to construct a copy of the zone.  Because accuracy is
+essential, TCP or some other reliable protocol must be used for AXFR
+requests.
+
+Each secondary server is required to perform the following operations
+against the master, but may also optionally perform these operations
+against other secondary servers.  This strategy can improve the transfer
+process when the primary is unavailable due to host downtime or network
+problems, or when a secondary server has better network access to an
+"intermediate" secondary than to the primary.
+
+5. RESOLVERS
+
+5.1. Introduction
+
+Resolvers are programs that interface user programs to domain name
+servers.  In the simplest case, a resolver receives a request from a
+user program (e.g., mail programs, TELNET, FTP) in the form of a
+subroutine call, system call etc., and returns the desired information
+in a form compatible with the local host's data formats.
+
+The resolver is located on the same machine as the program that requests
+the resolver's services, but it may need to consult name servers on
+other hosts.  Because a resolver may need to consult several name
+servers, or may have the requested information in a local cache, the
+amount of time that a resolver will take to complete can vary quite a
+bit, from milliseconds to several seconds.
+
+A very important goal of the resolver is to eliminate network delay and
+name server load from most requests by answering them from its cache of
+prior results.  It follows that caches which are shared by multiple
+processes, users, machines, etc., are more efficient than non-shared
+caches.
+
+5.2. Client-resolver interface
+
+5.2.1. Typical functions
+
+The client interface to the resolver is influenced by the local host's
+conventions, but the typical resolver-client interface has three
+functions:
+
+   1. Host name to host address translation.
+
+      This function is often defined to mimic a previous HOSTS.TXT
+
+
+
+Mockapetris                                                    [Page 29]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+      based function.  Given a character string, the caller wants
+      one or more 32 bit IP addresses.  Under the DNS, it
+      translates into a request for type A RRs.  Since the DNS does
+      not preserve the order of RRs, this function may choose to
+      sort the returned addresses or select the "best" address if
+      the service returns only one choice to the client.  Note that
+      a multiple address return is recommended, but a single
+      address may be the only way to emulate prior HOSTS.TXT
+      services.
+
+   2. Host address to host name translation
+
+      This function will often follow the form of previous
+      functions.  Given a 32 bit IP address, the caller wants a
+      character string.  The octets of the IP address are reversed,
+      used as name components, and suffixed with "IN-ADDR.ARPA".  A
+      type PTR query is used to get the RR with the primary name of
+      the host.  For example, a request for the host name
+      corresponding to IP address 1.2.3.4 looks for PTR RRs for
+      domain name "4.3.2.1.IN-ADDR.ARPA".
+
+   3. General lookup function
+
+      This function retrieves arbitrary information from the DNS,
+      and has no counterpart in previous systems.  The caller
+      supplies a QNAME, QTYPE, and QCLASS, and wants all of the
+      matching RRs.  This function will often use the DNS format
+      for all RR data instead of the local host's, and returns all
+      RR content (e.g., TTL) instead of a processed form with local
+      quoting conventions.
+
+When the resolver performs the indicated function, it usually has one of
+the following results to pass back to the client:
+
+   - One or more RRs giving the requested data.
+
+     In this case the resolver returns the answer in the
+     appropriate format.
+
+   - A name error (NE).
+
+     This happens when the referenced name does not exist.  For
+     example, a user may have mistyped a host name.
+
+   - A data not found error.
+
+     This happens when the referenced name exists, but data of the
+     appropriate type does not.  For example, a host address
+
+
+
+Mockapetris                                                    [Page 30]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+     function applied to a mailbox name would return this error
+     since the name exists, but no address RR is present.
+
+It is important to note that the functions for translating between host
+names and addresses may combine the "name error" and "data not found"
+error conditions into a single type of error return, but the general
+function should not.  One reason for this is that applications may ask
+first for one type of information about a name followed by a second
+request to the same name for some other type of information; if the two
+errors are combined, then useless queries may slow the application.
+
+5.2.2. Aliases
+
+While attempting to resolve a particular request, the resolver may find
+that the name in question is an alias.  For example, the resolver might
+find that the name given for host name to address translation is an
+alias when it finds the CNAME RR.  If possible, the alias condition
+should be signalled back from the resolver to the client.
+
+In most cases a resolver simply restarts the query at the new name when
+it encounters a CNAME.  However, when performing the general function,
+the resolver should not pursue aliases when the CNAME RR matches the
+query type.  This allows queries which ask whether an alias is present.
+For example, if the query type is CNAME, the user is interested in the
+CNAME RR itself, and not the RRs at the name it points to.
+
+Several special conditions can occur with aliases.  Multiple levels of
+aliases should be avoided due to their lack of efficiency, but should
+not be signalled as an error.  Alias loops and aliases which point to
+non-existent names should be caught and an error condition passed back
+to the client.
+
+5.2.3. Temporary failures
+
+In a less than perfect world, all resolvers will occasionally be unable
+to resolve a particular request.  This condition can be caused by a
+resolver which becomes separated from the rest of the network due to a
+link failure or gateway problem, or less often by coincident failure or
+unavailability of all servers for a particular domain.
+
+It is essential that this sort of condition should not be signalled as a
+name or data not present error to applications.  This sort of behavior
+is annoying to humans, and can wreak havoc when mail systems use the
+DNS.
+
+While in some cases it is possible to deal with such a temporary problem
+by blocking the request indefinitely, this is usually not a good choice,
+particularly when the client is a server process that could move on to
+
+
+
+Mockapetris                                                    [Page 31]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+other tasks.  The recommended solution is to always have temporary
+failure as one of the possible results of a resolver function, even
+though this may make emulation of existing HOSTS.TXT functions more
+difficult.
+
+5.3. Resolver internals
+
+Every resolver implementation uses slightly different algorithms, and
+typically spends much more logic dealing with errors of various sorts
+than typical occurances.  This section outlines a recommended basic
+strategy for resolver operation, but leaves details to [RFC-1035].
+
+5.3.1. Stub resolvers
+
+One option for implementing a resolver is to move the resolution
+function out of the local machine and into a name server which supports
+recursive queries.  This can provide an easy method of providing domain
+service in a PC which lacks the resources to perform the resolver
+function, or can centralize the cache for a whole local network or
+organization.
+
+All that the remaining stub needs is a list of name server addresses
+that will perform the recursive requests.  This type of resolver
+presumably needs the information in a configuration file, since it
+probably lacks the sophistication to locate it in the domain database.
+The user also needs to verify that the listed servers will perform the
+recursive service; a name server is free to refuse to perform recursive
+services for any or all clients.  The user should consult the local
+system administrator to find name servers willing to perform the
+service.
+
+This type of service suffers from some drawbacks.  Since the recursive
+requests may take an arbitrary amount of time to perform, the stub may
+have difficulty optimizing retransmission intervals to deal with both
+lost UDP packets and dead servers; the name server can be easily
+overloaded by too zealous a stub if it interprets retransmissions as new
+requests.  Use of TCP may be an answer, but TCP may well place burdens
+on the host's capabilities which are similar to those of a real
+resolver.
+
+5.3.2. Resources
+
+In addition to its own resources, the resolver may also have shared
+access to zones maintained by a local name server.  This gives the
+resolver the advantage of more rapid access, but the resolver must be
+careful to never let cached information override zone data.  In this
+discussion the term "local information" is meant to mean the union of
+the cache and such shared zones, with the understanding that
+
+
+
+Mockapetris                                                    [Page 32]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+authoritative data is always used in preference to cached data when both
+are present.
+
+The following resolver algorithm assumes that all functions have been
+converted to a general lookup function, and uses the following data
+structures to represent the state of a request in progress in the
+resolver:
+
+SNAME           the domain name we are searching for.
+
+STYPE           the QTYPE of the search request.
+
+SCLASS          the QCLASS of the search request.
+
+SLIST           a structure which describes the name servers and the
+                zone which the resolver is currently trying to query.
+                This structure keeps track of the resolver's current
+                best guess about which name servers hold the desired
+                information; it is updated when arriving information
+                changes the guess.  This structure includes the
+                equivalent of a zone name, the known name servers for
+                the zone, the known addresses for the name servers, and
+                history information which can be used to suggest which
+                server is likely to be the best one to try next.  The
+                zone name equivalent is a match count of the number of
+                labels from the root down which SNAME has in common with
+                the zone being queried; this is used as a measure of how
+                "close" the resolver is to SNAME.
+
+SBELT           a "safety belt" structure of the same form as SLIST,
+                which is initialized from a configuration file, and
+                lists servers which should be used when the resolver
+                doesn't have any local information to guide name server
+                selection.  The match count will be -1 to indicate that
+                no labels are known to match.
+
+CACHE           A structure which stores the results from previous
+                responses.  Since resolvers are responsible for
+                discarding old RRs whose TTL has expired, most
+                implementations convert the interval specified in
+                arriving RRs to some sort of absolute time when the RR
+                is stored in the cache.  Instead of counting the TTLs
+                down individually, the resolver just ignores or discards
+                old RRs when it runs across them in the course of a
+                search, or discards them during periodic sweeps to
+                reclaim the memory consumed by old RRs.
+
+
+
+
+
+Mockapetris                                                    [Page 33]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+5.3.3. Algorithm
+
+The top level algorithm has four steps:
+
+   1. See if the answer is in local information, and if so return
+      it to the client.
+
+   2. Find the best servers to ask.
+
+   3. Send them queries until one returns a response.
+
+   4. Analyze the response, either:
+
+         a. if the response answers the question or contains a name
+            error, cache the data as well as returning it back to
+            the client.
+
+         b. if the response contains a better delegation to other
+            servers, cache the delegation information, and go to
+            step 2.
+
+         c. if the response shows a CNAME and that is not the
+            answer itself, cache the CNAME, change the SNAME to the
+            canonical name in the CNAME RR and go to step 1.
+
+         d. if the response shows a servers failure or other
+            bizarre contents, delete the server from the SLIST and
+            go back to step 3.
+
+Step 1 searches the cache for the desired data. If the data is in the
+cache, it is assumed to be good enough for normal use.  Some resolvers
+have an option at the user interface which will force the resolver to
+ignore the cached data and consult with an authoritative server.  This
+is not recommended as the default.  If the resolver has direct access to
+a name server's zones, it should check to see if the desired data is
+present in authoritative form, and if so, use the authoritative data in
+preference to cached data.
+
+Step 2 looks for a name server to ask for the required data.  The
+general strategy is to look for locally-available name server RRs,
+starting at SNAME, then the parent domain name of SNAME, the
+grandparent, and so on toward the root.  Thus if SNAME were
+Mockapetris.ISI.EDU, this step would look for NS RRs for
+Mockapetris.ISI.EDU, then ISI.EDU, then EDU, and then . (the root).
+These NS RRs list the names of hosts for a zone at or above SNAME.  Copy
+the names into SLIST.  Set up their addresses using local data.  It may
+be the case that the addresses are not available.  The resolver has many
+choices here; the best is to start parallel resolver processes looking
+
+
+
+Mockapetris                                                    [Page 34]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+for the addresses while continuing onward with the addresses which are
+available.  Obviously, the design choices and options are complicated
+and a function of the local host's capabilities.  The recommended
+priorities for the resolver designer are:
+
+   1. Bound the amount of work (packets sent, parallel processes
+      started) so that a request can't get into an infinite loop or
+      start off a chain reaction of requests or queries with other
+      implementations EVEN IF SOMEONE HAS INCORRECTLY CONFIGURED
+      SOME DATA.
+
+   2. Get back an answer if at all possible.
+
+   3. Avoid unnecessary transmissions.
+
+   4. Get the answer as quickly as possible.
+
+If the search for NS RRs fails, then the resolver initializes SLIST from
+the safety belt SBELT.  The basic idea is that when the resolver has no
+idea what servers to ask, it should use information from a configuration
+file that lists several servers which are expected to be helpful.
+Although there are special situations, the usual choice is two of the
+root servers and two of the servers for the host's domain.  The reason
+for two of each is for redundancy.  The root servers will provide
+eventual access to all of the domain space.  The two local servers will
+allow the resolver to continue to resolve local names if the local
+network becomes isolated from the internet due to gateway or link
+failure.
+
+In addition to the names and addresses of the servers, the SLIST data
+structure can be sorted to use the best servers first, and to insure
+that all addresses of all servers are used in a round-robin manner.  The
+sorting can be a simple function of preferring addresses on the local
+network over others, or may involve statistics from past events, such as
+previous response times and batting averages.
+
+Step 3 sends out queries until a response is received.  The strategy is
+to cycle around all of the addresses for all of the servers with a
+timeout between each transmission.  In practice it is important to use
+all addresses of a multihomed host, and too aggressive a retransmission
+policy actually slows response when used by multiple resolvers
+contending for the same name server and even occasionally for a single
+resolver.  SLIST typically contains data values to control the timeouts
+and keep track of previous transmissions.
+
+Step 4 involves analyzing responses.  The resolver should be highly
+paranoid in its parsing of responses.  It should also check that the
+response matches the query it sent using the ID field in the response.
+
+
+
+Mockapetris                                                    [Page 35]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+The ideal answer is one from a server authoritative for the query which
+either gives the required data or a name error.  The data is passed back
+to the user and entered in the cache for future use if its TTL is
+greater than zero.
+
+If the response shows a delegation, the resolver should check to see
+that the delegation is "closer" to the answer than the servers in SLIST
+are.  This can be done by comparing the match count in SLIST with that
+computed from SNAME and the NS RRs in the delegation.  If not, the reply
+is bogus and should be ignored.  If the delegation is valid the NS
+delegation RRs and any address RRs for the servers should be cached.
+The name servers are entered in the SLIST, and the search is restarted.
+
+If the response contains a CNAME, the search is restarted at the CNAME
+unless the response has the data for the canonical name or if the CNAME
+is the answer itself.
+
+Details and implementation hints can be found in [RFC-1035].
+
+6. A SCENARIO
+
+In our sample domain space, suppose we wanted separate administrative
+control for the root, MIL, EDU, MIT.EDU and ISI.EDU zones.  We might
+allocate name servers as follows:
+
+
+                                   |(C.ISI.EDU,SRI-NIC.ARPA
+                                   | A.ISI.EDU)
+             +---------------------+------------------+
+             |                     |                  |
+            MIL                   EDU                ARPA
+             |(SRI-NIC.ARPA,       |(SRI-NIC.ARPA,    |
+             | A.ISI.EDU           | C.ISI.EDU)       |
+       +-----+-----+               |     +------+-----+-----+
+       |     |     |               |     |      |           |
+      BRL  NOSC  DARPA             |  IN-ADDR  SRI-NIC     ACC
+                                   |
+       +--------+------------------+---------------+--------+
+       |        |                  |               |        |
+      UCI      MIT                 |              UDEL     YALE
+                |(XX.LCS.MIT.EDU, ISI
+                |ACHILLES.MIT.EDU) |(VAXA.ISI.EDU,VENERA.ISI.EDU,
+            +---+---+              | A.ISI.EDU)
+            |       |              |
+           LCS   ACHILLES +--+-----+-----+--------+
+            |             |  |     |     |        |
+            XX            A  C   VAXA  VENERA Mockapetris
+
+
+
+
+Mockapetris                                                    [Page 36]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+In this example, the authoritative name server is shown in parentheses
+at the point in the domain tree at which is assumes control.
+
+Thus the root name servers are on C.ISI.EDU, SRI-NIC.ARPA, and
+A.ISI.EDU.  The MIL domain is served by SRI-NIC.ARPA and A.ISI.EDU.  The
+EDU domain is served by SRI-NIC.ARPA. and C.ISI.EDU.  Note that servers
+may have zones which are contiguous or disjoint.  In this scenario,
+C.ISI.EDU has contiguous zones at the root and EDU domains.  A.ISI.EDU
+has contiguous zones at the root and MIL domains, but also has a non-
+contiguous zone at ISI.EDU.
+
+6.1. C.ISI.EDU name server
+
+C.ISI.EDU is a name server for the root, MIL, and EDU domains of the IN
+class, and would have zones for these domains.  The zone data for the
+root domain might be:
+
+    .       IN      SOA     SRI-NIC.ARPA. HOSTMASTER.SRI-NIC.ARPA. (
+                            870611          ;serial
+                            1800            ;refresh every 30 min
+                            300             ;retry every 5 min
+                            604800          ;expire after a week
+                            86400)          ;minimum of a day
+                    NS      A.ISI.EDU.
+                    NS      C.ISI.EDU.
+                    NS      SRI-NIC.ARPA.
+
+    MIL.    86400   NS      SRI-NIC.ARPA.
+            86400   NS      A.ISI.EDU.
+
+    EDU.    86400   NS      SRI-NIC.ARPA.
+            86400   NS      C.ISI.EDU.
+
+    SRI-NIC.ARPA.   A       26.0.0.73
+                    A       10.0.0.51
+                    MX      0 SRI-NIC.ARPA.
+                    HINFO   DEC-2060 TOPS20
+
+    ACC.ARPA.       A       26.6.0.65
+                    HINFO   PDP-11/70 UNIX
+                    MX      10 ACC.ARPA.
+
+    USC-ISIC.ARPA.  CNAME   C.ISI.EDU.
+
+    73.0.0.26.IN-ADDR.ARPA.  PTR    SRI-NIC.ARPA.
+    65.0.6.26.IN-ADDR.ARPA.  PTR    ACC.ARPA.
+    51.0.0.10.IN-ADDR.ARPA.  PTR    SRI-NIC.ARPA.
+    52.0.0.10.IN-ADDR.ARPA.  PTR    C.ISI.EDU.
+
+
+
+Mockapetris                                                    [Page 37]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+    103.0.3.26.IN-ADDR.ARPA. PTR    A.ISI.EDU.
+
+    A.ISI.EDU. 86400 A      26.3.0.103
+    C.ISI.EDU. 86400 A      10.0.0.52
+
+This data is represented as it would be in a master file.  Most RRs are
+single line entries; the sole exception here is the SOA RR, which uses
+"(" to start a multi-line RR and ")" to show the end of a multi-line RR.
+Since the class of all RRs in a zone must be the same, only the first RR
+in a zone need specify the class.  When a name server loads a zone, it
+forces the TTL of all authoritative RRs to be at least the MINIMUM field
+of the SOA, here 86400 seconds, or one day.  The NS RRs marking
+delegation of the MIL and EDU domains, together with the glue RRs for
+the servers host addresses, are not part of the authoritative data in
+the zone, and hence have explicit TTLs.
+
+Four RRs are attached to the root node: the SOA which describes the root
+zone and the 3 NS RRs which list the name servers for the root.  The
+data in the SOA RR describes the management of the zone.  The zone data
+is maintained on host SRI-NIC.ARPA, and the responsible party for the
+zone is HOSTMASTER@SRI-NIC.ARPA.  A key item in the SOA is the 86400
+second minimum TTL, which means that all authoritative data in the zone
+has at least that TTL, although higher values may be explicitly
+specified.
+
+The NS RRs for the MIL and EDU domains mark the boundary between the
+root zone and the MIL and EDU zones.  Note that in this example, the
+lower zones happen to be supported by name servers which also support
+the root zone.
+
+The master file for the EDU zone might be stated relative to the origin
+EDU.  The zone data for the EDU domain might be:
+
+    EDU.  IN SOA SRI-NIC.ARPA. HOSTMASTER.SRI-NIC.ARPA. (
+                            870729 ;serial
+                            1800 ;refresh every 30 minutes
+                            300 ;retry every 5 minutes
+                            604800 ;expire after a week
+                            86400 ;minimum of a day
+                            )
+                    NS SRI-NIC.ARPA.
+                    NS C.ISI.EDU.
+
+    UCI 172800 NS ICS.UCI
+                    172800 NS ROME.UCI
+    ICS.UCI 172800 A 192.5.19.1
+    ROME.UCI 172800 A 192.5.19.31
+
+
+
+
+Mockapetris                                                    [Page 38]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+    ISI 172800 NS VAXA.ISI
+                    172800 NS A.ISI
+                    172800 NS VENERA.ISI.EDU.
+    VAXA.ISI 172800 A 10.2.0.27
+                    172800 A 128.9.0.33
+    VENERA.ISI.EDU. 172800 A 10.1.0.52
+                    172800 A 128.9.0.32
+    A.ISI 172800 A 26.3.0.103
+
+    UDEL.EDU.  172800 NS LOUIE.UDEL.EDU.
+                    172800 NS UMN-REI-UC.ARPA.
+    LOUIE.UDEL.EDU. 172800 A 10.0.0.96
+                    172800 A 192.5.39.3
+
+    YALE.EDU.  172800 NS YALE.ARPA.
+    YALE.EDU.  172800 NS YALE-BULLDOG.ARPA.
+
+    MIT.EDU.  43200 NS XX.LCS.MIT.EDU.
+                      43200 NS ACHILLES.MIT.EDU.
+    XX.LCS.MIT.EDU.  43200 A 10.0.0.44
+    ACHILLES.MIT.EDU. 43200 A 18.72.0.8
+
+Note the use of relative names here.  The owner name for the ISI.EDU. is
+stated using a relative name, as are two of the name server RR contents.
+Relative and absolute domain names may be freely intermixed in a master
+
+6.2. Example standard queries
+
+The following queries and responses illustrate name server behavior.
+Unless otherwise noted, the queries do not have recursion desired (RD)
+in the header.  Note that the answers to non-recursive queries do depend
+on the server being asked, but do not depend on the identity of the
+requester.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mockapetris                                                    [Page 39]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+6.2.1. QNAME=SRI-NIC.ARPA, QTYPE=A
+
+The query would look like:
+
+               +---------------------------------------------------+
+    Header     | OPCODE=SQUERY                                     |
+               +---------------------------------------------------+
+    Question   | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=A           |
+               +---------------------------------------------------+
+    Answer     | <empty>                                           |
+               +---------------------------------------------------+
+    Authority  | <empty>                                           |
+               +---------------------------------------------------+
+    Additional | <empty>                                           |
+               +---------------------------------------------------+
+
+The response from C.ISI.EDU would be:
+
+               +---------------------------------------------------+
+    Header     | OPCODE=SQUERY, RESPONSE, AA                       |
+               +---------------------------------------------------+
+    Question   | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=A           |
+               +---------------------------------------------------+
+    Answer     | SRI-NIC.ARPA. 86400 IN A 26.0.0.73                |
+               |               86400 IN A 10.0.0.51                |
+               +---------------------------------------------------+
+    Authority  | <empty>                                           |
+               +---------------------------------------------------+
+    Additional | <empty>                                           |
+               +---------------------------------------------------+
+
+The header of the response looks like the header of the query, except
+that the RESPONSE bit is set, indicating that this message is a
+response, not a query, and the Authoritative Answer (AA) bit is set
+indicating that the address RRs in the answer section are from
+authoritative data.  The question section of the response matches the
+question section of the query.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mockapetris                                                    [Page 40]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+If the same query was sent to some other server which was not
+authoritative for SRI-NIC.ARPA, the response might be:
+
+               +---------------------------------------------------+
+    Header     | OPCODE=SQUERY,RESPONSE                            |
+               +---------------------------------------------------+
+    Question   | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=A           |
+               +---------------------------------------------------+
+    Answer     | SRI-NIC.ARPA. 1777 IN A 10.0.0.51                 |
+               |               1777 IN A 26.0.0.73                 |
+               +---------------------------------------------------+
+    Authority  | <empty>                                           |
+               +---------------------------------------------------+
+    Additional | <empty>                                           |
+               +---------------------------------------------------+
+
+This response is different from the previous one in two ways: the header
+does not have AA set, and the TTLs are different.  The inference is that
+the data did not come from a zone, but from a cache.  The difference
+between the authoritative TTL and the TTL here is due to aging of the
+data in a cache.  The difference in ordering of the RRs in the answer
+section is not significant.
+
+6.2.2. QNAME=SRI-NIC.ARPA, QTYPE=*
+
+A query similar to the previous one, but using a QTYPE of *, would
+receive the following response from C.ISI.EDU:
+
+               +---------------------------------------------------+
+    Header     | OPCODE=SQUERY, RESPONSE, AA                       |
+               +---------------------------------------------------+
+    Question   | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=*           |
+               +---------------------------------------------------+
+    Answer     | SRI-NIC.ARPA. 86400 IN  A     26.0.0.73           |
+               |                         A     10.0.0.51           |
+               |                         MX    0 SRI-NIC.ARPA.     |
+               |                         HINFO DEC-2060 TOPS20     |
+               +---------------------------------------------------+
+    Authority  | <empty>                                           |
+               +---------------------------------------------------+
+    Additional | <empty>                                           |
+               +---------------------------------------------------+
+
+
+
+
+
+
+
+
+
+Mockapetris                                                    [Page 41]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+If a similar query was directed to two name servers which are not
+authoritative for SRI-NIC.ARPA, the responses might be:
+
+               +---------------------------------------------------+
+    Header     | OPCODE=SQUERY, RESPONSE                           |
+               +---------------------------------------------------+
+    Question   | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=*           |
+               +---------------------------------------------------+
+    Answer     | SRI-NIC.ARPA. 12345 IN     A       26.0.0.73      |
+               |                            A       10.0.0.51      |
+               +---------------------------------------------------+
+    Authority  | <empty>                                           |
+               +---------------------------------------------------+
+    Additional | <empty>                                           |
+               +---------------------------------------------------+
+
+and
+
+               +---------------------------------------------------+
+    Header     | OPCODE=SQUERY, RESPONSE                           |
+               +---------------------------------------------------+
+    Question   | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=*           |
+               +---------------------------------------------------+
+    Answer     | SRI-NIC.ARPA. 1290 IN HINFO  DEC-2060 TOPS20      |
+               +---------------------------------------------------+
+    Authority  | <empty>                                           |
+               +---------------------------------------------------+
+    Additional | <empty>                                           |
+               +---------------------------------------------------+
+
+Neither of these answers have AA set, so neither response comes from
+authoritative data.  The different contents and different TTLs suggest
+that the two servers cached data at different times, and that the first
+server cached the response to a QTYPE=A query and the second cached the
+response to a HINFO query.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mockapetris                                                    [Page 42]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+6.2.3. QNAME=SRI-NIC.ARPA, QTYPE=MX
+
+This type of query might be result from a mailer trying to look up
+routing information for the mail destination HOSTMASTER@SRI-NIC.ARPA.
+The response from C.ISI.EDU would be:
+
+               +---------------------------------------------------+
+    Header     | OPCODE=SQUERY, RESPONSE, AA                       |
+               +---------------------------------------------------+
+    Question   | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=MX          |
+               +---------------------------------------------------+
+    Answer     | SRI-NIC.ARPA. 86400 IN     MX      0 SRI-NIC.ARPA.|
+               +---------------------------------------------------+
+    Authority  | <empty>                                           |
+               +---------------------------------------------------+
+    Additional | SRI-NIC.ARPA. 86400 IN     A       26.0.0.73      |
+               |                            A       10.0.0.51      |
+               +---------------------------------------------------+
+
+This response contains the MX RR in the answer section of the response.
+The additional section contains the address RRs because the name server
+at C.ISI.EDU guesses that the requester will need the addresses in order
+to properly use the information carried by the MX.
+
+6.2.4. QNAME=SRI-NIC.ARPA, QTYPE=NS
+
+C.ISI.EDU would reply to this query with:
+
+               +---------------------------------------------------+
+    Header     | OPCODE=SQUERY, RESPONSE, AA                       |
+               +---------------------------------------------------+
+    Question   | QNAME=SRI-NIC.ARPA., QCLASS=IN, QTYPE=NS          |
+               +---------------------------------------------------+
+    Answer     | <empty>                                           |
+               +---------------------------------------------------+
+    Authority  | <empty>                                           |
+               +---------------------------------------------------+
+    Additional | <empty>                                           |
+               +---------------------------------------------------+
+
+The only difference between the response and the query is the AA and
+RESPONSE bits in the header.  The interpretation of this response is
+that the server is authoritative for the name, and the name exists, but
+no RRs of type NS are present there.
+
+6.2.5. QNAME=SIR-NIC.ARPA, QTYPE=A
+
+If a user mistyped a host name, we might see this type of query.
+
+
+
+Mockapetris                                                    [Page 43]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+C.ISI.EDU would answer it with:
+
+               +---------------------------------------------------+
+    Header     | OPCODE=SQUERY, RESPONSE, AA, RCODE=NE             |
+               +---------------------------------------------------+
+    Question   | QNAME=SIR-NIC.ARPA., QCLASS=IN, QTYPE=A           |
+               +---------------------------------------------------+
+    Answer     | <empty>                                           |
+               +---------------------------------------------------+
+    Authority  | . SOA SRI-NIC.ARPA. HOSTMASTER.SRI-NIC.ARPA.      |
+               |       870611 1800 300 604800 86400                |
+               +---------------------------------------------------+
+    Additional | <empty>                                           |
+               +---------------------------------------------------+
+
+This response states that the name does not exist.  This condition is
+signalled in the response code (RCODE) section of the header.
+
+The SOA RR in the authority section is the optional negative caching
+information which allows the resolver using this response to assume that
+the name will not exist for the SOA MINIMUM (86400) seconds.
+
+6.2.6. QNAME=BRL.MIL, QTYPE=A
+
+If this query is sent to C.ISI.EDU, the reply would be:
+
+               +---------------------------------------------------+
+    Header     | OPCODE=SQUERY, RESPONSE                           |
+               +---------------------------------------------------+
+    Question   | QNAME=BRL.MIL, QCLASS=IN, QTYPE=A                 |
+               +---------------------------------------------------+
+    Answer     | <empty>                                           |
+               +---------------------------------------------------+
+    Authority  | MIL.             86400 IN NS       SRI-NIC.ARPA.  |
+               |                  86400    NS       A.ISI.EDU.     |
+               +---------------------------------------------------+
+    Additional | A.ISI.EDU.                A        26.3.0.103     |
+               | SRI-NIC.ARPA.             A        26.0.0.73      |
+               |                           A        10.0.0.51      |
+               +---------------------------------------------------+
+
+This response has an empty answer section, but is not authoritative, so
+it is a referral.  The name server on C.ISI.EDU, realizing that it is
+not authoritative for the MIL domain, has referred the requester to
+servers on A.ISI.EDU and SRI-NIC.ARPA, which it knows are authoritative
+for the MIL domain.
+
+
+
+
+
+Mockapetris                                                    [Page 44]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+6.2.7. QNAME=USC-ISIC.ARPA, QTYPE=A
+
+The response to this query from A.ISI.EDU would be:
+
+               +---------------------------------------------------+
+    Header     | OPCODE=SQUERY, RESPONSE, AA                       |
+               +---------------------------------------------------+
+    Question   | QNAME=USC-ISIC.ARPA., QCLASS=IN, QTYPE=A          |
+               +---------------------------------------------------+
+    Answer     | USC-ISIC.ARPA. 86400 IN CNAME      C.ISI.EDU.     |
+               | C.ISI.EDU.     86400 IN A          10.0.0.52      |
+               +---------------------------------------------------+
+    Authority  | <empty>                                           |
+               +---------------------------------------------------+
+    Additional | <empty>                                           |
+               +---------------------------------------------------+
+
+Note that the AA bit in the header guarantees that the data matching
+QNAME is authoritative, but does not say anything about whether the data
+for C.ISI.EDU is authoritative.  This complete reply is possible because
+A.ISI.EDU happens to be authoritative for both the ARPA domain where
+USC-ISIC.ARPA is found and the ISI.EDU domain where C.ISI.EDU data is
+found.
+
+If the same query was sent to C.ISI.EDU, its response might be the same
+as shown above if it had its own address in its cache, but might also
+be:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mockapetris                                                    [Page 45]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+               +---------------------------------------------------+
+    Header     | OPCODE=SQUERY, RESPONSE, AA                       |
+               +---------------------------------------------------+
+    Question   | QNAME=USC-ISIC.ARPA., QCLASS=IN, QTYPE=A          |
+               +---------------------------------------------------+
+    Answer     | USC-ISIC.ARPA.   86400 IN CNAME   C.ISI.EDU.      |
+               +---------------------------------------------------+
+    Authority  | ISI.EDU.        172800 IN NS      VAXA.ISI.EDU.   |
+               |                           NS      A.ISI.EDU.      |
+               |                           NS      VENERA.ISI.EDU. |
+               +---------------------------------------------------+
+    Additional | VAXA.ISI.EDU.   172800    A       10.2.0.27       |
+               |                 172800    A       128.9.0.33      |
+               | VENERA.ISI.EDU. 172800    A       10.1.0.52       |
+               |                 172800    A       128.9.0.32      |
+               | A.ISI.EDU.      172800    A       26.3.0.103      |
+               +---------------------------------------------------+
+
+This reply contains an authoritative reply for the alias USC-ISIC.ARPA,
+plus a referral to the name servers for ISI.EDU.  This sort of reply
+isn't very likely given that the query is for the host name of the name
+server being asked, but would be common for other aliases.
+
+6.2.8. QNAME=USC-ISIC.ARPA, QTYPE=CNAME
+
+If this query is sent to either A.ISI.EDU or C.ISI.EDU, the reply would
+be:
+
+               +---------------------------------------------------+
+    Header     | OPCODE=SQUERY, RESPONSE, AA                       |
+               +---------------------------------------------------+
+    Question   | QNAME=USC-ISIC.ARPA., QCLASS=IN, QTYPE=A          |
+               +---------------------------------------------------+
+    Answer     | USC-ISIC.ARPA. 86400 IN CNAME      C.ISI.EDU.     |
+               +---------------------------------------------------+
+    Authority  | <empty>                                           |
+               +---------------------------------------------------+
+    Additional | <empty>                                           |
+               +---------------------------------------------------+
+
+Because QTYPE=CNAME, the CNAME RR itself answers the query, and the name
+server doesn't attempt to look up anything for C.ISI.EDU.  (Except
+possibly for the additional section.)
+
+6.3. Example resolution
+
+The following examples illustrate the operations a resolver must perform
+for its client.  We assume that the resolver is starting without a
+
+
+
+Mockapetris                                                    [Page 46]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+cache, as might be the case after system boot.  We further assume that
+the system is not one of the hosts in the data and that the host is
+located somewhere on net 26, and that its safety belt (SBELT) data
+structure has the following information:
+
+    Match count = -1
+    SRI-NIC.ARPA.   26.0.0.73       10.0.0.51
+    A.ISI.EDU.      26.3.0.103
+
+This information specifies servers to try, their addresses, and a match
+count of -1, which says that the servers aren't very close to the
+target.  Note that the -1 isn't supposed to be an accurate closeness
+measure, just a value so that later stages of the algorithm will work.
+
+The following examples illustrate the use of a cache, so each example
+assumes that previous requests have completed.
+
+6.3.1. Resolve MX for ISI.EDU.
+
+Suppose the first request to the resolver comes from the local mailer,
+which has mail for PVM@ISI.EDU.  The mailer might then ask for type MX
+RRs for the domain name ISI.EDU.
+
+The resolver would look in its cache for MX RRs at ISI.EDU, but the
+empty cache wouldn't be helpful.  The resolver would recognize that it
+needed to query foreign servers and try to determine the best servers to
+query.  This search would look for NS RRs for the domains ISI.EDU, EDU,
+and the root.  These searches of the cache would also fail.  As a last
+resort, the resolver would use the information from the SBELT, copying
+it into its SLIST structure.
+
+At this point the resolver would need to pick one of the three available
+addresses to try.  Given that the resolver is on net 26, it should
+choose either 26.0.0.73 or 26.3.0.103 as its first choice.  It would
+then send off a query of the form:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mockapetris                                                    [Page 47]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+               +---------------------------------------------------+
+    Header     | OPCODE=SQUERY                                     |
+               +---------------------------------------------------+
+    Question   | QNAME=ISI.EDU., QCLASS=IN, QTYPE=MX               |
+               +---------------------------------------------------+
+    Answer     | <empty>                                           |
+               +---------------------------------------------------+
+    Authority  | <empty>                                           |
+               +---------------------------------------------------+
+    Additional | <empty>                                           |
+               +---------------------------------------------------+
+
+The resolver would then wait for a response to its query or a timeout.
+If the timeout occurs, it would try different servers, then different
+addresses of the same servers, lastly retrying addresses already tried.
+It might eventually receive a reply from SRI-NIC.ARPA:
+
+               +---------------------------------------------------+
+    Header     | OPCODE=SQUERY, RESPONSE                           |
+               +---------------------------------------------------+
+    Question   | QNAME=ISI.EDU., QCLASS=IN, QTYPE=MX               |
+               +---------------------------------------------------+
+    Answer     | <empty>                                           |
+               +---------------------------------------------------+
+    Authority  | ISI.EDU.        172800 IN NS       VAXA.ISI.EDU.  |
+               |                           NS       A.ISI.EDU.     |
+               |                           NS       VENERA.ISI.EDU.|
+               +---------------------------------------------------+
+    Additional | VAXA.ISI.EDU.   172800    A        10.2.0.27      |
+               |                 172800    A        128.9.0.33     |
+               | VENERA.ISI.EDU. 172800    A        10.1.0.52      |
+               |                 172800    A        128.9.0.32     |
+               | A.ISI.EDU.      172800    A        26.3.0.103     |
+               +---------------------------------------------------+
+
+The resolver would notice that the information in the response gave a
+closer delegation to ISI.EDU than its existing SLIST (since it matches
+three labels).  The resolver would then cache the information in this
+response and use it to set up a new SLIST:
+
+    Match count = 3
+    A.ISI.EDU.      26.3.0.103
+    VAXA.ISI.EDU.   10.2.0.27       128.9.0.33
+    VENERA.ISI.EDU. 10.1.0.52       128.9.0.32
+
+A.ISI.EDU appears on this list as well as the previous one, but that is
+purely coincidental.  The resolver would again start transmitting and
+waiting for responses.  Eventually it would get an answer:
+
+
+
+Mockapetris                                                    [Page 48]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+               +---------------------------------------------------+
+    Header     | OPCODE=SQUERY, RESPONSE, AA                       |
+               +---------------------------------------------------+
+    Question   | QNAME=ISI.EDU., QCLASS=IN, QTYPE=MX               |
+               +---------------------------------------------------+
+    Answer     | ISI.EDU.                MX 10 VENERA.ISI.EDU.     |
+               |                         MX 20 VAXA.ISI.EDU.       |
+               +---------------------------------------------------+
+    Authority  | <empty>                                           |
+               +---------------------------------------------------+
+    Additional | VAXA.ISI.EDU.   172800  A  10.2.0.27              |
+               |                 172800  A  128.9.0.33             |
+               | VENERA.ISI.EDU. 172800  A  10.1.0.52              |
+               |                 172800  A  128.9.0.32             |
+               +---------------------------------------------------+
+
+The resolver would add this information to its cache, and return the MX
+RRs to its client.
+
+6.3.2. Get the host name for address 26.6.0.65
+
+The resolver would translate this into a request for PTR RRs for
+65.0.6.26.IN-ADDR.ARPA.  This information is not in the cache, so the
+resolver would look for foreign servers to ask.  No servers would match,
+so it would use SBELT again.  (Note that the servers for the ISI.EDU
+domain are in the cache, but ISI.EDU is not an ancestor of
+65.0.6.26.IN-ADDR.ARPA, so the SBELT is used.)
+
+Since this request is within the authoritative data of both servers in
+SBELT, eventually one would return:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mockapetris                                                    [Page 49]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+               +---------------------------------------------------+
+    Header     | OPCODE=SQUERY, RESPONSE, AA                       |
+               +---------------------------------------------------+
+    Question   | QNAME=65.0.6.26.IN-ADDR.ARPA.,QCLASS=IN,QTYPE=PTR |
+               +---------------------------------------------------+
+    Answer     | 65.0.6.26.IN-ADDR.ARPA.    PTR     ACC.ARPA.      |
+               +---------------------------------------------------+
+    Authority  | <empty>                                           |
+               +---------------------------------------------------+
+    Additional | <empty>                                           |
+               +---------------------------------------------------+
+
+6.3.3. Get the host address of poneria.ISI.EDU
+
+This request would translate into a type A request for poneria.ISI.EDU.
+The resolver would not find any cached data for this name, but would
+find the NS RRs in the cache for ISI.EDU when it looks for foreign
+servers to ask.  Using this data, it would construct a SLIST of the
+form:
+
+    Match count = 3
+
+    A.ISI.EDU.      26.3.0.103
+    VAXA.ISI.EDU.   10.2.0.27       128.9.0.33
+    VENERA.ISI.EDU. 10.1.0.52
+
+A.ISI.EDU is listed first on the assumption that the resolver orders its
+choices by preference, and A.ISI.EDU is on the same network.
+
+One of these servers would answer the query.
+
+7. REFERENCES and BIBLIOGRAPHY
+
+[Dyer 87]       Dyer, S., and F. Hsu, "Hesiod", Project Athena
+                Technical Plan - Name Service, April 1987, version 1.9.
+
+                Describes the fundamentals of the Hesiod name service.
+
+[IEN-116]       J. Postel, "Internet Name Server", IEN-116,
+                USC/Information Sciences Institute, August 1979.
+
+                A name service obsoleted by the Domain Name System, but
+                still in use.
+
+
+
+
+
+
+
+
+Mockapetris                                                    [Page 50]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+[Quarterman 86] Quarterman, J., and J. Hoskins, "Notable Computer
+                Networks",Communications of the ACM, October 1986,
+                volume 29, number 10.
+
+[RFC-742]       K. Harrenstien, "NAME/FINGER", RFC-742, Network
+                Information Center, SRI International, December 1977.
+
+[RFC-768]       J. Postel, "User Datagram Protocol", RFC-768,
+                USC/Information Sciences Institute, August 1980.
+
+[RFC-793]       J. Postel, "Transmission Control Protocol", RFC-793,
+                USC/Information Sciences Institute, September 1981.
+
+[RFC-799]       D. Mills, "Internet Name Domains", RFC-799, COMSAT,
+                September 1981.
+
+                Suggests introduction of a hierarchy in place of a flat
+                name space for the Internet.
+
+[RFC-805]       J. Postel, "Computer Mail Meeting Notes", RFC-805,
+                USC/Information Sciences Institute, February 1982.
+
+[RFC-810]       E. Feinler, K. Harrenstien, Z. Su, and V. White, "DOD
+                Internet Host Table Specification", RFC-810, Network
+                Information Center, SRI International, March 1982.
+
+                Obsolete.  See RFC-952.
+
+[RFC-811]       K. Harrenstien, V. White, and E. Feinler, "Hostnames
+                Server", RFC-811, Network Information Center, SRI
+                International, March 1982.
+
+                Obsolete.  See RFC-953.
+
+[RFC-812]       K. Harrenstien, and V. White, "NICNAME/WHOIS", RFC-812,
+                Network Information Center, SRI International, March
+                1982.
+
+[RFC-819]       Z. Su, and J. Postel, "The Domain Naming Convention for
+                Internet User Applications", RFC-819, Network
+                Information Center, SRI International, August 1982.
+
+                Early thoughts on the design of the domain system.
+                Current implementation is completely different.
+
+[RFC-821]       J. Postel, "Simple Mail Transfer Protocol", RFC-821,
+                USC/Information Sciences Institute, August 1980.
+
+
+
+
+Mockapetris                                                    [Page 51]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+[RFC-830]       Z. Su, "A Distributed System for Internet Name Service",
+                RFC-830, Network Information Center, SRI International,
+                October 1982.
+
+                Early thoughts on the design of the domain system.
+                Current implementation is completely different.
+
+[RFC-882]       P. Mockapetris, "Domain names - Concepts and
+                Facilities," RFC-882, USC/Information Sciences
+                Institute, November 1983.
+
+                Superceeded by this memo.
+
+[RFC-883]       P. Mockapetris, "Domain names - Implementation and
+                Specification," RFC-883, USC/Information Sciences
+                Institute, November 1983.
+
+                Superceeded by this memo.
+
+[RFC-920]       J. Postel and J. Reynolds, "Domain Requirements",
+                RFC-920, USC/Information Sciences Institute
+                October 1984.
+
+                Explains the naming scheme for top level domains.
+
+[RFC-952]       K. Harrenstien, M. Stahl, E. Feinler, "DoD Internet Host
+                Table Specification", RFC-952, SRI, October 1985.
+
+                Specifies the format of HOSTS.TXT, the host/address
+                table replaced by the DNS.
+
+[RFC-953]       K. Harrenstien, M. Stahl, E. Feinler, "HOSTNAME Server",
+                RFC-953, SRI, October 1985.
+
+                This RFC contains the official specification of the
+                hostname server protocol, which is obsoleted by the DNS.
+                This TCP based protocol accesses information stored in
+                the RFC-952 format, and is used to obtain copies of the
+                host table.
+
+[RFC-973]       P. Mockapetris, "Domain System Changes and
+                Observations", RFC-973, USC/Information Sciences
+                Institute, January 1986.
+
+                Describes changes to RFC-882 and RFC-883 and reasons for
+                them.  Now obsolete.
+
+
+
+
+
+Mockapetris                                                    [Page 52]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+[RFC-974]       C. Partridge, "Mail routing and the domain system",
+                RFC-974, CSNET CIC BBN Labs, January 1986.
+
+                Describes the transition from HOSTS.TXT based mail
+                addressing to the more powerful MX system used with the
+                domain system.
+
+[RFC-1001]      NetBIOS Working Group, "Protocol standard for a NetBIOS
+                service on a TCP/UDP transport: Concepts and Methods",
+                RFC-1001, March 1987.
+
+                This RFC and RFC-1002 are a preliminary design for
+                NETBIOS on top of TCP/IP which proposes to base NetBIOS
+                name service on top of the DNS.
+
+[RFC-1002]      NetBIOS Working Group, "Protocol standard for a NetBIOS
+                service on a TCP/UDP transport: Detailed
+                Specifications", RFC-1002, March 1987.
+
+[RFC-1010]      J. Reynolds and J. Postel, "Assigned Numbers", RFC-1010,
+                USC/Information Sciences Institute, May 1987
+
+                Contains socket numbers and mnemonics for host names,
+                operating systems, etc.
+
+[RFC-1031]      W. Lazear, "MILNET Name Domain Transition", RFC-1031,
+                November 1987.
+
+                Describes a plan for converting the MILNET to the DNS.
+
+[RFC-1032]      M. K. Stahl, "Establishing a Domain - Guidelines for
+                Administrators", RFC-1032, November 1987.
+
+                Describes the registration policies used by the NIC to
+                administer the top level domains and delegate subzones.
+
+[RFC-1033]      M. K. Lottor, "Domain Administrators Operations Guide",
+                RFC-1033, November 1987.
+
+                A cookbook for domain administrators.
+
+[Solomon 82]    M. Solomon, L. Landweber, and D. Neuhengen, "The CSNET
+                Name Server", Computer Networks, vol 6, nr 3, July 1982.
+
+                Describes a name service for CSNET which is independent
+                from the DNS and DNS use in the CSNET.
+
+
+
+
+
+Mockapetris                                                    [Page 53]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+Index
+
+          A   12
+          Absolute names   8
+          Aliases   14, 31
+          Authority   6
+          AXFR   17
+
+          Case of characters   7
+          CH   12
+          CNAME   12, 13, 31
+          Completion queries   18
+
+          Domain name   6, 7
+
+          Glue RRs   20
+
+          HINFO   12
+
+          IN   12
+          Inverse queries   16
+          Iterative   4
+
+          Label   7
+
+          Mailbox names   9
+          MX   12
+
+          Name error   27, 36
+          Name servers   5, 17
+          NE   30
+          Negative caching   44
+          NS   12
+
+          Opcode   16
+
+          PTR   12
+
+          QCLASS   16
+          QTYPE   16
+
+          RDATA   13
+          Recursive   4
+          Recursive service   22
+          Relative names   7
+          Resolvers   6
+          RR   12
+
+
+
+
+Mockapetris                                                    [Page 54]
+
+RFC 1034             Domain Concepts and Facilities        November 1987
+
+
+          Safety belt   33
+          Sections   16
+          SOA   12
+          Standard queries   22
+
+          Status queries   18
+          Stub resolvers   32
+
+          TTL   12, 13
+
+          Wildcards   25
+
+          Zone transfers   28
+          Zones   19
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mockapetris                                                    [Page 55]
+
diff --git a/doc/rfc/rfc1035.txt b/doc/rfc/rfc1035.txt
new file mode 100644
index 0000000..b1a9bf5
--- /dev/null
+++ b/doc/rfc/rfc1035.txt
@@ -0,0 +1,3077 @@
+Network Working Group                                     P. Mockapetris
+Request for Comments: 1035                                           ISI
+                                                           November 1987
+Obsoletes: RFCs 882, 883, 973
+
+            DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION
+
+
+1. STATUS OF THIS MEMO
+
+This RFC describes the details of the domain system and protocol, and
+assumes that the reader is familiar with the concepts discussed in a
+companion RFC, "Domain Names - Concepts and Facilities" [RFC-1034].
+
+The domain system is a mixture of functions and data types which are an
+official protocol and functions and data types which are still
+experimental.  Since the domain system is intentionally extensible, new
+data types and experimental behavior should always be expected in parts
+of the system beyond the official protocol.  The official protocol parts
+include standard queries, responses and the Internet class RR data
+formats (e.g., host addresses).  Since the previous RFC set, several
+definitions have changed, so some previous definitions are obsolete.
+
+Experimental or obsolete features are clearly marked in these RFCs, and
+such information should be used with caution.
+
+The reader is especially cautioned not to depend on the values which
+appear in examples to be current or complete, since their purpose is
+primarily pedagogical.  Distribution of this memo is unlimited.
+
+                           Table of Contents
+
+  1. STATUS OF THIS MEMO                                              1
+  2. INTRODUCTION                                                     3
+      2.1. Overview                                                   3
+      2.2. Common configurations                                      4
+      2.3. Conventions                                                7
+          2.3.1. Preferred name syntax                                7
+          2.3.2. Data Transmission Order                              8
+          2.3.3. Character Case                                       9
+          2.3.4. Size limits                                         10
+  3. DOMAIN NAME SPACE AND RR DEFINITIONS                            10
+      3.1. Name space definitions                                    10
+      3.2. RR definitions                                            11
+          3.2.1. Format                                              11
+          3.2.2. TYPE values                                         12
+          3.2.3. QTYPE values                                        12
+          3.2.4. CLASS values                                        13
+
+
+
+Mockapetris                                                     [Page 1]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+          3.2.5. QCLASS values                                       13
+      3.3. Standard RRs                                              13
+          3.3.1. CNAME RDATA format                                  14
+          3.3.2. HINFO RDATA format                                  14
+          3.3.3. MB RDATA format (EXPERIMENTAL)                      14
+          3.3.4. MD RDATA format (Obsolete)                          15
+          3.3.5. MF RDATA format (Obsolete)                          15
+          3.3.6. MG RDATA format (EXPERIMENTAL)                      16
+          3.3.7. MINFO RDATA format (EXPERIMENTAL)                   16
+          3.3.8. MR RDATA format (EXPERIMENTAL)                      17
+          3.3.9. MX RDATA format                                     17
+          3.3.10. NULL RDATA format (EXPERIMENTAL)                   17
+          3.3.11. NS RDATA format                                    18
+          3.3.12. PTR RDATA format                                   18
+          3.3.13. SOA RDATA format                                   19
+          3.3.14. TXT RDATA format                                   20
+      3.4. ARPA Internet specific RRs                                20
+          3.4.1. A RDATA format                                      20
+          3.4.2. WKS RDATA format                                    21
+      3.5. IN-ADDR.ARPA domain                                       22
+      3.6. Defining new types, classes, and special namespaces       24
+  4. MESSAGES                                                        25
+      4.1. Format                                                    25
+          4.1.1. Header section format                               26
+          4.1.2. Question section format                             28
+          4.1.3. Resource record format                              29
+          4.1.4. Message compression                                 30
+      4.2. Transport                                                 32
+          4.2.1. UDP usage                                           32
+          4.2.2. TCP usage                                           32
+  5. MASTER FILES                                                    33
+      5.1. Format                                                    33
+      5.2. Use of master files to define zones                       35
+      5.3. Master file example                                       36
+  6. NAME SERVER IMPLEMENTATION                                      37
+      6.1. Architecture                                              37
+          6.1.1. Control                                             37
+          6.1.2. Database                                            37
+          6.1.3. Time                                                39
+      6.2. Standard query processing                                 39
+      6.3. Zone refresh and reload processing                        39
+      6.4. Inverse queries (Optional)                                40
+          6.4.1. The contents of inverse queries and responses       40
+          6.4.2. Inverse query and response example                  41
+          6.4.3. Inverse query processing                            42
+
+
+
+
+
+
+Mockapetris                                                     [Page 2]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+      6.5. Completion queries and responses                          42
+  7. RESOLVER IMPLEMENTATION                                         43
+      7.1. Transforming a user request into a query                  43
+      7.2. Sending the queries                                       44
+      7.3. Processing responses                                      46
+      7.4. Using the cache                                           47
+  8. MAIL SUPPORT                                                    47
+      8.1. Mail exchange binding                                     48
+      8.2. Mailbox binding (Experimental)                            48
+  9. REFERENCES and BIBLIOGRAPHY                                     50
+  Index                                                              54
+
+2. INTRODUCTION
+
+2.1. Overview
+
+The goal of domain names is to provide a mechanism for naming resources
+in such a way that the names are usable in different hosts, networks,
+protocol families, internets, and administrative organizations.
+
+From the user's point of view, domain names are useful as arguments to a
+local agent, called a resolver, which retrieves information associated
+with the domain name.  Thus a user might ask for the host address or
+mail information associated with a particular domain name.  To enable
+the user to request a particular type of information, an appropriate
+query type is passed to the resolver with the domain name.  To the user,
+the domain tree is a single information space; the resolver is
+responsible for hiding the distribution of data among name servers from
+the user.
+
+From the resolver's point of view, the database that makes up the domain
+space is distributed among various name servers.  Different parts of the
+domain space are stored in different name servers, although a particular
+data item will be stored redundantly in two or more name servers.  The
+resolver starts with knowledge of at least one name server.  When the
+resolver processes a user query it asks a known name server for the
+information; in return, the resolver either receives the desired
+information or a referral to another name server.  Using these
+referrals, resolvers learn the identities and contents of other name
+servers.  Resolvers are responsible for dealing with the distribution of
+the domain space and dealing with the effects of name server failure by
+consulting redundant databases in other servers.
+
+Name servers manage two kinds of data.  The first kind of data held in
+sets called zones; each zone is the complete database for a particular
+"pruned" subtree of the domain space.  This data is called
+authoritative.  A name server periodically checks to make sure that its
+zones are up to date, and if not, obtains a new copy of updated zones
+
+
+
+Mockapetris                                                     [Page 3]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+from master files stored locally or in another name server.  The second
+kind of data is cached data which was acquired by a local resolver.
+This data may be incomplete, but improves the performance of the
+retrieval process when non-local data is repeatedly accessed.  Cached
+data is eventually discarded by a timeout mechanism.
+
+This functional structure isolates the problems of user interface,
+failure recovery, and distribution in the resolvers and isolates the
+database update and refresh problems in the name servers.
+
+2.2. Common configurations
+
+A host can participate in the domain name system in a number of ways,
+depending on whether the host runs programs that retrieve information
+from the domain system, name servers that answer queries from other
+hosts, or various combinations of both functions.  The simplest, and
+perhaps most typical, configuration is shown below:
+
+                 Local Host                        |  Foreign
+                                                   |
+    +---------+               +----------+         |  +--------+
+    |         | user queries  |          |queries  |  |        |
+    |  User   |-------------->|          |---------|->|Foreign |
+    | Program |               | Resolver |         |  |  Name  |
+    |         |<--------------|          |<--------|--| Server |
+    |         | user responses|          |responses|  |        |
+    +---------+               +----------+         |  +--------+
+                                |     A            |
+                cache additions |     | references |
+                                V     |            |
+                              +----------+         |
+                              |  cache   |         |
+                              +----------+         |
+
+User programs interact with the domain name space through resolvers; the
+format of user queries and user responses is specific to the host and
+its operating system.  User queries will typically be operating system
+calls, and the resolver and its cache will be part of the host operating
+system.  Less capable hosts may choose to implement the resolver as a
+subroutine to be linked in with every program that needs its services.
+Resolvers answer user queries with information they acquire via queries
+to foreign name servers and the local cache.
+
+Note that the resolver may have to make several queries to several
+different foreign name servers to answer a particular user query, and
+hence the resolution of a user query may involve several network
+accesses and an arbitrary amount of time.  The queries to foreign name
+servers and the corresponding responses have a standard format described
+
+
+
+Mockapetris                                                     [Page 4]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+in this memo, and may be datagrams.
+
+Depending on its capabilities, a name server could be a stand alone
+program on a dedicated machine or a process or processes on a large
+timeshared host.  A simple configuration might be:
+
+                 Local Host                        |  Foreign
+                                                   |
+      +---------+                                  |
+     /         /|                                  |
+    +---------+ |             +----------+         |  +--------+
+    |         | |             |          |responses|  |        |
+    |         | |             |   Name   |---------|->|Foreign |
+    |  Master |-------------->|  Server  |         |  |Resolver|
+    |  files  | |             |          |<--------|--|        |
+    |         |/              |          | queries |  +--------+
+    +---------+               +----------+         |
+
+Here a primary name server acquires information about one or more zones
+by reading master files from its local file system, and answers queries
+about those zones that arrive from foreign resolvers.
+
+The DNS requires that all zones be redundantly supported by more than
+one name server.  Designated secondary servers can acquire zones and
+check for updates from the primary server using the zone transfer
+protocol of the DNS.  This configuration is shown below:
+
+                 Local Host                        |  Foreign
+                                                   |
+      +---------+                                  |
+     /         /|                                  |
+    +---------+ |             +----------+         |  +--------+
+    |         | |             |          |responses|  |        |
+    |         | |             |   Name   |---------|->|Foreign |
+    |  Master |-------------->|  Server  |         |  |Resolver|
+    |  files  | |             |          |<--------|--|        |
+    |         |/              |          | queries |  +--------+
+    +---------+               +----------+         |
+                                A     |maintenance |  +--------+
+                                |     +------------|->|        |
+                                |      queries     |  |Foreign |
+                                |                  |  |  Name  |
+                                +------------------|--| Server |
+                             maintenance responses |  +--------+
+
+In this configuration, the name server periodically establishes a
+virtual circuit to a foreign name server to acquire a copy of a zone or
+to check that an existing copy has not changed.  The messages sent for
+
+
+
+Mockapetris                                                     [Page 5]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+these maintenance activities follow the same form as queries and
+responses, but the message sequences are somewhat different.
+
+The information flow in a host that supports all aspects of the domain
+name system is shown below:
+
+                 Local Host                        |  Foreign
+                                                   |
+    +---------+               +----------+         |  +--------+
+    |         | user queries  |          |queries  |  |        |
+    |  User   |-------------->|          |---------|->|Foreign |
+    | Program |               | Resolver |         |  |  Name  |
+    |         |<--------------|          |<--------|--| Server |
+    |         | user responses|          |responses|  |        |
+    +---------+               +----------+         |  +--------+
+                                |     A            |
+                cache additions |     | references |
+                                V     |            |
+                              +----------+         |
+                              |  Shared  |         |
+                              | database |         |
+                              +----------+         |
+                                A     |            |
+      +---------+     refreshes |     | references |
+     /         /|               |     V            |
+    +---------+ |             +----------+         |  +--------+
+    |         | |             |          |responses|  |        |
+    |         | |             |   Name   |---------|->|Foreign |
+    |  Master |-------------->|  Server  |         |  |Resolver|
+    |  files  | |             |          |<--------|--|        |
+    |         |/              |          | queries |  +--------+
+    +---------+               +----------+         |
+                                A     |maintenance |  +--------+
+                                |     +------------|->|        |
+                                |      queries     |  |Foreign |
+                                |                  |  |  Name  |
+                                +------------------|--| Server |
+                             maintenance responses |  +--------+
+
+The shared database holds domain space data for the local name server
+and resolver.  The contents of the shared database will typically be a
+mixture of authoritative data maintained by the periodic refresh
+operations of the name server and cached data from previous resolver
+requests.  The structure of the domain data and the necessity for
+synchronization between name servers and resolvers imply the general
+characteristics of this database, but the actual format is up to the
+local implementor.
+
+
+
+
+Mockapetris                                                     [Page 6]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+Information flow can also be tailored so that a group of hosts act
+together to optimize activities.  Sometimes this is done to offload less
+capable hosts so that they do not have to implement a full resolver.
+This can be appropriate for PCs or hosts which want to minimize the
+amount of new network code which is required.  This scheme can also
+allow a group of hosts can share a small number of caches rather than
+maintaining a large number of separate caches, on the premise that the
+centralized caches will have a higher hit ratio.  In either case,
+resolvers are replaced with stub resolvers which act as front ends to
+resolvers located in a recursive server in one or more name servers
+known to perform that service:
+
+                   Local Hosts                     |  Foreign
+                                                   |
+    +---------+                                    |
+    |         | responses                          |
+    | Stub    |<--------------------+              |
+    | Resolver|                     |              |
+    |         |----------------+    |              |
+    +---------+ recursive      |    |              |
+                queries        |    |              |
+                               V    |              |
+    +---------+ recursive     +----------+         |  +--------+
+    |         | queries       |          |queries  |  |        |
+    | Stub    |-------------->| Recursive|---------|->|Foreign |
+    | Resolver|               | Server   |         |  |  Name  |
+    |         |<--------------|          |<--------|--| Server |
+    +---------+ responses     |          |responses|  |        |
+                              +----------+         |  +--------+
+                              |  Central |         |
+                              |   cache  |         |
+                              +----------+         |
+
+In any case, note that domain components are always replicated for
+reliability whenever possible.
+
+2.3. Conventions
+
+The domain system has several conventions dealing with low-level, but
+fundamental, issues.  While the implementor is free to violate these
+conventions WITHIN HIS OWN SYSTEM, he must observe these conventions in
+ALL behavior observed from other hosts.
+
+2.3.1. Preferred name syntax
+
+The DNS specifications attempt to be as general as possible in the rules
+for constructing domain names.  The idea is that the name of any
+existing object can be expressed as a domain name with minimal changes.
+
+
+
+Mockapetris                                                     [Page 7]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+However, when assigning a domain name for an object, the prudent user
+will select a name which satisfies both the rules of the domain system
+and any existing rules for the object, whether these rules are published
+or implied by existing programs.
+
+For example, when naming a mail domain, the user should satisfy both the
+rules of this memo and those in RFC-822.  When creating a new host name,
+the old rules for HOSTS.TXT should be followed.  This avoids problems
+when old software is converted to use domain names.
+
+The following syntax will result in fewer problems with many
+
+applications that use domain names (e.g., mail, TELNET).
+
+<domain> ::= <subdomain> | " "
+
+<subdomain> ::= <label> | <subdomain> "." <label>
+
+<label> ::= <letter> [ [ <ldh-str> ] <let-dig> ]
+
+<ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str>
+
+<let-dig-hyp> ::= <let-dig> | "-"
+
+<let-dig> ::= <letter> | <digit>
+
+<letter> ::= any one of the 52 alphabetic characters A through Z in
+upper case and a through z in lower case
+
+<digit> ::= any one of the ten digits 0 through 9
+
+Note that while upper and lower case letters are allowed in domain
+names, no significance is attached to the case.  That is, two names with
+the same spelling but different case are to be treated as if identical.
+
+The labels must follow the rules for ARPANET host names.  They must
+start with a letter, end with a letter or digit, and have as interior
+characters only letters, digits, and hyphen.  There are also some
+restrictions on the length.  Labels must be 63 characters or less.
+
+For example, the following strings identify hosts in the Internet:
+
+A.ISI.EDU XX.LCS.MIT.EDU SRI-NIC.ARPA
+
+2.3.2. Data Transmission Order
+
+The order of transmission of the header and data described in this
+document is resolved to the octet level.  Whenever a diagram shows a
+
+
+
+Mockapetris                                                     [Page 8]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+group of octets, the order of transmission of those octets is the normal
+order in which they are read in English.  For example, in the following
+diagram, the octets are transmitted in the order they are numbered.
+
+     0                   1
+     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |       1       |       2       |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |       3       |       4       |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |       5       |       6       |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+Whenever an octet represents a numeric quantity, the left most bit in
+the diagram is the high order or most significant bit.  That is, the bit
+labeled 0 is the most significant bit.  For example, the following
+diagram represents the value 170 (decimal).
+
+     0 1 2 3 4 5 6 7
+    +-+-+-+-+-+-+-+-+
+    |1 0 1 0 1 0 1 0|
+    +-+-+-+-+-+-+-+-+
+
+Similarly, whenever a multi-octet field represents a numeric quantity
+the left most bit of the whole field is the most significant bit.  When
+a multi-octet quantity is transmitted the most significant octet is
+transmitted first.
+
+2.3.3. Character Case
+
+For all parts of the DNS that are part of the official protocol, all
+comparisons between character strings (e.g., labels, domain names, etc.)
+are done in a case-insensitive manner.  At present, this rule is in
+force throughout the domain system without exception.  However, future
+additions beyond current usage may need to use the full binary octet
+capabilities in names, so attempts to store domain names in 7-bit ASCII
+or use of special bytes to terminate labels, etc., should be avoided.
+
+When data enters the domain system, its original case should be
+preserved whenever possible.  In certain circumstances this cannot be
+done.  For example, if two RRs are stored in a database, one at x.y and
+one at X.Y, they are actually stored at the same place in the database,
+and hence only one casing would be preserved.  The basic rule is that
+case can be discarded only when data is used to define structure in a
+database, and two names are identical when compared in a case
+insensitive manner.
+
+
+
+
+Mockapetris                                                     [Page 9]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+Loss of case sensitive data must be minimized.  Thus while data for x.y
+and X.Y may both be stored under a single location x.y or X.Y, data for
+a.x and B.X would never be stored under A.x, A.X, b.x, or b.X.  In
+general, this preserves the case of the first label of a domain name,
+but forces standardization of interior node labels.
+
+Systems administrators who enter data into the domain database should
+take care to represent the data they supply to the domain system in a
+case-consistent manner if their system is case-sensitive.  The data
+distribution system in the domain system will ensure that consistent
+representations are preserved.
+
+2.3.4. Size limits
+
+Various objects and parameters in the DNS have size limits.  They are
+listed below.  Some could be easily changed, others are more
+fundamental.
+
+labels          63 octets or less
+
+names           255 octets or less
+
+TTL             positive values of a signed 32 bit number.
+
+UDP messages    512 octets or less
+
+3. DOMAIN NAME SPACE AND RR DEFINITIONS
+
+3.1. Name space definitions
+
+Domain names in messages are expressed in terms of a sequence of labels.
+Each label is represented as a one octet length field followed by that
+number of octets.  Since every domain name ends with the null label of
+the root, a domain name is terminated by a length byte of zero.  The
+high order two bits of every length octet must be zero, and the
+remaining six bits of the length field limit the label to 63 octets or
+less.
+
+To simplify implementations, the total length of a domain name (i.e.,
+label octets and label length octets) is restricted to 255 octets or
+less.
+
+Although labels can contain any 8 bit values in octets that make up a
+label, it is strongly recommended that labels follow the preferred
+syntax described elsewhere in this memo, which is compatible with
+existing host naming conventions.  Name servers and resolvers must
+compare labels in a case-insensitive manner (i.e., A=a), assuming ASCII
+with zero parity.  Non-alphabetic codes must match exactly.
+
+
+
+Mockapetris                                                    [Page 10]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+3.2. RR definitions
+
+3.2.1. Format
+
+All RRs have the same top level format shown below:
+
+                                    1  1  1  1  1  1
+      0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    |                                               |
+    /                                               /
+    /                      NAME                     /
+    |                                               |
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    |                      TYPE                     |
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    |                     CLASS                     |
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    |                      TTL                      |
+    |                                               |
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    |                   RDLENGTH                    |
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
+    /                     RDATA                     /
+    /                                               /
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+
+where:
+
+NAME            an owner name, i.e., the name of the node to which this
+                resource record pertains.
+
+TYPE            two octets containing one of the RR TYPE codes.
+
+CLASS           two octets containing one of the RR CLASS codes.
+
+TTL             a 32 bit signed integer that specifies the time interval
+                that the resource record may be cached before the source
+                of the information should again be consulted.  Zero
+                values are interpreted to mean that the RR can only be
+                used for the transaction in progress, and should not be
+                cached.  For example, SOA records are always distributed
+                with a zero TTL to prohibit caching.  Zero values can
+                also be used for extremely volatile data.
+
+RDLENGTH        an unsigned 16 bit integer that specifies the length in
+                octets of the RDATA field.
+
+
+
+Mockapetris                                                    [Page 11]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+RDATA           a variable length string of octets that describes the
+                resource.  The format of this information varies
+                according to the TYPE and CLASS of the resource record.
+
+3.2.2. TYPE values
+
+TYPE fields are used in resource records.  Note that these types are a
+subset of QTYPEs.
+
+TYPE            value and meaning
+
+A               1 a host address
+
+NS              2 an authoritative name server
+
+MD              3 a mail destination (Obsolete - use MX)
+
+MF              4 a mail forwarder (Obsolete - use MX)
+
+CNAME           5 the canonical name for an alias
+
+SOA             6 marks the start of a zone of authority
+
+MB              7 a mailbox domain name (EXPERIMENTAL)
+
+MG              8 a mail group member (EXPERIMENTAL)
+
+MR              9 a mail rename domain name (EXPERIMENTAL)
+
+NULL            10 a null RR (EXPERIMENTAL)
+
+WKS             11 a well known service description
+
+PTR             12 a domain name pointer
+
+HINFO           13 host information
+
+MINFO           14 mailbox or mail list information
+
+MX              15 mail exchange
+
+TXT             16 text strings
+
+3.2.3. QTYPE values
+
+QTYPE fields appear in the question part of a query.  QTYPES are a
+superset of TYPEs, hence all TYPEs are valid QTYPEs.  In addition, the
+following QTYPEs are defined:
+
+
+
+Mockapetris                                                    [Page 12]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+AXFR            252 A request for a transfer of an entire zone
+
+MAILB           253 A request for mailbox-related records (MB, MG or MR)
+
+MAILA           254 A request for mail agent RRs (Obsolete - see MX)
+
+*               255 A request for all records
+
+3.2.4. CLASS values
+
+CLASS fields appear in resource records.  The following CLASS mnemonics
+and values are defined:
+
+IN              1 the Internet
+
+CS              2 the CSNET class (Obsolete - used only for examples in
+                some obsolete RFCs)
+
+CH              3 the CHAOS class
+
+HS              4 Hesiod [Dyer 87]
+
+3.2.5. QCLASS values
+
+QCLASS fields appear in the question section of a query.  QCLASS values
+are a superset of CLASS values; every CLASS is a valid QCLASS.  In
+addition to CLASS values, the following QCLASSes are defined:
+
+*               255 any class
+
+3.3. Standard RRs
+
+The following RR definitions are expected to occur, at least
+potentially, in all classes.  In particular, NS, SOA, CNAME, and PTR
+will be used in all classes, and have the same format in all classes.
+Because their RDATA format is known, all domain names in the RDATA
+section of these RRs may be compressed.
+
+<domain-name> is a domain name represented as a series of labels, and
+terminated by a label with zero length.  <character-string> is a single
+length octet followed by that number of characters.  <character-string>
+is treated as binary information, and can be up to 256 characters in
+length (including the length octet).
+
+
+
+
+
+
+
+
+Mockapetris                                                    [Page 13]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+3.3.1. CNAME RDATA format
+
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    /                     CNAME                     /
+    /                                               /
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+where:
+
+CNAME           A <domain-name> which specifies the canonical or primary
+                name for the owner.  The owner name is an alias.
+
+CNAME RRs cause no additional section processing, but name servers may
+choose to restart the query at the canonical name in certain cases.  See
+the description of name server logic in [RFC-1034] for details.
+
+3.3.2. HINFO RDATA format
+
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    /                      CPU                      /
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    /                       OS                      /
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+where:
+
+CPU             A <character-string> which specifies the CPU type.
+
+OS              A <character-string> which specifies the operating
+                system type.
+
+Standard values for CPU and OS can be found in [RFC-1010].
+
+HINFO records are used to acquire general information about a host.  The
+main use is for protocols such as FTP that can use special procedures
+when talking between machines or operating systems of the same type.
+
+3.3.3. MB RDATA format (EXPERIMENTAL)
+
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    /                   MADNAME                     /
+    /                                               /
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+where:
+
+MADNAME         A <domain-name> which specifies a host which has the
+                specified mailbox.
+
+
+
+Mockapetris                                                    [Page 14]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+MB records cause additional section processing which looks up an A type
+RRs corresponding to MADNAME.
+
+3.3.4. MD RDATA format (Obsolete)
+
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    /                   MADNAME                     /
+    /                                               /
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+where:
+
+MADNAME         A <domain-name> which specifies a host which has a mail
+                agent for the domain which should be able to deliver
+                mail for the domain.
+
+MD records cause additional section processing which looks up an A type
+record corresponding to MADNAME.
+
+MD is obsolete.  See the definition of MX and [RFC-974] for details of
+the new scheme.  The recommended policy for dealing with MD RRs found in
+a master file is to reject them, or to convert them to MX RRs with a
+preference of 0.
+
+3.3.5. MF RDATA format (Obsolete)
+
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    /                   MADNAME                     /
+    /                                               /
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+where:
+
+MADNAME         A <domain-name> which specifies a host which has a mail
+                agent for the domain which will accept mail for
+                forwarding to the domain.
+
+MF records cause additional section processing which looks up an A type
+record corresponding to MADNAME.
+
+MF is obsolete.  See the definition of MX and [RFC-974] for details ofw
+the new scheme.  The recommended policy for dealing with MD RRs found in
+a master file is to reject them, or to convert them to MX RRs with a
+preference of 10.
+
+
+
+
+
+
+
+Mockapetris                                                    [Page 15]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+3.3.6. MG RDATA format (EXPERIMENTAL)
+
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    /                   MGMNAME                     /
+    /                                               /
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+where:
+
+MGMNAME         A <domain-name> which specifies a mailbox which is a
+                member of the mail group specified by the domain name.
+
+MG records cause no additional section processing.
+
+3.3.7. MINFO RDATA format (EXPERIMENTAL)
+
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    /                    RMAILBX                    /
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    /                    EMAILBX                    /
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+where:
+
+RMAILBX         A <domain-name> which specifies a mailbox which is
+                responsible for the mailing list or mailbox.  If this
+                domain name names the root, the owner of the MINFO RR is
+                responsible for itself.  Note that many existing mailing
+                lists use a mailbox X-request for the RMAILBX field of
+                mailing list X, e.g., Msgroup-request for Msgroup.  This
+                field provides a more general mechanism.
+
+
+EMAILBX         A <domain-name> which specifies a mailbox which is to
+                receive error messages related to the mailing list or
+                mailbox specified by the owner of the MINFO RR (similar
+                to the ERRORS-TO: field which has been proposed).  If
+                this domain name names the root, errors should be
+                returned to the sender of the message.
+
+MINFO records cause no additional section processing.  Although these
+records can be associated with a simple mailbox, they are usually used
+with a mailing list.
+
+
+
+
+
+
+
+
+Mockapetris                                                    [Page 16]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+3.3.8. MR RDATA format (EXPERIMENTAL)
+
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    /                   NEWNAME                     /
+    /                                               /
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+where:
+
+NEWNAME         A <domain-name> which specifies a mailbox which is the
+                proper rename of the specified mailbox.
+
+MR records cause no additional section processing.  The main use for MR
+is as a forwarding entry for a user who has moved to a different
+mailbox.
+
+3.3.9. MX RDATA format
+
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    |                  PREFERENCE                   |
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    /                   EXCHANGE                    /
+    /                                               /
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+where:
+
+PREFERENCE      A 16 bit integer which specifies the preference given to
+                this RR among others at the same owner.  Lower values
+                are preferred.
+
+EXCHANGE        A <domain-name> which specifies a host willing to act as
+                a mail exchange for the owner name.
+
+MX records cause type A additional section processing for the host
+specified by EXCHANGE.  The use of MX RRs is explained in detail in
+[RFC-974].
+
+3.3.10. NULL RDATA format (EXPERIMENTAL)
+
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    /                  <anything>                   /
+    /                                               /
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+Anything at all may be in the RDATA field so long as it is 65535 octets
+or less.
+
+
+
+
+Mockapetris                                                    [Page 17]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+NULL records cause no additional section processing.  NULL RRs are not
+allowed in master files.  NULLs are used as placeholders in some
+experimental extensions of the DNS.
+
+3.3.11. NS RDATA format
+
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    /                   NSDNAME                     /
+    /                                               /
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+where:
+
+NSDNAME         A <domain-name> which specifies a host which should be
+                authoritative for the specified class and domain.
+
+NS records cause both the usual additional section processing to locate
+a type A record, and, when used in a referral, a special search of the
+zone in which they reside for glue information.
+
+The NS RR states that the named host should be expected to have a zone
+starting at owner name of the specified class.  Note that the class may
+not indicate the protocol family which should be used to communicate
+with the host, although it is typically a strong hint.  For example,
+hosts which are name servers for either Internet (IN) or Hesiod (HS)
+class information are normally queried using IN class protocols.
+
+3.3.12. PTR RDATA format
+
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    /                   PTRDNAME                    /
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+where:
+
+PTRDNAME        A <domain-name> which points to some location in the
+                domain name space.
+
+PTR records cause no additional section processing.  These RRs are used
+in special domains to point to some other location in the domain space.
+These records are simple data, and don't imply any special processing
+similar to that performed by CNAME, which identifies aliases.  See the
+description of the IN-ADDR.ARPA domain for an example.
+
+
+
+
+
+
+
+
+Mockapetris                                                    [Page 18]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+3.3.13. SOA RDATA format
+
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    /                     MNAME                     /
+    /                                               /
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    /                     RNAME                     /
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    |                    SERIAL                     |
+    |                                               |
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    |                    REFRESH                    |
+    |                                               |
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    |                     RETRY                     |
+    |                                               |
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    |                    EXPIRE                     |
+    |                                               |
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    |                    MINIMUM                    |
+    |                                               |
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+where:
+
+MNAME           The <domain-name> of the name server that was the
+                original or primary source of data for this zone.
+
+RNAME           A <domain-name> which specifies the mailbox of the
+                person responsible for this zone.
+
+SERIAL          The unsigned 32 bit version number of the original copy
+                of the zone.  Zone transfers preserve this value.  This
+                value wraps and should be compared using sequence space
+                arithmetic.
+
+REFRESH         A 32 bit time interval before the zone should be
+                refreshed.
+
+RETRY           A 32 bit time interval that should elapse before a
+                failed refresh should be retried.
+
+EXPIRE          A 32 bit time value that specifies the upper limit on
+                the time interval that can elapse before the zone is no
+                longer authoritative.
+
+
+
+
+
+Mockapetris                                                    [Page 19]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+MINIMUM         The unsigned 32 bit minimum TTL field that should be
+                exported with any RR from this zone.
+
+SOA records cause no additional section processing.
+
+All times are in units of seconds.
+
+Most of these fields are pertinent only for name server maintenance
+operations.  However, MINIMUM is used in all query operations that
+retrieve RRs from a zone.  Whenever a RR is sent in a response to a
+query, the TTL field is set to the maximum of the TTL field from the RR
+and the MINIMUM field in the appropriate SOA.  Thus MINIMUM is a lower
+bound on the TTL field for all RRs in a zone.  Note that this use of
+MINIMUM should occur when the RRs are copied into the response and not
+when the zone is loaded from a master file or via a zone transfer.  The
+reason for this provison is to allow future dynamic update facilities to
+change the SOA RR with known semantics.
+
+
+3.3.14. TXT RDATA format
+
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    /                   TXT-DATA                    /
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+where:
+
+TXT-DATA        One or more <character-string>s.
+
+TXT RRs are used to hold descriptive text.  The semantics of the text
+depends on the domain where it is found.
+
+3.4. Internet specific RRs
+
+3.4.1. A RDATA format
+
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    |                    ADDRESS                    |
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+where:
+
+ADDRESS         A 32 bit Internet address.
+
+Hosts that have multiple Internet addresses will have multiple A
+records.
+
+
+
+
+
+Mockapetris                                                    [Page 20]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+A records cause no additional section processing.  The RDATA section of
+an A line in a master file is an Internet address expressed as four
+decimal numbers separated by dots without any imbedded spaces (e.g.,
+"10.2.0.52" or "192.0.5.6").
+
+3.4.2. WKS RDATA format
+
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    |                    ADDRESS                    |
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    |       PROTOCOL        |                       |
+    +--+--+--+--+--+--+--+--+                       |
+    |                                               |
+    /                   <BIT MAP>                   /
+    /                                               /
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+where:
+
+ADDRESS         An 32 bit Internet address
+
+PROTOCOL        An 8 bit IP protocol number
+
+<BIT MAP>       A variable length bit map.  The bit map must be a
+                multiple of 8 bits long.
+
+The WKS record is used to describe the well known services supported by
+a particular protocol on a particular internet address.  The PROTOCOL
+field specifies an IP protocol number, and the bit map has one bit per
+port of the specified protocol.  The first bit corresponds to port 0,
+the second to port 1, etc.  If the bit map does not include a bit for a
+protocol of interest, that bit is assumed zero.  The appropriate values
+and mnemonics for ports and protocols are specified in [RFC-1010].
+
+For example, if PROTOCOL=TCP (6), the 26th bit corresponds to TCP port
+25 (SMTP).  If this bit is set, a SMTP server should be listening on TCP
+port 25; if zero, SMTP service is not supported on the specified
+address.
+
+The purpose of WKS RRs is to provide availability information for
+servers for TCP and UDP.  If a server supports both TCP and UDP, or has
+multiple Internet addresses, then multiple WKS RRs are used.
+
+WKS RRs cause no additional section processing.
+
+In master files, both ports and protocols are expressed using mnemonics
+or decimal numbers.
+
+
+
+
+Mockapetris                                                    [Page 21]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+3.5. IN-ADDR.ARPA domain
+
+The Internet uses a special domain to support gateway location and
+Internet address to host mapping.  Other classes may employ a similar
+strategy in other domains.  The intent of this domain is to provide a
+guaranteed method to perform host address to host name mapping, and to
+facilitate queries to locate all gateways on a particular network in the
+Internet.
+
+Note that both of these services are similar to functions that could be
+performed by inverse queries; the difference is that this part of the
+domain name space is structured according to address, and hence can
+guarantee that the appropriate data can be located without an exhaustive
+search of the domain space.
+
+The domain begins at IN-ADDR.ARPA and has a substructure which follows
+the Internet addressing structure.
+
+Domain names in the IN-ADDR.ARPA domain are defined to have up to four
+labels in addition to the IN-ADDR.ARPA suffix.  Each label represents
+one octet of an Internet address, and is expressed as a character string
+for a decimal value in the range 0-255 (with leading zeros omitted
+except in the case of a zero octet which is represented by a single
+zero).
+
+Host addresses are represented by domain names that have all four labels
+specified.  Thus data for Internet address 10.2.0.52 is located at
+domain name 52.0.2.10.IN-ADDR.ARPA.  The reversal, though awkward to
+read, allows zones to be delegated which are exactly one network of
+address space.  For example, 10.IN-ADDR.ARPA can be a zone containing
+data for the ARPANET, while 26.IN-ADDR.ARPA can be a separate zone for
+MILNET.  Address nodes are used to hold pointers to primary host names
+in the normal domain space.
+
+Network numbers correspond to some non-terminal nodes at various depths
+in the IN-ADDR.ARPA domain, since Internet network numbers are either 1,
+2, or 3 octets.  Network nodes are used to hold pointers to the primary
+host names of gateways attached to that network.  Since a gateway is, by
+definition, on more than one network, it will typically have two or more
+network nodes which point at it.  Gateways will also have host level
+pointers at their fully qualified addresses.
+
+Both the gateway pointers at network nodes and the normal host pointers
+at full address nodes use the PTR RR to point back to the primary domain
+names of the corresponding hosts.
+
+For example, the IN-ADDR.ARPA domain will contain information about the
+ISI gateway between net 10 and 26, an MIT gateway from net 10 to MIT's
+
+
+
+Mockapetris                                                    [Page 22]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+net 18, and hosts A.ISI.EDU and MULTICS.MIT.EDU.  Assuming that ISI
+gateway has addresses 10.2.0.22 and 26.0.0.103, and a name MILNET-
+GW.ISI.EDU, and the MIT gateway has addresses 10.0.0.77 and 18.10.0.4
+and a name GW.LCS.MIT.EDU, the domain database would contain:
+
+    10.IN-ADDR.ARPA.           PTR MILNET-GW.ISI.EDU.
+    10.IN-ADDR.ARPA.           PTR GW.LCS.MIT.EDU.
+    18.IN-ADDR.ARPA.           PTR GW.LCS.MIT.EDU.
+    26.IN-ADDR.ARPA.           PTR MILNET-GW.ISI.EDU.
+    22.0.2.10.IN-ADDR.ARPA.    PTR MILNET-GW.ISI.EDU.
+    103.0.0.26.IN-ADDR.ARPA.   PTR MILNET-GW.ISI.EDU.
+    77.0.0.10.IN-ADDR.ARPA.    PTR GW.LCS.MIT.EDU.
+    4.0.10.18.IN-ADDR.ARPA.    PTR GW.LCS.MIT.EDU.
+    103.0.3.26.IN-ADDR.ARPA.   PTR A.ISI.EDU.
+    6.0.0.10.IN-ADDR.ARPA.     PTR MULTICS.MIT.EDU.
+
+Thus a program which wanted to locate gateways on net 10 would originate
+a query of the form QTYPE=PTR, QCLASS=IN, QNAME=10.IN-ADDR.ARPA.  It
+would receive two RRs in response:
+
+    10.IN-ADDR.ARPA.           PTR MILNET-GW.ISI.EDU.
+    10.IN-ADDR.ARPA.           PTR GW.LCS.MIT.EDU.
+
+The program could then originate QTYPE=A, QCLASS=IN queries for MILNET-
+GW.ISI.EDU. and GW.LCS.MIT.EDU. to discover the Internet addresses of
+these gateways.
+
+A resolver which wanted to find the host name corresponding to Internet
+host address 10.0.0.6 would pursue a query of the form QTYPE=PTR,
+QCLASS=IN, QNAME=6.0.0.10.IN-ADDR.ARPA, and would receive:
+
+    6.0.0.10.IN-ADDR.ARPA.     PTR MULTICS.MIT.EDU.
+
+Several cautions apply to the use of these services:
+   - Since the IN-ADDR.ARPA special domain and the normal domain
+     for a particular host or gateway will be in different zones,
+     the possibility exists that that the data may be inconsistent.
+
+   - Gateways will often have two names in separate domains, only
+     one of which can be primary.
+
+   - Systems that use the domain database to initialize their
+     routing tables must start with enough gateway information to
+     guarantee that they can access the appropriate name server.
+
+   - The gateway data only reflects the existence of a gateway in a
+     manner equivalent to the current HOSTS.TXT file.  It doesn't
+     replace the dynamic availability information from GGP or EGP.
+
+
+
+Mockapetris                                                    [Page 23]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+3.6. Defining new types, classes, and special namespaces
+
+The previously defined types and classes are the ones in use as of the
+date of this memo.  New definitions should be expected.  This section
+makes some recommendations to designers considering additions to the
+existing facilities.  The mailing list NAMEDROPPERS@SRI-NIC.ARPA is the
+forum where general discussion of design issues takes place.
+
+In general, a new type is appropriate when new information is to be
+added to the database about an existing object, or we need new data
+formats for some totally new object.  Designers should attempt to define
+types and their RDATA formats that are generally applicable to all
+classes, and which avoid duplication of information.  New classes are
+appropriate when the DNS is to be used for a new protocol, etc which
+requires new class-specific data formats, or when a copy of the existing
+name space is desired, but a separate management domain is necessary.
+
+New types and classes need mnemonics for master files; the format of the
+master files requires that the mnemonics for type and class be disjoint.
+
+TYPE and CLASS values must be a proper subset of QTYPEs and QCLASSes
+respectively.
+
+The present system uses multiple RRs to represent multiple values of a
+type rather than storing multiple values in the RDATA section of a
+single RR.  This is less efficient for most applications, but does keep
+RRs shorter.  The multiple RRs assumption is incorporated in some
+experimental work on dynamic update methods.
+
+The present system attempts to minimize the duplication of data in the
+database in order to insure consistency.  Thus, in order to find the
+address of the host for a mail exchange, you map the mail domain name to
+a host name, then the host name to addresses, rather than a direct
+mapping to host address.  This approach is preferred because it avoids
+the opportunity for inconsistency.
+
+In defining a new type of data, multiple RR types should not be used to
+create an ordering between entries or express different formats for
+equivalent bindings, instead this information should be carried in the
+body of the RR and a single type used.  This policy avoids problems with
+caching multiple types and defining QTYPEs to match multiple types.
+
+For example, the original form of mail exchange binding used two RR
+types one to represent a "closer" exchange (MD) and one to represent a
+"less close" exchange (MF).  The difficulty is that the presence of one
+RR type in a cache doesn't convey any information about the other
+because the query which acquired the cached information might have used
+a QTYPE of MF, MD, or MAILA (which matched both).  The redesigned
+
+
+
+Mockapetris                                                    [Page 24]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+service used a single type (MX) with a "preference" value in the RDATA
+section which can order different RRs.  However, if any MX RRs are found
+in the cache, then all should be there.
+
+4. MESSAGES
+
+4.1. Format
+
+All communications inside of the domain protocol are carried in a single
+format called a message.  The top level format of message is divided
+into 5 sections (some of which are empty in certain cases) shown below:
+
+    +---------------------+
+    |        Header       |
+    +---------------------+
+    |       Question      | the question for the name server
+    +---------------------+
+    |        Answer       | RRs answering the question
+    +---------------------+
+    |      Authority      | RRs pointing toward an authority
+    +---------------------+
+    |      Additional     | RRs holding additional information
+    +---------------------+
+
+The header section is always present.  The header includes fields that
+specify which of the remaining sections are present, and also specify
+whether the message is a query or a response, a standard query or some
+other opcode, etc.
+
+The names of the sections after the header are derived from their use in
+standard queries.  The question section contains fields that describe a
+question to a name server.  These fields are a query type (QTYPE), a
+query class (QCLASS), and a query domain name (QNAME).  The last three
+sections have the same format: a possibly empty list of concatenated
+resource records (RRs).  The answer section contains RRs that answer the
+question; the authority section contains RRs that point toward an
+authoritative name server; the additional records section contains RRs
+which relate to the query, but are not strictly answers for the
+question.
+
+
+
+
+
+
+
+
+
+
+
+
+Mockapetris                                                    [Page 25]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+4.1.1. Header section format
+
+The header contains the following fields:
+
+                                    1  1  1  1  1  1
+      0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    |                      ID                       |
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    |QR|   Opcode  |AA|TC|RD|RA|   Z    |   RCODE   |
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    |                    QDCOUNT                    |
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    |                    ANCOUNT                    |
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    |                    NSCOUNT                    |
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    |                    ARCOUNT                    |
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+where:
+
+ID              A 16 bit identifier assigned by the program that
+                generates any kind of query.  This identifier is copied
+                the corresponding reply and can be used by the requester
+                to match up replies to outstanding queries.
+
+QR              A one bit field that specifies whether this message is a
+                query (0), or a response (1).
+
+OPCODE          A four bit field that specifies kind of query in this
+                message.  This value is set by the originator of a query
+                and copied into the response.  The values are:
+
+                0               a standard query (QUERY)
+
+                1               an inverse query (IQUERY)
+
+                2               a server status request (STATUS)
+
+                3-15            reserved for future use
+
+AA              Authoritative Answer - this bit is valid in responses,
+                and specifies that the responding name server is an
+                authority for the domain name in question section.
+
+                Note that the contents of the answer section may have
+                multiple owner names because of aliases.  The AA bit
+
+
+
+Mockapetris                                                    [Page 26]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+                corresponds to the name which matches the query name, or
+                the first owner name in the answer section.
+
+TC              TrunCation - specifies that this message was truncated
+                due to length greater than that permitted on the
+                transmission channel.
+
+RD              Recursion Desired - this bit may be set in a query and
+                is copied into the response.  If RD is set, it directs
+                the name server to pursue the query recursively.
+                Recursive query support is optional.
+
+RA              Recursion Available - this be is set or cleared in a
+                response, and denotes whether recursive query support is
+                available in the name server.
+
+Z               Reserved for future use.  Must be zero in all queries
+                and responses.
+
+RCODE           Response code - this 4 bit field is set as part of
+                responses.  The values have the following
+                interpretation:
+
+                0               No error condition
+
+                1               Format error - The name server was
+                                unable to interpret the query.
+
+                2               Server failure - The name server was
+                                unable to process this query due to a
+                                problem with the name server.
+
+                3               Name Error - Meaningful only for
+                                responses from an authoritative name
+                                server, this code signifies that the
+                                domain name referenced in the query does
+                                not exist.
+
+                4               Not Implemented - The name server does
+                                not support the requested kind of query.
+
+                5               Refused - The name server refuses to
+                                perform the specified operation for
+                                policy reasons.  For example, a name
+                                server may not wish to provide the
+                                information to the particular requester,
+                                or a name server may not wish to perform
+                                a particular operation (e.g., zone
+
+
+
+Mockapetris                                                    [Page 27]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+                                transfer) for particular data.
+
+                6-15            Reserved for future use.
+
+QDCOUNT         an unsigned 16 bit integer specifying the number of
+                entries in the question section.
+
+ANCOUNT         an unsigned 16 bit integer specifying the number of
+                resource records in the answer section.
+
+NSCOUNT         an unsigned 16 bit integer specifying the number of name
+                server resource records in the authority records
+                section.
+
+ARCOUNT         an unsigned 16 bit integer specifying the number of
+                resource records in the additional records section.
+
+4.1.2. Question section format
+
+The question section is used to carry the "question" in most queries,
+i.e., the parameters that define what is being asked.  The section
+contains QDCOUNT (usually 1) entries, each of the following format:
+
+                                    1  1  1  1  1  1
+      0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    |                                               |
+    /                     QNAME                     /
+    /                                               /
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    |                     QTYPE                     |
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    |                     QCLASS                    |
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+where:
+
+QNAME           a domain name represented as a sequence of labels, where
+                each label consists of a length octet followed by that
+                number of octets.  The domain name terminates with the
+                zero length octet for the null label of the root.  Note
+                that this field may be an odd number of octets; no
+                padding is used.
+
+QTYPE           a two octet code which specifies the type of the query.
+                The values for this field include all codes valid for a
+                TYPE field, together with some more general codes which
+                can match more than one type of RR.
+
+
+
+Mockapetris                                                    [Page 28]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+QCLASS          a two octet code that specifies the class of the query.
+                For example, the QCLASS field is IN for the Internet.
+
+4.1.3. Resource record format
+
+The answer, authority, and additional sections all share the same
+format: a variable number of resource records, where the number of
+records is specified in the corresponding count field in the header.
+Each resource record has the following format:
+                                    1  1  1  1  1  1
+      0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    |                                               |
+    /                                               /
+    /                      NAME                     /
+    |                                               |
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    |                      TYPE                     |
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    |                     CLASS                     |
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    |                      TTL                      |
+    |                                               |
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    |                   RDLENGTH                    |
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
+    /                     RDATA                     /
+    /                                               /
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+where:
+
+NAME            a domain name to which this resource record pertains.
+
+TYPE            two octets containing one of the RR type codes.  This
+                field specifies the meaning of the data in the RDATA
+                field.
+
+CLASS           two octets which specify the class of the data in the
+                RDATA field.
+
+TTL             a 32 bit unsigned integer that specifies the time
+                interval (in seconds) that the resource record may be
+                cached before it should be discarded.  Zero values are
+                interpreted to mean that the RR can only be used for the
+                transaction in progress, and should not be cached.
+
+
+
+
+
+Mockapetris                                                    [Page 29]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+RDLENGTH        an unsigned 16 bit integer that specifies the length in
+                octets of the RDATA field.
+
+RDATA           a variable length string of octets that describes the
+                resource.  The format of this information varies
+                according to the TYPE and CLASS of the resource record.
+                For example, the if the TYPE is A and the CLASS is IN,
+                the RDATA field is a 4 octet ARPA Internet address.
+
+4.1.4. Message compression
+
+In order to reduce the size of messages, the domain system utilizes a
+compression scheme which eliminates the repetition of domain names in a
+message.  In this scheme, an entire domain name or a list of labels at
+the end of a domain name is replaced with a pointer to a prior occurance
+of the same name.
+
+The pointer takes the form of a two octet sequence:
+
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    | 1  1|                OFFSET                   |
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+The first two bits are ones.  This allows a pointer to be distinguished
+from a label, since the label must begin with two zero bits because
+labels are restricted to 63 octets or less.  (The 10 and 01 combinations
+are reserved for future use.)  The OFFSET field specifies an offset from
+the start of the message (i.e., the first octet of the ID field in the
+domain header).  A zero offset specifies the first byte of the ID field,
+etc.
+
+The compression scheme allows a domain name in a message to be
+represented as either:
+
+   - a sequence of labels ending in a zero octet
+
+   - a pointer
+
+   - a sequence of labels ending with a pointer
+
+Pointers can only be used for occurances of a domain name where the
+format is not class specific.  If this were not the case, a name server
+or resolver would be required to know the format of all RRs it handled.
+As yet, there are no such cases, but they may occur in future RDATA
+formats.
+
+If a domain name is contained in a part of the message subject to a
+length field (such as the RDATA section of an RR), and compression is
+
+
+
+Mockapetris                                                    [Page 30]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+used, the length of the compressed name is used in the length
+calculation, rather than the length of the expanded name.
+
+Programs are free to avoid using pointers in messages they generate,
+although this will reduce datagram capacity, and may cause truncation.
+However all programs are required to understand arriving messages that
+contain pointers.
+
+For example, a datagram might need to use the domain names F.ISI.ARPA,
+FOO.F.ISI.ARPA, ARPA, and the root.  Ignoring the other fields of the
+message, these domain names might be represented as:
+
+       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    20 |           1           |           F           |
+       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    22 |           3           |           I           |
+       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    24 |           S           |           I           |
+       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    26 |           4           |           A           |
+       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    28 |           R           |           P           |
+       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    30 |           A           |           0           |
+       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    40 |           3           |           F           |
+       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    42 |           O           |           O           |
+       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    44 | 1  1|                20                       |
+       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    64 | 1  1|                26                       |
+       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    92 |           0           |                       |
+       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+The domain name for F.ISI.ARPA is shown at offset 20.  The domain name
+FOO.F.ISI.ARPA is shown at offset 40; this definition uses a pointer to
+concatenate a label for FOO to the previously defined F.ISI.ARPA.  The
+domain name ARPA is defined at offset 64 using a pointer to the ARPA
+component of the name F.ISI.ARPA at 20; note that this pointer relies on
+ARPA being the last label in the string at 20.  The root domain name is
+
+
+
+Mockapetris                                                    [Page 31]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+defined by a single octet of zeros at 92; the root domain name has no
+labels.
+
+4.2. Transport
+
+The DNS assumes that messages will be transmitted as datagrams or in a
+byte stream carried by a virtual circuit.  While virtual circuits can be
+used for any DNS activity, datagrams are preferred for queries due to
+their lower overhead and better performance.  Zone refresh activities
+must use virtual circuits because of the need for reliable transfer.
+
+The Internet supports name server access using TCP [RFC-793] on server
+port 53 (decimal) as well as datagram access using UDP [RFC-768] on UDP
+port 53 (decimal).
+
+4.2.1. UDP usage
+
+Messages sent using UDP user server port 53 (decimal).
+
+Messages carried by UDP are restricted to 512 bytes (not counting the IP
+or UDP headers).  Longer messages are truncated and the TC bit is set in
+the header.
+
+UDP is not acceptable for zone transfers, but is the recommended method
+for standard queries in the Internet.  Queries sent using UDP may be
+lost, and hence a retransmission strategy is required.  Queries or their
+responses may be reordered by the network, or by processing in name
+servers, so resolvers should not depend on them being returned in order.
+
+The optimal UDP retransmission policy will vary with performance of the
+Internet and the needs of the client, but the following are recommended:
+
+   - The client should try other servers and server addresses
+     before repeating a query to a specific address of a server.
+
+   - The retransmission interval should be based on prior
+     statistics if possible.  Too aggressive retransmission can
+     easily slow responses for the community at large.  Depending
+     on how well connected the client is to its expected servers,
+     the minimum retransmission interval should be 2-5 seconds.
+
+More suggestions on server selection and retransmission policy can be
+found in the resolver section of this memo.
+
+4.2.2. TCP usage
+
+Messages sent over TCP connections use server port 53 (decimal).  The
+message is prefixed with a two byte length field which gives the message
+
+
+
+Mockapetris                                                    [Page 32]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+length, excluding the two byte length field.  This length field allows
+the low-level processing to assemble a complete message before beginning
+to parse it.
+
+Several connection management policies are recommended:
+
+   - The server should not block other activities waiting for TCP
+     data.
+
+   - The server should support multiple connections.
+
+   - The server should assume that the client will initiate
+     connection closing, and should delay closing its end of the
+     connection until all outstanding client requests have been
+     satisfied.
+
+   - If the server needs to close a dormant connection to reclaim
+     resources, it should wait until the connection has been idle
+     for a period on the order of two minutes.  In particular, the
+     server should allow the SOA and AXFR request sequence (which
+     begins a refresh operation) to be made on a single connection.
+     Since the server would be unable to answer queries anyway, a
+     unilateral close or reset may be used instead of a graceful
+     close.
+
+5. MASTER FILES
+
+Master files are text files that contain RRs in text form.  Since the
+contents of a zone can be expressed in the form of a list of RRs a
+master file is most often used to define a zone, though it can be used
+to list a cache's contents.  Hence, this section first discusses the
+format of RRs in a master file, and then the special considerations when
+a master file is used to create a zone in some name server.
+
+5.1. Format
+
+The format of these files is a sequence of entries.  Entries are
+predominantly line-oriented, though parentheses can be used to continue
+a list of items across a line boundary, and text literals can contain
+CRLF within the text.  Any combination of tabs and spaces act as a
+delimiter between the separate items that make up an entry.  The end of
+any line in the master file can end with a comment.  The comment starts
+with a ";" (semicolon).
+
+The following entries are defined:
+
+    <blank>[<comment>]
+
+
+
+
+Mockapetris                                                    [Page 33]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+    $ORIGIN <domain-name> [<comment>]
+
+    $INCLUDE <file-name> [<domain-name>] [<comment>]
+
+    <domain-name><rr> [<comment>]
+
+    <blank><rr> [<comment>]
+
+Blank lines, with or without comments, are allowed anywhere in the file.
+
+Two control entries are defined: $ORIGIN and $INCLUDE.  $ORIGIN is
+followed by a domain name, and resets the current origin for relative
+domain names to the stated name.  $INCLUDE inserts the named file into
+the current file, and may optionally specify a domain name that sets the
+relative domain name origin for the included file.  $INCLUDE may also
+have a comment.  Note that a $INCLUDE entry never changes the relative
+origin of the parent file, regardless of changes to the relative origin
+made within the included file.
+
+The last two forms represent RRs.  If an entry for an RR begins with a
+blank, then the RR is assumed to be owned by the last stated owner.  If
+an RR entry begins with a <domain-name>, then the owner name is reset.
+
+<rr> contents take one of the following forms:
+
+    [<TTL>] [<class>] <type> <RDATA>
+
+    [<class>] [<TTL>] <type> <RDATA>
+
+The RR begins with optional TTL and class fields, followed by a type and
+RDATA field appropriate to the type and class.  Class and type use the
+standard mnemonics, TTL is a decimal integer.  Omitted class and TTL
+values are default to the last explicitly stated values.  Since type and
+class mnemonics are disjoint, the parse is unique.  (Note that this
+order is different from the order used in examples and the order used in
+the actual RRs; the given order allows easier parsing and defaulting.)
+
+<domain-name>s make up a large share of the data in the master file.
+The labels in the domain name are expressed as character strings and
+separated by dots.  Quoting conventions allow arbitrary characters to be
+stored in domain names.  Domain names that end in a dot are called
+absolute, and are taken as complete.  Domain names which do not end in a
+dot are called relative; the actual domain name is the concatenation of
+the relative part with an origin specified in a $ORIGIN, $INCLUDE, or as
+an argument to the master file loading routine.  A relative name is an
+error when no origin is available.
+
+
+
+
+
+Mockapetris                                                    [Page 34]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+<character-string> is expressed in one or two ways: as a contiguous set
+of characters without interior spaces, or as a string beginning with a "
+and ending with a ".  Inside a " delimited string any character can
+occur, except for a " itself, which must be quoted using \ (back slash).
+
+Because these files are text files several special encodings are
+necessary to allow arbitrary data to be loaded.  In particular:
+
+                of the root.
+
+@               A free standing @ is used to denote the current origin.
+
+\X              where X is any character other than a digit (0-9), is
+                used to quote that character so that its special meaning
+                does not apply.  For example, "\." can be used to place
+                a dot character in a label.
+
+\DDD            where each D is a digit is the octet corresponding to
+                the decimal number described by DDD.  The resulting
+                octet is assumed to be text and is not checked for
+                special meaning.
+
+( )             Parentheses are used to group data that crosses a line
+                boundary.  In effect, line terminations are not
+                recognized within parentheses.
+
+;               Semicolon is used to start a comment; the remainder of
+                the line is ignored.
+
+5.2. Use of master files to define zones
+
+When a master file is used to load a zone, the operation should be
+suppressed if any errors are encountered in the master file.  The
+rationale for this is that a single error can have widespread
+consequences.  For example, suppose that the RRs defining a delegation
+have syntax errors; then the server will return authoritative name
+errors for all names in the subzone (except in the case where the
+subzone is also present on the server).
+
+Several other validity checks that should be performed in addition to
+insuring that the file is syntactically correct:
+
+   1. All RRs in the file should have the same class.
+
+   2. Exactly one SOA RR should be present at the top of the zone.
+
+   3. If delegations are present and glue information is required,
+      it should be present.
+
+
+
+Mockapetris                                                    [Page 35]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+   4. Information present outside of the authoritative nodes in the
+      zone should be glue information, rather than the result of an
+      origin or similar error.
+
+5.3. Master file example
+
+The following is an example file which might be used to define the
+ISI.EDU zone.and is loaded with an origin of ISI.EDU:
+
+@   IN  SOA     VENERA      Action\.domains (
+                                 20     ; SERIAL
+                                 7200   ; REFRESH
+                                 600    ; RETRY
+                                 3600000; EXPIRE
+                                 60)    ; MINIMUM
+
+        NS      A.ISI.EDU.
+        NS      VENERA
+        NS      VAXA
+        MX      10      VENERA
+        MX      20      VAXA
+
+A       A       26.3.0.103
+
+VENERA  A       10.1.0.52
+        A       128.9.0.32
+
+VAXA    A       10.2.0.27
+        A       128.9.0.33
+
+
+$INCLUDE <SUBSYS>ISI-MAILBOXES.TXT
+
+Where the file <SUBSYS>ISI-MAILBOXES.TXT is:
+
+    MOE     MB      A.ISI.EDU.
+    LARRY   MB      A.ISI.EDU.
+    CURLEY  MB      A.ISI.EDU.
+    STOOGES MG      MOE
+            MG      LARRY
+            MG      CURLEY
+
+Note the use of the \ character in the SOA RR to specify the responsible
+person mailbox "Action.domains@E.ISI.EDU".
+
+
+
+
+
+
+
+Mockapetris                                                    [Page 36]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+6. NAME SERVER IMPLEMENTATION
+
+6.1. Architecture
+
+The optimal structure for the name server will depend on the host
+operating system and whether the name server is integrated with resolver
+operations, either by supporting recursive service, or by sharing its
+database with a resolver.  This section discusses implementation
+considerations for a name server which shares a database with a
+resolver, but most of these concerns are present in any name server.
+
+6.1.1. Control
+
+A name server must employ multiple concurrent activities, whether they
+are implemented as separate tasks in the host's OS or multiplexing
+inside a single name server program.  It is simply not acceptable for a
+name server to block the service of UDP requests while it waits for TCP
+data for refreshing or query activities.  Similarly, a name server
+should not attempt to provide recursive service without processing such
+requests in parallel, though it may choose to serialize requests from a
+single client, or to regard identical requests from the same client as
+duplicates.  A name server should not substantially delay requests while
+it reloads a zone from master files or while it incorporates a newly
+refreshed zone into its database.
+
+6.1.2. Database
+
+While name server implementations are free to use any internal data
+structures they choose, the suggested structure consists of three major
+parts:
+
+   - A "catalog" data structure which lists the zones available to
+     this server, and a "pointer" to the zone data structure.  The
+     main purpose of this structure is to find the nearest ancestor
+     zone, if any, for arriving standard queries.
+
+   - Separate data structures for each of the zones held by the
+     name server.
+
+   - A data structure for cached data. (or perhaps separate caches
+     for different classes)
+
+All of these data structures can be implemented an identical tree
+structure format, with different data chained off the nodes in different
+parts: in the catalog the data is pointers to zones, while in the zone
+and cache data structures, the data will be RRs.  In designing the tree
+framework the designer should recognize that query processing will need
+to traverse the tree using case-insensitive label comparisons; and that
+
+
+
+Mockapetris                                                    [Page 37]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+in real data, a few nodes have a very high branching factor (100-1000 or
+more), but the vast majority have a very low branching factor (0-1).
+
+One way to solve the case problem is to store the labels for each node
+in two pieces: a standardized-case representation of the label where all
+ASCII characters are in a single case, together with a bit mask that
+denotes which characters are actually of a different case.  The
+branching factor diversity can be handled using a simple linked list for
+a node until the branching factor exceeds some threshold, and
+transitioning to a hash structure after the threshold is exceeded.  In
+any case, hash structures used to store tree sections must insure that
+hash functions and procedures preserve the casing conventions of the
+DNS.
+
+The use of separate structures for the different parts of the database
+is motivated by several factors:
+
+   - The catalog structure can be an almost static structure that
+     need change only when the system administrator changes the
+     zones supported by the server.  This structure can also be
+     used to store parameters used to control refreshing
+     activities.
+
+   - The individual data structures for zones allow a zone to be
+     replaced simply by changing a pointer in the catalog.  Zone
+     refresh operations can build a new structure and, when
+     complete, splice it into the database via a simple pointer
+     replacement.  It is very important that when a zone is
+     refreshed, queries should not use old and new data
+     simultaneously.
+
+   - With the proper search procedures, authoritative data in zones
+     will always "hide", and hence take precedence over, cached
+     data.
+
+   - Errors in zone definitions that cause overlapping zones, etc.,
+     may cause erroneous responses to queries, but problem
+     determination is simplified, and the contents of one "bad"
+     zone can't corrupt another.
+
+   - Since the cache is most frequently updated, it is most
+     vulnerable to corruption during system restarts.  It can also
+     become full of expired RR data.  In either case, it can easily
+     be discarded without disturbing zone data.
+
+A major aspect of database design is selecting a structure which allows
+the name server to deal with crashes of the name server's host.  State
+information which a name server should save across system crashes
+
+
+
+Mockapetris                                                    [Page 38]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+includes the catalog structure (including the state of refreshing for
+each zone) and the zone data itself.
+
+6.1.3. Time
+
+Both the TTL data for RRs and the timing data for refreshing activities
+depends on 32 bit timers in units of seconds.  Inside the database,
+refresh timers and TTLs for cached data conceptually "count down", while
+data in the zone stays with constant TTLs.
+
+A recommended implementation strategy is to store time in two ways:  as
+a relative increment and as an absolute time.  One way to do this is to
+use positive 32 bit numbers for one type and negative numbers for the
+other.  The RRs in zones use relative times; the refresh timers and
+cache data use absolute times.  Absolute numbers are taken with respect
+to some known origin and converted to relative values when placed in the
+response to a query.  When an absolute TTL is negative after conversion
+to relative, then the data is expired and should be ignored.
+
+6.2. Standard query processing
+
+The major algorithm for standard query processing is presented in
+[RFC-1034].
+
+When processing queries with QCLASS=*, or some other QCLASS which
+matches multiple classes, the response should never be authoritative
+unless the server can guarantee that the response covers all classes.
+
+When composing a response, RRs which are to be inserted in the
+additional section, but duplicate RRs in the answer or authority
+sections, may be omitted from the additional section.
+
+When a response is so long that truncation is required, the truncation
+should start at the end of the response and work forward in the
+datagram.  Thus if there is any data for the authority section, the
+answer section is guaranteed to be unique.
+
+The MINIMUM value in the SOA should be used to set a floor on the TTL of
+data distributed from a zone.  This floor function should be done when
+the data is copied into a response.  This will allow future dynamic
+update protocols to change the SOA MINIMUM field without ambiguous
+semantics.
+
+6.3. Zone refresh and reload processing
+
+In spite of a server's best efforts, it may be unable to load zone data
+from a master file due to syntax errors, etc., or be unable to refresh a
+zone within the its expiration parameter.  In this case, the name server
+
+
+
+Mockapetris                                                    [Page 39]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+should answer queries as if it were not supposed to possess the zone.
+
+If a master is sending a zone out via AXFR, and a new version is created
+during the transfer, the master should continue to send the old version
+if possible.  In any case, it should never send part of one version and
+part of another.  If completion is not possible, the master should reset
+the connection on which the zone transfer is taking place.
+
+6.4. Inverse queries (Optional)
+
+Inverse queries are an optional part of the DNS.  Name servers are not
+required to support any form of inverse queries.  If a name server
+receives an inverse query that it does not support, it returns an error
+response with the "Not Implemented" error set in the header.  While
+inverse query support is optional, all name servers must be at least
+able to return the error response.
+
+6.4.1. The contents of inverse queries and responses          Inverse
+queries reverse the mappings performed by standard query operations;
+while a standard query maps a domain name to a resource, an inverse
+query maps a resource to a domain name.  For example, a standard query
+might bind a domain name to a host address; the corresponding inverse
+query binds the host address to a domain name.
+
+Inverse queries take the form of a single RR in the answer section of
+the message, with an empty question section.  The owner name of the
+query RR and its TTL are not significant.  The response carries
+questions in the question section which identify all names possessing
+the query RR WHICH THE NAME SERVER KNOWS.  Since no name server knows
+about all of the domain name space, the response can never be assumed to
+be complete.  Thus inverse queries are primarily useful for database
+management and debugging activities.  Inverse queries are NOT an
+acceptable method of mapping host addresses to host names; use the IN-
+ADDR.ARPA domain instead.
+
+Where possible, name servers should provide case-insensitive comparisons
+for inverse queries.  Thus an inverse query asking for an MX RR of
+"Venera.isi.edu" should get the same response as a query for
+"VENERA.ISI.EDU"; an inverse query for HINFO RR "IBM-PC UNIX" should
+produce the same result as an inverse query for "IBM-pc unix".  However,
+this cannot be guaranteed because name servers may possess RRs that
+contain character strings but the name server does not know that the
+data is character.
+
+When a name server processes an inverse query, it either returns:
+
+   1. zero, one, or multiple domain names for the specified
+      resource as QNAMEs in the question section
+
+
+
+Mockapetris                                                    [Page 40]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+   2. an error code indicating that the name server doesn't support
+      inverse mapping of the specified resource type.
+
+When the response to an inverse query contains one or more QNAMEs, the
+owner name and TTL of the RR in the answer section which defines the
+inverse query is modified to exactly match an RR found at the first
+QNAME.
+
+RRs returned in the inverse queries cannot be cached using the same
+mechanism as is used for the replies to standard queries.  One reason
+for this is that a name might have multiple RRs of the same type, and
+only one would appear.  For example, an inverse query for a single
+address of a multiply homed host might create the impression that only
+one address existed.
+
+6.4.2. Inverse query and response example          The overall structure
+of an inverse query for retrieving the domain name that corresponds to
+Internet address 10.1.0.52 is shown below:
+
+                         +-----------------------------------------+
+           Header        |          OPCODE=IQUERY, ID=997          |
+                         +-----------------------------------------+
+          Question       |                 <empty>                 |
+                         +-----------------------------------------+
+           Answer        |        <anyname> A IN 10.1.0.52         |
+                         +-----------------------------------------+
+          Authority      |                 <empty>                 |
+                         +-----------------------------------------+
+         Additional      |                 <empty>                 |
+                         +-----------------------------------------+
+
+This query asks for a question whose answer is the Internet style
+address 10.1.0.52.  Since the owner name is not known, any domain name
+can be used as a placeholder (and is ignored).  A single octet of zero,
+signifying the root, is usually used because it minimizes the length of
+the message.  The TTL of the RR is not significant.  The response to
+this query might be:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mockapetris                                                    [Page 41]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+                         +-----------------------------------------+
+           Header        |         OPCODE=RESPONSE, ID=997         |
+                         +-----------------------------------------+
+          Question       |QTYPE=A, QCLASS=IN, QNAME=VENERA.ISI.EDU |
+                         +-----------------------------------------+
+           Answer        |  VENERA.ISI.EDU  A IN 10.1.0.52         |
+                         +-----------------------------------------+
+          Authority      |                 <empty>                 |
+                         +-----------------------------------------+
+         Additional      |                 <empty>                 |
+                         +-----------------------------------------+
+
+Note that the QTYPE in a response to an inverse query is the same as the
+TYPE field in the answer section of the inverse query.  Responses to
+inverse queries may contain multiple questions when the inverse is not
+unique.  If the question section in the response is not empty, then the
+RR in the answer section is modified to correspond to be an exact copy
+of an RR at the first QNAME.
+
+6.4.3. Inverse query processing
+
+Name servers that support inverse queries can support these operations
+through exhaustive searches of their databases, but this becomes
+impractical as the size of the database increases.  An alternative
+approach is to invert the database according to the search key.
+
+For name servers that support multiple zones and a large amount of data,
+the recommended approach is separate inversions for each zone.  When a
+particular zone is changed during a refresh, only its inversions need to
+be redone.
+
+Support for transfer of this type of inversion may be included in future
+versions of the domain system, but is not supported in this version.
+
+6.5. Completion queries and responses
+
+The optional completion services described in RFC-882 and RFC-883 have
+been deleted.  Redesigned services may become available in the future.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mockapetris                                                    [Page 42]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+7. RESOLVER IMPLEMENTATION
+
+The top levels of the recommended resolver algorithm are discussed in
+[RFC-1034].  This section discusses implementation details assuming the
+database structure suggested in the name server implementation section
+of this memo.
+
+7.1. Transforming a user request into a query
+
+The first step a resolver takes is to transform the client's request,
+stated in a format suitable to the local OS, into a search specification
+for RRs at a specific name which match a specific QTYPE and QCLASS.
+Where possible, the QTYPE and QCLASS should correspond to a single type
+and a single class, because this makes the use of cached data much
+simpler.  The reason for this is that the presence of data of one type
+in a cache doesn't confirm the existence or non-existence of data of
+other types, hence the only way to be sure is to consult an
+authoritative source.  If QCLASS=* is used, then authoritative answers
+won't be available.
+
+Since a resolver must be able to multiplex multiple requests if it is to
+perform its function efficiently, each pending request is usually
+represented in some block of state information.  This state block will
+typically contain:
+
+   - A timestamp indicating the time the request began.
+     The timestamp is used to decide whether RRs in the database
+     can be used or are out of date.  This timestamp uses the
+     absolute time format previously discussed for RR storage in
+     zones and caches.  Note that when an RRs TTL indicates a
+     relative time, the RR must be timely, since it is part of a
+     zone.  When the RR has an absolute time, it is part of a
+     cache, and the TTL of the RR is compared against the timestamp
+     for the start of the request.
+
+     Note that using the timestamp is superior to using a current
+     time, since it allows RRs with TTLs of zero to be entered in
+     the cache in the usual manner, but still used by the current
+     request, even after intervals of many seconds due to system
+     load, query retransmission timeouts, etc.
+
+   - Some sort of parameters to limit the amount of work which will
+     be performed for this request.
+
+     The amount of work which a resolver will do in response to a
+     client request must be limited to guard against errors in the
+     database, such as circular CNAME references, and operational
+     problems, such as network partition which prevents the
+
+
+
+Mockapetris                                                    [Page 43]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+     resolver from accessing the name servers it needs.  While
+     local limits on the number of times a resolver will retransmit
+     a particular query to a particular name server address are
+     essential, the resolver should have a global per-request
+     counter to limit work on a single request.  The counter should
+     be set to some initial value and decremented whenever the
+     resolver performs any action (retransmission timeout,
+     retransmission, etc.)  If the counter passes zero, the request
+     is terminated with a temporary error.
+
+     Note that if the resolver structure allows one request to
+     start others in parallel, such as when the need to access a
+     name server for one request causes a parallel resolve for the
+     name server's addresses, the spawned request should be started
+     with a lower counter.  This prevents circular references in
+     the database from starting a chain reaction of resolver
+     activity.
+
+   - The SLIST data structure discussed in [RFC-1034].
+
+     This structure keeps track of the state of a request if it
+     must wait for answers from foreign name servers.
+
+7.2. Sending the queries
+
+As described in [RFC-1034], the basic task of the resolver is to
+formulate a query which will answer the client's request and direct that
+query to name servers which can provide the information.  The resolver
+will usually only have very strong hints about which servers to ask, in
+the form of NS RRs, and may have to revise the query, in response to
+CNAMEs, or revise the set of name servers the resolver is asking, in
+response to delegation responses which point the resolver to name
+servers closer to the desired information.  In addition to the
+information requested by the client, the resolver may have to call upon
+its own services to determine the address of name servers it wishes to
+contact.
+
+In any case, the model used in this memo assumes that the resolver is
+multiplexing attention between multiple requests, some from the client,
+and some internally generated.  Each request is represented by some
+state information, and the desired behavior is that the resolver
+transmit queries to name servers in a way that maximizes the probability
+that the request is answered, minimizes the time that the request takes,
+and avoids excessive transmissions.  The key algorithm uses the state
+information of the request to select the next name server address to
+query, and also computes a timeout which will cause the next action
+should a response not arrive.  The next action will usually be a
+transmission to some other server, but may be a temporary error to the
+
+
+
+Mockapetris                                                    [Page 44]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+client.
+
+The resolver always starts with a list of server names to query (SLIST).
+This list will be all NS RRs which correspond to the nearest ancestor
+zone that the resolver knows about.  To avoid startup problems, the
+resolver should have a set of default servers which it will ask should
+it have no current NS RRs which are appropriate.  The resolver then adds
+to SLIST all of the known addresses for the name servers, and may start
+parallel requests to acquire the addresses of the servers when the
+resolver has the name, but no addresses, for the name servers.
+
+To complete initialization of SLIST, the resolver attaches whatever
+history information it has to the each address in SLIST.  This will
+usually consist of some sort of weighted averages for the response time
+of the address, and the batting average of the address (i.e., how often
+the address responded at all to the request).  Note that this
+information should be kept on a per address basis, rather than on a per
+name server basis, because the response time and batting average of a
+particular server may vary considerably from address to address.  Note
+also that this information is actually specific to a resolver address /
+server address pair, so a resolver with multiple addresses may wish to
+keep separate histories for each of its addresses.  Part of this step
+must deal with addresses which have no such history; in this case an
+expected round trip time of 5-10 seconds should be the worst case, with
+lower estimates for the same local network, etc.
+
+Note that whenever a delegation is followed, the resolver algorithm
+reinitializes SLIST.
+
+The information establishes a partial ranking of the available name
+server addresses.  Each time an address is chosen and the state should
+be altered to prevent its selection again until all other addresses have
+been tried.  The timeout for each transmission should be 50-100% greater
+than the average predicted value to allow for variance in response.
+
+Some fine points:
+
+   - The resolver may encounter a situation where no addresses are
+     available for any of the name servers named in SLIST, and
+     where the servers in the list are precisely those which would
+     normally be used to look up their own addresses.  This
+     situation typically occurs when the glue address RRs have a
+     smaller TTL than the NS RRs marking delegation, or when the
+     resolver caches the result of a NS search.  The resolver
+     should detect this condition and restart the search at the
+     next ancestor zone, or alternatively at the root.
+
+
+
+
+
+Mockapetris                                                    [Page 45]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+   - If a resolver gets a server error or other bizarre response
+     from a name server, it should remove it from SLIST, and may
+     wish to schedule an immediate transmission to the next
+     candidate server address.
+
+7.3. Processing responses
+
+The first step in processing arriving response datagrams is to parse the
+response.  This procedure should include:
+
+   - Check the header for reasonableness.  Discard datagrams which
+     are queries when responses are expected.
+
+   - Parse the sections of the message, and insure that all RRs are
+     correctly formatted.
+
+   - As an optional step, check the TTLs of arriving data looking
+     for RRs with excessively long TTLs.  If a RR has an
+     excessively long TTL, say greater than 1 week, either discard
+     the whole response, or limit all TTLs in the response to 1
+     week.
+
+The next step is to match the response to a current resolver request.
+The recommended strategy is to do a preliminary matching using the ID
+field in the domain header, and then to verify that the question section
+corresponds to the information currently desired.  This requires that
+the transmission algorithm devote several bits of the domain ID field to
+a request identifier of some sort.  This step has several fine points:
+
+   - Some name servers send their responses from different
+     addresses than the one used to receive the query.  That is, a
+     resolver cannot rely that a response will come from the same
+     address which it sent the corresponding query to.  This name
+     server bug is typically encountered in UNIX systems.
+
+   - If the resolver retransmits a particular request to a name
+     server it should be able to use a response from any of the
+     transmissions.  However, if it is using the response to sample
+     the round trip time to access the name server, it must be able
+     to determine which transmission matches the response (and keep
+     transmission times for each outgoing message), or only
+     calculate round trip times based on initial transmissions.
+
+   - A name server will occasionally not have a current copy of a
+     zone which it should have according to some NS RRs.  The
+     resolver should simply remove the name server from the current
+     SLIST, and continue.
+
+
+
+
+Mockapetris                                                    [Page 46]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+7.4. Using the cache
+
+In general, we expect a resolver to cache all data which it receives in
+responses since it may be useful in answering future client requests.
+However, there are several types of data which should not be cached:
+
+   - When several RRs of the same type are available for a
+     particular owner name, the resolver should either cache them
+     all or none at all.  When a response is truncated, and a
+     resolver doesn't know whether it has a complete set, it should
+     not cache a possibly partial set of RRs.
+
+   - Cached data should never be used in preference to
+     authoritative data, so if caching would cause this to happen
+     the data should not be cached.
+
+   - The results of an inverse query should not be cached.
+
+   - The results of standard queries where the QNAME contains "*"
+     labels if the data might be used to construct wildcards.  The
+     reason is that the cache does not necessarily contain existing
+     RRs or zone boundary information which is necessary to
+     restrict the application of the wildcard RRs.
+
+   - RR data in responses of dubious reliability.  When a resolver
+     receives unsolicited responses or RR data other than that
+     requested, it should discard it without caching it.  The basic
+     implication is that all sanity checks on a packet should be
+     performed before any of it is cached.
+
+In a similar vein, when a resolver has a set of RRs for some name in a
+response, and wants to cache the RRs, it should check its cache for
+already existing RRs.  Depending on the circumstances, either the data
+in the response or the cache is preferred, but the two should never be
+combined.  If the data in the response is from authoritative data in the
+answer section, it is always preferred.
+
+8. MAIL SUPPORT
+
+The domain system defines a standard for mapping mailboxes into domain
+names, and two methods for using the mailbox information to derive mail
+routing information.  The first method is called mail exchange binding
+and the other method is mailbox binding.  The mailbox encoding standard
+and mail exchange binding are part of the DNS official protocol, and are
+the recommended method for mail routing in the Internet.  Mailbox
+binding is an experimental feature which is still under development and
+subject to change.
+
+
+
+
+Mockapetris                                                    [Page 47]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+The mailbox encoding standard assumes a mailbox name of the form
+"<local-part>@<mail-domain>".  While the syntax allowed in each of these
+sections varies substantially between the various mail internets, the
+preferred syntax for the ARPA Internet is given in [RFC-822].
+
+The DNS encodes the <local-part> as a single label, and encodes the
+<mail-domain> as a domain name.  The single label from the <local-part>
+is prefaced to the domain name from <mail-domain> to form the domain
+name corresponding to the mailbox.  Thus the mailbox HOSTMASTER@SRI-
+NIC.ARPA is mapped into the domain name HOSTMASTER.SRI-NIC.ARPA.  If the
+<local-part> contains dots or other special characters, its
+representation in a master file will require the use of backslash
+quoting to ensure that the domain name is properly encoded.  For
+example, the mailbox Action.domains@ISI.EDU would be represented as
+Action\.domains.ISI.EDU.
+
+8.1. Mail exchange binding
+
+Mail exchange binding uses the <mail-domain> part of a mailbox
+specification to determine where mail should be sent.  The <local-part>
+is not even consulted.  [RFC-974] specifies this method in detail, and
+should be consulted before attempting to use mail exchange support.
+
+One of the advantages of this method is that it decouples mail
+destination naming from the hosts used to support mail service, at the
+cost of another layer of indirection in the lookup function.  However,
+the addition layer should eliminate the need for complicated "%", "!",
+etc encodings in <local-part>.
+
+The essence of the method is that the <mail-domain> is used as a domain
+name to locate type MX RRs which list hosts willing to accept mail for
+<mail-domain>, together with preference values which rank the hosts
+according to an order specified by the administrators for <mail-domain>.
+
+In this memo, the <mail-domain> ISI.EDU is used in examples, together
+with the hosts VENERA.ISI.EDU and VAXA.ISI.EDU as mail exchanges for
+ISI.EDU.  If a mailer had a message for Mockapetris@ISI.EDU, it would
+route it by looking up MX RRs for ISI.EDU.  The MX RRs at ISI.EDU name
+VENERA.ISI.EDU and VAXA.ISI.EDU, and type A queries can find the host
+addresses.
+
+8.2. Mailbox binding (Experimental)
+
+In mailbox binding, the mailer uses the entire mail destination
+specification to construct a domain name.  The encoded domain name for
+the mailbox is used as the QNAME field in a QTYPE=MAILB query.
+
+Several outcomes are possible for this query:
+
+
+
+Mockapetris                                                    [Page 48]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+   1. The query can return a name error indicating that the mailbox
+      does not exist as a domain name.
+
+      In the long term, this would indicate that the specified
+      mailbox doesn't exist.  However, until the use of mailbox
+      binding is universal, this error condition should be
+      interpreted to mean that the organization identified by the
+      global part does not support mailbox binding.  The
+      appropriate procedure is to revert to exchange binding at
+      this point.
+
+   2. The query can return a Mail Rename (MR) RR.
+
+      The MR RR carries new mailbox specification in its RDATA
+      field.  The mailer should replace the old mailbox with the
+      new one and retry the operation.
+
+   3. The query can return a MB RR.
+
+      The MB RR carries a domain name for a host in its RDATA
+      field.  The mailer should deliver the message to that host
+      via whatever protocol is applicable, e.g., b,SMTP.
+
+   4. The query can return one or more Mail Group (MG) RRs.
+
+      This condition means that the mailbox was actually a mailing
+      list or mail group, rather than a single mailbox.  Each MG RR
+      has a RDATA field that identifies a mailbox that is a member
+      of the group.  The mailer should deliver a copy of the
+      message to each member.
+
+   5. The query can return a MB RR as well as one or more MG RRs.
+
+      This condition means the the mailbox was actually a mailing
+      list.  The mailer can either deliver the message to the host
+      specified by the MB RR, which will in turn do the delivery to
+      all members, or the mailer can use the MG RRs to do the
+      expansion itself.
+
+In any of these cases, the response may include a Mail Information
+(MINFO) RR.  This RR is usually associated with a mail group, but is
+legal with a MB.  The MINFO RR identifies two mailboxes.  One of these
+identifies a responsible person for the original mailbox name.  This
+mailbox should be used for requests to be added to a mail group, etc.
+The second mailbox name in the MINFO RR identifies a mailbox that should
+receive error messages for mail failures.  This is particularly
+appropriate for mailing lists when errors in member names should be
+reported to a person other than the one who sends a message to the list.
+
+
+
+Mockapetris                                                    [Page 49]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+New fields may be added to this RR in the future.
+
+
+9. REFERENCES and BIBLIOGRAPHY
+
+[Dyer 87]       S. Dyer, F. Hsu, "Hesiod", Project Athena
+                Technical Plan - Name Service, April 1987, version 1.9.
+
+                Describes the fundamentals of the Hesiod name service.
+
+[IEN-116]       J. Postel, "Internet Name Server", IEN-116,
+                USC/Information Sciences Institute, August 1979.
+
+                A name service obsoleted by the Domain Name System, but
+                still in use.
+
+[Quarterman 86] J. Quarterman, and J. Hoskins, "Notable Computer Networks",
+                Communications of the ACM, October 1986, volume 29, number
+                10.
+
+[RFC-742]       K. Harrenstien, "NAME/FINGER", RFC-742, Network
+                Information Center, SRI International, December 1977.
+
+[RFC-768]       J. Postel, "User Datagram Protocol", RFC-768,
+                USC/Information Sciences Institute, August 1980.
+
+[RFC-793]       J. Postel, "Transmission Control Protocol", RFC-793,
+                USC/Information Sciences Institute, September 1981.
+
+[RFC-799]       D. Mills, "Internet Name Domains", RFC-799, COMSAT,
+                September 1981.
+
+                Suggests introduction of a hierarchy in place of a flat
+                name space for the Internet.
+
+[RFC-805]       J. Postel, "Computer Mail Meeting Notes", RFC-805,
+                USC/Information Sciences Institute, February 1982.
+
+[RFC-810]       E. Feinler, K. Harrenstien, Z. Su, and V. White, "DOD
+                Internet Host Table Specification", RFC-810, Network
+                Information Center, SRI International, March 1982.
+
+                Obsolete.  See RFC-952.
+
+[RFC-811]       K. Harrenstien, V. White, and E. Feinler, "Hostnames
+                Server", RFC-811, Network Information Center, SRI
+                International, March 1982.
+
+
+
+
+Mockapetris                                                    [Page 50]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+                Obsolete.  See RFC-953.
+
+[RFC-812]       K. Harrenstien, and V. White, "NICNAME/WHOIS", RFC-812,
+                Network Information Center, SRI International, March
+                1982.
+
+[RFC-819]       Z. Su, and J. Postel, "The Domain Naming Convention for
+                Internet User Applications", RFC-819, Network
+                Information Center, SRI International, August 1982.
+
+                Early thoughts on the design of the domain system.
+                Current implementation is completely different.
+
+[RFC-821]       J. Postel, "Simple Mail Transfer Protocol", RFC-821,
+                USC/Information Sciences Institute, August 1980.
+
+[RFC-830]       Z. Su, "A Distributed System for Internet Name Service",
+                RFC-830, Network Information Center, SRI International,
+                October 1982.
+
+                Early thoughts on the design of the domain system.
+                Current implementation is completely different.
+
+[RFC-882]       P. Mockapetris, "Domain names - Concepts and
+                Facilities," RFC-882, USC/Information Sciences
+                Institute, November 1983.
+
+                Superceeded by this memo.
+
+[RFC-883]       P. Mockapetris, "Domain names - Implementation and
+                Specification," RFC-883, USC/Information Sciences
+                Institute, November 1983.
+
+                Superceeded by this memo.
+
+[RFC-920]       J. Postel and J. Reynolds, "Domain Requirements",
+                RFC-920, USC/Information Sciences Institute,
+                October 1984.
+
+                Explains the naming scheme for top level domains.
+
+[RFC-952]       K. Harrenstien, M. Stahl, E. Feinler, "DoD Internet Host
+                Table Specification", RFC-952, SRI, October 1985.
+
+                Specifies the format of HOSTS.TXT, the host/address
+                table replaced by the DNS.
+
+
+
+
+
+Mockapetris                                                    [Page 51]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+[RFC-953]       K. Harrenstien, M. Stahl, E. Feinler, "HOSTNAME Server",
+                RFC-953, SRI, October 1985.
+
+                This RFC contains the official specification of the
+                hostname server protocol, which is obsoleted by the DNS.
+                This TCP based protocol accesses information stored in
+                the RFC-952 format, and is used to obtain copies of the
+                host table.
+
+[RFC-973]       P. Mockapetris, "Domain System Changes and
+                Observations", RFC-973, USC/Information Sciences
+                Institute, January 1986.
+
+                Describes changes to RFC-882 and RFC-883 and reasons for
+                them.
+
+[RFC-974]       C. Partridge, "Mail routing and the domain system",
+                RFC-974, CSNET CIC BBN Labs, January 1986.
+
+                Describes the transition from HOSTS.TXT based mail
+                addressing to the more powerful MX system used with the
+                domain system.
+
+[RFC-1001]      NetBIOS Working Group, "Protocol standard for a NetBIOS
+                service on a TCP/UDP transport: Concepts and Methods",
+                RFC-1001, March 1987.
+
+                This RFC and RFC-1002 are a preliminary design for
+                NETBIOS on top of TCP/IP which proposes to base NetBIOS
+                name service on top of the DNS.
+
+[RFC-1002]      NetBIOS Working Group, "Protocol standard for a NetBIOS
+                service on a TCP/UDP transport: Detailed
+                Specifications", RFC-1002, March 1987.
+
+[RFC-1010]      J. Reynolds, and J. Postel, "Assigned Numbers", RFC-1010,
+                USC/Information Sciences Institute, May 1987.
+
+                Contains socket numbers and mnemonics for host names,
+                operating systems, etc.
+
+[RFC-1031]      W. Lazear, "MILNET Name Domain Transition", RFC-1031,
+                November 1987.
+
+                Describes a plan for converting the MILNET to the DNS.
+
+[RFC-1032]      M. Stahl, "Establishing a Domain - Guidelines for
+                Administrators", RFC-1032, November 1987.
+
+
+
+Mockapetris                                                    [Page 52]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+                Describes the registration policies used by the NIC to
+                administer the top level domains and delegate subzones.
+
+[RFC-1033]      M. Lottor, "Domain Administrators Operations Guide",
+                RFC-1033, November 1987.
+
+                A cookbook for domain administrators.
+
+[Solomon 82]    M. Solomon, L. Landweber, and D. Neuhengen, "The CSNET
+                Name Server", Computer Networks, vol 6, nr 3, July 1982.
+
+                Describes a name service for CSNET which is independent
+                from the DNS and DNS use in the CSNET.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mockapetris                                                    [Page 53]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+Index
+
+          *   13
+
+          ;   33, 35
+
+          <character-string>   35
+          <domain-name>   34
+
+          @   35
+
+          \   35
+
+          A   12
+
+          Byte order   8
+
+          CH   13
+          Character case   9
+          CLASS   11
+          CNAME   12
+          Completion   42
+          CS   13
+
+          Hesiod   13
+          HINFO   12
+          HS   13
+
+          IN   13
+          IN-ADDR.ARPA domain   22
+          Inverse queries   40
+
+          Mailbox names   47
+          MB   12
+          MD   12
+          MF   12
+          MG   12
+          MINFO   12
+          MINIMUM   20
+          MR   12
+          MX   12
+
+          NS   12
+          NULL   12
+
+          Port numbers   32
+          Primary server   5
+          PTR   12, 18
+
+
+
+Mockapetris                                                    [Page 54]
+
+RFC 1035        Domain Implementation and Specification    November 1987
+
+
+          QCLASS   13
+          QTYPE   12
+
+          RDATA   12
+          RDLENGTH  11
+
+          Secondary server   5
+          SOA   12
+          Stub resolvers   7
+
+          TCP   32
+          TXT   12
+          TYPE   11
+
+          UDP   32
+
+          WKS   12
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mockapetris                                                    [Page 55]
+
diff --git a/doc/rfc/rfc1101.txt b/doc/rfc/rfc1101.txt
new file mode 100644
index 0000000..66c9d8b
--- /dev/null
+++ b/doc/rfc/rfc1101.txt
@@ -0,0 +1,787 @@
+
+
+
+
+
+
+Network Working Group                                     P. Mockapetris
+Request for Comments: 1101                                           ISI
+Updates: RFCs 1034, 1035                                      April 1989
+
+
+             DNS Encoding of Network Names and Other Types
+
+
+1. STATUS OF THIS MEMO
+
+   This RFC proposes two extensions to the Domain Name System:
+
+      - A specific method for entering and retrieving RRs which map
+        between network names and numbers.
+
+      - Ideas for a general method for describing mappings between
+        arbitrary identifiers and numbers.
+
+   The method for mapping between network names and addresses is a
+   proposed standard, the ideas for a general method are experimental.
+
+   This RFC assumes that the reader is familiar with the DNS [RFC 1034,
+   RFC 1035] and its use.  The data shown is for pedagogical use and
+   does not necessarily reflect the real Internet.
+
+   Distribution of this memo is unlimited.
+
+2. INTRODUCTION
+
+   The DNS is extensible and can be used for a virtually unlimited
+   number of data types, name spaces, etc.  New type definitions are
+   occasionally necessary as are revisions or deletions of old types
+   (e.g., MX replacement of MD and MF [RFC 974]), and changes described
+   in [RFC 973].  This RFC describes changes due to the general need to
+   map between identifiers and values, and a specific need for network
+   name support.
+
+   Users wish to be able to use the DNS to map between network names and
+   numbers.  This need is the only capability found in HOSTS.TXT which
+   is not available from the DNS.  In designing a method to do this,
+   there were two major areas of concern:
+
+      - Several tradeoffs involving control of network names, the
+        syntax of network names, backward compatibility, etc.
+
+      - A desire to create a method which would be sufficiently
+        general to set a good precedent for future mappings,
+        for example, between TCP-port names and numbers,
+
+
+
+Mockapetris                                                     [Page 1]
+
+RFC 1101     DNS Encoding of Network Names and Other Types    April 1989
+
+
+        autonomous system names and numbers, X.500 Relative
+        Distinguished Names (RDNs) and their servers, or whatever.
+
+   It was impossible to reconcile these two areas of concern for network
+   names because of the desire to unify network number support within
+   existing IP address to host name support.  The existing support is
+   the IN-ADDR.ARPA section of the DNS name space.  As a result this RFC
+   describes one structure for network names which builds on the
+   existing support for host names, and another family of structures for
+   future yellow pages (YP) functions such as conversions between TCP-
+   port numbers and mnemonics.
+
+   Both structures are described in following sections.  Each structure
+   has a discussion of design issues and specific structure
+   recommendations.
+
+   We wish to avoid defining structures and methods which can work but
+   do not because of indifference or errors on the part of system
+   administrators when maintaining the database.  The WKS RR is an
+   example.  Thus, while we favor distribution as a general method, we
+   also recognize that centrally maintained tables (such as HOSTS.TXT)
+   are usually more consistent though less maintainable and timely.
+   Hence we recommend both specific methods for mapping network names,
+   addresses, and subnets, as well as an instance of the general method
+   for mapping between allocated network numbers and network names.
+   (Allocation is centrally performed by the SRI Network Information
+   Center, aka the NIC).
+
+3. NETWORK NAME ISSUES AND DISCUSSION
+
+   The issues involved in the design were the definition of network name
+   syntax, the mappings to be provided, and possible support for similar
+   functions at the subnet level.
+
+3.1. Network name syntax
+
+   The current syntax for network names, as defined by [RFC 952] is an
+   alphanumeric string of up to 24 characters, which begins with an
+   alpha, and may include "." and "-" except as first and last
+   characters.  This is the format which was also used for host names
+   before the DNS.  Upward compatibility with existing names might be a
+   goal of any new scheme.
+
+   However, the present syntax has been used to define a flat name
+   space, and hence would prohibit the same distributed name allocation
+   method used for host names.  There is some sentiment for allowing the
+   NIC to continue to allocate and regulate network names, much as it
+   allocates numbers, but the majority opinion favors local control of
+
+
+
+Mockapetris                                                     [Page 2]
+
+RFC 1101     DNS Encoding of Network Names and Other Types    April 1989
+
+
+   network names.  Although it would be possible to provide a flat space
+   or a name space in which, for example, the last label of a domain
+   name captured the old-style network name, any such approach would add
+   complexity to the method and create different rules for network names
+   and host names.
+
+   For these reasons, we assume that the syntax of network names will be
+   the same as the expanded syntax for host names permitted in [HR].
+   The new syntax expands the set of names to allow leading digits, so
+   long as the resulting representations do not conflict with IP
+   addresses in decimal octet form.  For example, 3Com.COM and 3M.COM
+   are now legal, although 26.0.0.73.COM is not.  See [HR] for details.
+
+   The price is that network names will get as complicated as host
+   names.  An administrator will be able to create network names in any
+   domain under his control, and also create network number to name
+   entries in IN-ADDR.ARPA domains under his control.  Thus, the name
+   for the ARPANET might become NET.ARPA, ARPANET.ARPA or Arpa-
+   network.MIL., depending on the preferences of the owner.
+
+3.2. Mappings
+
+   The desired mappings, ranked by priority with most important first,
+   are:
+
+      - Mapping a IP address or network number to a network name.
+
+        This mapping is for use in debugging tools and status displays
+        of various sorts.  The conversion from IP address to network
+        number is well known for class A, B, and C IP addresses, and
+        involves a simple mask operation.  The needs of other classes
+        are not yet defined and are ignored for the rest of this RFC.
+
+      - Mapping a network name to a network address.
+
+        This facility is of less obvious application, but a
+        symmetrical mapping seems desirable.
+
+      - Mapping an organization to its network names and numbers.
+
+        This facility is useful because it may not always be possible
+        to guess the local choice for network names, but the
+        organization name is often well known.
+
+      - Similar mappings for subnets, even when nested.
+
+        The primary application is to be able to identify all of the
+        subnets involved in a particular IP address.  A secondary
+
+
+
+Mockapetris                                                     [Page 3]
+
+RFC 1101     DNS Encoding of Network Names and Other Types    April 1989
+
+
+        requirement is to retrieve address mask information.
+
+3.3. Network address section of the name space
+
+   The network name syntax discussed above can provide domain names
+   which will contain mappings from network names to various quantities,
+   but we also need a section of the name space, organized by network
+   and subnet number to hold the inverse mappings.
+
+   The choices include:
+
+      - The same network number slots already assigned and delegated
+        in the IN-ADDR.ARPA section of the name space.
+
+        For example, 10.IN-ADDR.ARPA for class A net 10,
+        2.128.IN-ADDR.ARPA for class B net 128.2, etc.
+
+      - Host-zero addresses in the IN-ADDR.ARPA tree.  (A host field
+        of all zero in an IP address is prohibited because of
+        confusion related to broadcast addresses, et al.)
+
+        For example, 0.0.0.10.IN-ADDR.ARPA for class A net 10,
+        0.0.2.128.IN-ADDR.arpa for class B net 128.2, etc.  Like the
+        first scheme, it uses in-place name space delegations to
+        distribute control.
+
+        The main advantage of this scheme over the first is that it
+        allows convenient names for subnets as well as networks.  A
+        secondary advantage is that it uses names which are not in use
+        already, and hence it is possible to test whether an
+        organization has entered this information in its domain
+        database.
+
+      - Some new section of the name space.
+
+        While this option provides the most opportunities, it creates
+        a need to delegate a whole new name space.  Since the IP
+        address space is so closely related to the network number
+        space, most believe that the overhead of creating such a new
+        space is overwhelming and would lead to the WKS syndrome.  (As
+        of February, 1989, approximately 400 sections of the
+        IN-ADDR.ARPA tree are already delegated, usually at network
+        boundaries.)
+
+
+
+
+
+
+
+
+Mockapetris                                                     [Page 4]
+
+RFC 1101     DNS Encoding of Network Names and Other Types    April 1989
+
+
+4. SPECIFICS FOR NETWORK NAME MAPPINGS
+
+   The proposed solution uses information stored at:
+
+      - Names in the IN-ADDR.ARPA tree that correspond to host-zero IP
+        addresses.  The same method is used for subnets in a nested
+        fashion.  For example, 0.0.0.10.IN-ADDR.ARPA. for net 10.
+
+        Two types of information are stored here: PTR RRs which point
+        to the network name in their data sections, and A RRs, which
+        are present if the network (or subnet) is subnetted further.
+        If a type A RR is present, then it has the address mask as its
+        data.  The general form is:
+
+        <reversed-host-zero-number>.IN-ADDR.ARPA. PTR <network-name>
+        <reversed-host-zero-number>.IN-ADDR.ARPA. A   <subnet-mask>
+
+        For example:
+
+        0.0.0.10.IN-ADDR.ARPA.  PTR     ARPANET.ARPA.
+
+        or
+
+        0.0.2.128.IN-ADDR.ARPA. PTR     cmu-net.cmu.edu.
+                                A       255.255.255.0
+
+        In general, this information will be added to an existing
+        master file for some IN-ADDR.ARPA domain for each network
+        involved.  Similar RRs can be used at host-zero subnet
+        entries.
+
+      - Names which are network names.
+
+        The data stored here is PTR RRs pointing at the host-zero
+        entries.  The general form is:
+
+        <network-name> ptr <reversed-host-zero-number>.IN-ADDR.ARPA
+
+        For example:
+
+        ARPANET.ARPA.           PTR     0.0.0.10.IN-ADDR.ARPA.
+
+        or
+
+        isi-net.isi.edu.        PTR     0.0.9.128.IN-ADDR.ARPA.
+
+        In general, this information will be inserted in the master
+        file for the domain name of the organization; this is a
+
+
+
+Mockapetris                                                     [Page 5]
+
+RFC 1101     DNS Encoding of Network Names and Other Types    April 1989
+
+
+        different file from that which holds the information below
+        IN-ADDR.ARPA.  Similar PTR RRs can be used at subnet names.
+
+      - Names corresponding to organizations.
+
+        The data here is one or more PTR RRs pointing at the
+        IN-ADDR.ARPA names corresponding to host-zero entries for
+        networks.
+
+        For example:
+
+        ISI.EDU.        PTR     0.0.9.128.IN-ADDR.ARPA.
+
+        MCC.COM.        PTR     0.167.5.192.IN-ADDR.ARPA.
+                        PTR     0.168.5.192.IN-ADDR.ARPA.
+                        PTR     0.169.5.192.IN-ADDR.ARPA.
+                        PTR     0.0.62.128.IN-ADDR.ARPA.
+
+4.1. A simple example
+
+   The ARPANET is a Class A network without subnets.  The RRs which
+   would be added, assuming the ARPANET.ARPA was selected as a network
+   name, would be:
+
+   ARPA.                   PTR     0.0.0.10.IN-ADDR.ARPA.
+
+   ARPANET.ARPA.           PTR     0.0.0.10.IN-ADDR.ARPA.
+
+   0.0.0.10.IN-ADDR.ARPA.  PTR     ARPANET.ARPA.
+
+   The first RR states that the organization named ARPA owns net 10 (It
+   might also own more network numbers, and these would be represented
+   with an additional RR per net.)  The second states that the network
+   name ARPANET.ARPA. maps to net 10.  The last states that net 10 is
+   named ARPANET.ARPA.
+
+   Note that all of the usual host and corresponding IN-ADDR.ARPA
+   entries would still be required.
+
+4.2. A complicated, subnetted example
+
+   The ISI network is 128.9, a class B number.  Suppose the ISI network
+   was organized into two levels of subnet, with the first level using
+   an additional 8 bits of address, and the second level using 4 bits,
+   for address masks of x'FFFFFF00' and X'FFFFFFF0'.
+
+   Then the following RRs would be entered in ISI's master file for the
+   ISI.EDU zone:
+
+
+
+Mockapetris                                                     [Page 6]
+
+RFC 1101     DNS Encoding of Network Names and Other Types    April 1989
+
+
+   ; Define network entry
+   isi-net.isi.edu.                PTR  0.0.9.128.IN-ADDR.ARPA.
+
+   ; Define first level subnets
+   div1-subnet.isi.edu.            PTR  0.1.9.128.IN-ADDR.ARPA.
+   div2-subnet.isi.edu.            PTR  0.2.9.128.IN-ADDR.ARPA.
+
+   ; Define second level subnets
+   inc-subsubnet.isi.edu.          PTR  16.2.9.128.IN-ADDR.ARPA.
+
+   in the 9.128.IN-ADDR.ARPA zone:
+
+   ; Define network number and address mask
+   0.0.9.128.IN-ADDR.ARPA.         PTR  isi-net.isi.edu.
+                                   A    255.255.255.0  ;aka X'FFFFFF00'
+
+   ; Define one of the first level subnet numbers and masks
+   0.1.9.128.IN-ADDR.ARPA.         PTR  div1-subnet.isi.edu.
+                                   A    255.255.255.240 ;aka X'FFFFFFF0'
+
+   ; Define another first level subnet number and mask
+   0.2.9.128.IN-ADDR.ARPA.         PTR  div2-subnet.isi.edu.
+                                   A    255.255.255.240 ;aka X'FFFFFFF0'
+
+   ; Define second level subnet number
+   16.2.9.128.IN-ADDR.ARPA.        PTR  inc-subsubnet.isi.edu.
+
+   This assumes that the ISI network is named isi-net.isi.edu., first
+   level subnets are named div1-subnet.isi.edu. and div2-
+   subnet.isi.edu., and a second level subnet is called inc-
+   subsubnet.isi.edu.  (In a real system as complicated as this there
+   would be more first and second level subnets defined, but we have
+   shown enough to illustrate the ideas.)
+
+4.3. Procedure for using an IP address to get network name
+
+   Depending on whether the IP address is class A, B, or C, mask off the
+   high one, two, or three bytes, respectively.  Reverse the octets,
+   suffix IN-ADDR.ARPA, and do a PTR query.
+
+   For example, suppose the IP address is 10.0.0.51.
+
+      1. Since this is a class A address, use a mask x'FF000000' and
+         get 10.0.0.0.
+
+      2. Construct the name 0.0.0.10.IN-ADDR.ARPA.
+
+      3. Do a PTR query.  Get back
+
+
+
+Mockapetris                                                     [Page 7]
+
+RFC 1101     DNS Encoding of Network Names and Other Types    April 1989
+
+
+         0.0.0.10.IN-ADDR.ARPA.  PTR     ARPANET.ARPA.
+
+      4. Conclude that the network name is "ARPANET.ARPA."
+
+   Suppose that the IP address is 128.9.2.17.
+
+      1. Since this is a class B address, use a mask of x'FFFF0000'
+         and get 128.9.0.0.
+
+      2. Construct the name 0.0.9.128.IN-ADDR.ARPA.
+
+      3. Do a PTR query.  Get back
+
+         0.0.9.128.IN-ADDR.ARPA.       PTR     isi-net.isi.edu
+
+      4. Conclude that the network name is "isi-net.isi.edu."
+
+4.4. Procedure for finding all subnets involved with an IP address
+
+   This is a simple extension of the IP address to network name method.
+   When the network entry is located, do a lookup for a possible A RR.
+   If the A RR is found, look up the next level of subnet using the
+   original IP address and the mask in the A RR.  Repeat this procedure
+   until no A RR is found.
+
+   For example, repeating the use of 128.9.2.17.
+
+      1. As before construct a query for 0.0.9.128.IN-ADDR.ARPA.
+         Retrieve:
+
+         0.0.9.128.IN-ADDR.ARPA.  PTR    isi-net.isi.edu.
+                                  A      255.255.255.0
+
+      2. Since an A RR was found, repeat using mask from RR
+         (255.255.255.0), constructing a query for
+         0.2.9.128.IN-ADDR.ARPA.  Retrieve:
+
+         0.2.9.128.IN-ADDR.ARPA.  PTR    div2-subnet.isi.edu.
+                                  A      255.255.255.240
+
+      3. Since another A RR was found, repeat using mask
+         255.255.255.240 (x'FFFFFFF0').  constructing a query for
+         16.2.9.128.IN-ADDR.ARPA.  Retrieve:
+
+         16.2.9.128.IN-ADDR.ARPA. PTR    inc-subsubnet.isi.edu.
+
+      4. Since no A RR is present at 16.2.9.128.IN-ADDR.ARPA., there
+         are no more subnet levels.
+
+
+
+Mockapetris                                                     [Page 8]
+
+RFC 1101     DNS Encoding of Network Names and Other Types    April 1989
+
+
+5. YP ISSUES AND DISCUSSION
+
+   The term "Yellow Pages" is used in almost as many ways as the term
+   "domain", so it is useful to define what is meant herein by YP.  The
+   general problem to be solved is to create a method for creating
+   mappings from one kind of identifier to another, often with an
+   inverse capability.  The traditional methods are to search or use a
+   precomputed index of some kind.
+
+   Searching is impractical when the search is too large, and
+   precomputed indexes are possible only when it is possible to specify
+   search criteria in advance, and pay for the resources necessary to
+   build the index.  For example, it is impractical to search the entire
+   domain tree to find a particular address RR, so we build the IN-
+   ADDR.ARPA YP.  Similarly, we could never build an Internet-wide index
+   of "hosts with a load average of less than 2" in less time than it
+   would take for the data to change, so indexes are a useless approach
+   for that problem.
+
+   Such a precomputed index is what we mean by YP, and we regard the
+   IN-ADDR.ARPA domain as the first instance of a YP in the DNS.
+   Although a single, centrally-managed YP for well-known values such as
+   TCP-port is desirable, we regard organization-specific YPs for, say,
+   locally defined TCP ports as a natural extension, as are combinations
+   of YPs using search lists to merge the two.
+
+   In examining Internet Numbers [RFC 997] and Assigned Numbers [RFC
+   1010], it is clear that there are several mappings which might be of
+   value.  For example:
+
+   <assigned-network-name> <==> <IP-address>
+   <autonomous-system-id>  <==> <number>
+   <protocol-id>           <==> <number>
+   <port-id>               <==> <number>
+   <ethernet-type>         <==> <number>
+   <public-data-net>       <==> <IP-address>
+
+   Following the IN-ADDR example, the YP takes the form of a domain tree
+   organized to optimize retrieval by search key and distribution via
+   normal DNS rules.  The name used as a key must include:
+
+      1. A well known origin.  For example, IN-ADDR.ARPA is the
+         current IP-address to host name YP.
+
+      2. A "from" data type.  This identifies the input type of the
+         mapping.  This is necessary because we may be mapping
+         something as anonymous as a number to any number of
+         mnemonics, etc.
+
+
+
+Mockapetris                                                     [Page 9]
+
+RFC 1101     DNS Encoding of Network Names and Other Types    April 1989
+
+
+      3. A "to" data type.  Since we assume several symmetrical
+         mnemonic <==> number mappings, this is also necessary.
+
+   This ordering reflects the natural scoping of control, and hence the
+   order of the components in a domain name.  Thus domain names would be
+   of the form:
+
+   <from-value>.<to-data-type>.<from-data-type>.<YP-origin>
+
+   To make this work, we need to define well-know strings for each of
+   these metavariables, as well as encoding rules for converting a
+   <from-value> into a domain name.  We might define:
+
+   <YP-origin>     :=YP
+   <from-data-type>:=TCP-port | IN-ADDR | Number |
+                     Assigned-network-number | Name
+   <to-data-type>  :=<from-data-type>
+
+   Note that "YP" is NOT a valid country code under [ISO 3166] (although
+   we may want to worry about the future), and the existence of a
+   syntactically valid <to-data-type>.<from-data-type> pair does not
+   imply that a meaningful mapping exists, or is even possible.
+
+   The encoding rules might be:
+
+   TCP-port        Six character alphanumeric
+
+   IN-ADDR         Reversed 4-octet decimal string
+
+   Number          decimal integer
+
+   Assigned-network-number
+                   Reversed 4-octet decimal string
+
+   Name            Domain name
+
+6. SPECIFICS FOR YP MAPPINGS
+
+6.1. TCP-PORT
+
+   $origin Number.TCP-port.YP.
+
+   23              PTR     TELNET.TCP-port.Number.YP.
+   25              PTR     SMTP.TCP-port.Number.YP.
+
+   $origin TCP-port.Number.YP.
+
+   TELNET          PTR     23.Number.TCP-port.YP.
+
+
+
+Mockapetris                                                    [Page 10]
+
+RFC 1101     DNS Encoding of Network Names and Other Types    April 1989
+
+
+   SMTP            PTR     25.Number.TCP-port.YP.
+
+   Thus the mapping between 23 and TELNET is represented by a pair of
+   PTR RRs, one for each direction of the mapping.
+
+6.2. Assigned networks
+
+   Network numbers are assigned by the NIC and reported in "Internet
+   Numbers" RFCs.  To create a YP, the NIC would set up two domains:
+
+   Name.Assigned-network-number.YP and Assigned-network-number.YP
+
+   The first would contain entries of the form:
+
+   $origin Name.Assigned-network-number.YP.
+
+   0.0.0.4         PTR     SATNET.Assigned-network-number.Name.YP.
+   0.0.0.10        PTR     ARPANET.Assigned-network-number.Name.YP.
+
+   The second would contain entries of the form:
+
+   $origin Assigned-network-number.Name.YP.
+
+   SATNET.         PTR     0.0.0.4.Name.Assigned-network-number.YP.
+   ARPANET.        PTR     0.0.0.10.Name.Assigned-network-number.YP.
+
+   These YPs are not in conflict with the network name support described
+   in the first half of this RFC since they map between ASSIGNED network
+   names and numbers, not those allocated by the organizations
+   themselves.  That is, they document the NIC's decisions about
+   allocating network numbers but do not automatically track any
+   renaming performed by the new owners.
+
+   As a practical matter, we might want to create both of these domains
+   to enable users on the Internet to experiment with centrally
+   maintained support as well as the distributed version, or might want
+   to implement only the allocated number to name mapping and request
+   organizations to convert their allocated network names to the network
+   names described in the distributed model.
+
+6.3. Operational improvements
+
+   We could imagine that all conversion routines using these YPs might
+   be instructed to use "YP.<local-domain>" followed by "YP."  as a
+   search list.  Thus, if the organization ISI.EDU wished to define
+   locally meaningful TCP-PORT, it would define the domains:
+
+   <TCP-port.Number.YP.ISI.EDU> and <Number.TCP-port.YP.ISI.EDU>.
+
+
+
+Mockapetris                                                    [Page 11]
+
+RFC 1101     DNS Encoding of Network Names and Other Types    April 1989
+
+
+   We could add another level of indirection in the YP lookup, defining
+   the <to-data-type>.<from-data-type>.<YP-origin> nodes to point to the
+   YP tree, rather than being the YP tree directly.  This would enable
+   entries of the form:
+
+   IN-ADDR.Netname.YP.   PTR     IN-ADDR.ARPA.
+
+   to splice in YPs from other origins or existing spaces.
+
+   Another possibility would be to shorten the RDATA section of the RRs
+   which map back and forth by deleting the origin.  This could be done
+   either by allowing the domain name in the RDATA portion to not
+   identify a real domain name, or by defining a new RR which used a
+   simple text string rather than a domain name.
+
+   Thus, we might replace
+
+   $origin Assigned-network-number.Name.YP.
+
+   SATNET.         PTR     0.0.0.4.Name.Assigned-network-number.YP.
+   ARPANET.        PTR     0.0.0.10.Name.Assigned-network-number.YP.
+
+   with
+
+   $origin Assigned-network-number.Name.YP.
+
+   SATNET.         PTR     0.0.0.4.
+   ARPANET.        PTR     0.0.0.10.
+
+   or
+
+   $origin Assigned-network-number.Name.YP.
+
+   SATNET.         PTT     "0.0.0.4"
+   ARPANET.        PTT     "0.0.0.10"
+
+   where PTT is a new type whose RDATA section is a text string.
+
+7. ACKNOWLEDGMENTS
+
+   Drew Perkins, Mark Lottor, and Rob Austein contributed several of the
+   ideas in this RFC.  Numerous contributions, criticisms, and
+   compromises were produced in the IETF Domain working group and the
+   NAMEDROPPERS mailing list.
+
+
+
+
+
+
+
+Mockapetris                                                    [Page 12]
+
+RFC 1101     DNS Encoding of Network Names and Other Types    April 1989
+
+
+8. REFERENCES
+
+   [HR]        Braden, B., editor, "Requirements for Internet Hosts",
+               RFC in preparation.
+
+   [ISO 3166]  ISO, "Codes for the Representation of Names of
+               Countries", 1981.
+
+   [RFC 882]   Mockapetris, P., "Domain names - Concepts and
+               Facilities", RFC 882, USC/Information Sciences Institute,
+               November 1983.
+
+               Superseded by RFC 1034.
+
+   [RFC 883]   Mockapetris, P.,"Domain names - Implementation and
+               Specification", RFC 883, USC/Information Sciences
+               Institute, November 1983.
+
+               Superceeded by RFC 1035.
+
+   [RFC 920]   Postel, J. and J. Reynolds, "Domain Requirements", RFC
+               920, October 1984.
+
+               Explains the naming scheme for top level domains.
+
+   [RFC 952]   Harrenstien, K., M. Stahl, and E. Feinler, "DoD Internet
+               Host Table Specification", RFC 952, SRI, October 1985.
+
+               Specifies the format of HOSTS.TXT, the host/address table
+               replaced by the DNS
+
+   [RFC 973]   Mockapetris, P., "Domain System Changes and
+               Observations", RFC 973, USC/Information Sciences
+               Institute, January 1986.
+
+               Describes changes to RFCs 882 and 883 and reasons for
+               them.
+
+   [RFC 974]   Partridge, C., "Mail routing and the domain system", RFC
+               974, CSNET CIC BBN Labs, January 1986.
+
+               Describes the transition from HOSTS.TXT based mail
+               addressing to the more powerful MX system used with the
+               domain system.
+
+
+
+
+
+
+
+Mockapetris                                                    [Page 13]
+
+RFC 1101     DNS Encoding of Network Names and Other Types    April 1989
+
+
+   [RFC 997]   Reynolds, J., and J. Postel, "Internet Numbers", RFC 997,
+               USC/Information Sciences Institute, March 1987
+
+               Contains network numbers, autonomous system numbers, etc.
+
+   [RFC 1010]  Reynolds, J., and J. Postel, "Assigned Numbers", RFC
+               1010, USC/Information Sciences Institute, May 1987
+
+               Contains socket numbers and mnemonics for host names,
+               operating systems, etc.
+
+
+   [RFC 1034]  Mockapetris, P., "Domain names - Concepts and
+               Facilities", RFC 1034, USC/Information Sciences
+               Institute, November 1987.
+
+               Introduction/overview of the DNS.
+
+   [RFC 1035]  Mockapetris, P., "Domain names - Implementation and
+               Specification", RFC 1035, USC/Information Sciences
+               Institute, November 1987.
+
+               DNS implementation instructions.
+
+Author's Address:
+
+   Paul Mockapetris
+   USC/Information Sciences Institute
+   4676 Admiralty Way
+   Marina del Rey, CA 90292
+
+   Phone: (213) 822-1511
+
+   Email: PVM@ISI.EDU
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mockapetris                                                    [Page 14]
+
\ No newline at end of file
diff --git a/doc/rfc/rfc1122.txt b/doc/rfc/rfc1122.txt
new file mode 100644
index 0000000..c14f2e5
--- /dev/null
+++ b/doc/rfc/rfc1122.txt
@@ -0,0 +1,6844 @@
+
+
+
+
+
+
+Network Working Group                    Internet Engineering Task Force
+Request for Comments: 1122                             R. Braden, Editor
+                                                            October 1989
+
+
+        Requirements for Internet Hosts -- Communication Layers
+
+
+Status of This Memo
+
+   This RFC is an official specification for the Internet community.  It
+   incorporates by reference, amends, corrects, and supplements the
+   primary protocol standards documents relating to hosts.  Distribution
+   of this document is unlimited.
+
+Summary
+
+   This is one RFC of a pair that defines and discusses the requirements
+   for Internet host software.  This RFC covers the communications
+   protocol layers: link layer, IP layer, and transport layer; its
+   companion RFC-1123 covers the application and support protocols.
+
+
+
+                           Table of Contents
+
+
+
+
+   1.  INTRODUCTION ...............................................    5
+      1.1  The Internet Architecture ..............................    6
+         1.1.1  Internet Hosts ....................................    6
+         1.1.2  Architectural Assumptions .........................    7
+         1.1.3  Internet Protocol Suite ...........................    8
+         1.1.4  Embedded Gateway Code .............................   10
+      1.2  General Considerations .................................   12
+         1.2.1  Continuing Internet Evolution .....................   12
+         1.2.2  Robustness Principle ..............................   12
+         1.2.3  Error Logging .....................................   13
+         1.2.4  Configuration .....................................   14
+      1.3  Reading this Document ..................................   15
+         1.3.1  Organization ......................................   15
+         1.3.2  Requirements ......................................   16
+         1.3.3  Terminology .......................................   17
+      1.4  Acknowledgments ........................................   20
+
+   2. LINK LAYER ..................................................   21
+      2.1  INTRODUCTION ...........................................   21
+
+
+
+Internet Engineering Task Force                                 [Page 1]
+
+
+
+
+RFC1122                       INTRODUCTION                  October 1989
+
+
+      2.2  PROTOCOL WALK-THROUGH ..................................   21
+      2.3  SPECIFIC ISSUES ........................................   21
+         2.3.1  Trailer Protocol Negotiation ......................   21
+         2.3.2  Address Resolution Protocol -- ARP ................   22
+            2.3.2.1  ARP Cache Validation .........................   22
+            2.3.2.2  ARP Packet Queue .............................   24
+         2.3.3  Ethernet and IEEE 802 Encapsulation ...............   24
+      2.4  LINK/INTERNET LAYER INTERFACE ..........................   25
+      2.5  LINK LAYER REQUIREMENTS SUMMARY ........................   26
+
+   3. INTERNET LAYER PROTOCOLS ....................................   27
+      3.1 INTRODUCTION ............................................   27
+      3.2  PROTOCOL WALK-THROUGH ..................................   29
+         3.2.1 Internet Protocol -- IP ............................   29
+            3.2.1.1  Version Number ...............................   29
+            3.2.1.2  Checksum .....................................   29
+            3.2.1.3  Addressing ...................................   29
+            3.2.1.4  Fragmentation and Reassembly .................   32
+            3.2.1.5  Identification ...............................   32
+            3.2.1.6  Type-of-Service ..............................   33
+            3.2.1.7  Time-to-Live .................................   34
+            3.2.1.8  Options ......................................   35
+         3.2.2 Internet Control Message Protocol -- ICMP ..........   38
+            3.2.2.1  Destination Unreachable ......................   39
+            3.2.2.2  Redirect .....................................   40
+            3.2.2.3  Source Quench ................................   41
+            3.2.2.4  Time Exceeded ................................   41
+            3.2.2.5  Parameter Problem ............................   42
+            3.2.2.6  Echo Request/Reply ...........................   42
+            3.2.2.7  Information Request/Reply ....................   43
+            3.2.2.8  Timestamp and Timestamp Reply ................   43
+            3.2.2.9  Address Mask Request/Reply ...................   45
+         3.2.3  Internet Group Management Protocol IGMP ...........   47
+      3.3  SPECIFIC ISSUES ........................................   47
+         3.3.1  Routing Outbound Datagrams ........................   47
+            3.3.1.1  Local/Remote Decision ........................   47
+            3.3.1.2  Gateway Selection ............................   48
+            3.3.1.3  Route Cache ..................................   49
+            3.3.1.4  Dead Gateway Detection .......................   51
+            3.3.1.5  New Gateway Selection ........................   55
+            3.3.1.6  Initialization ...............................   56
+         3.3.2  Reassembly ........................................   56
+         3.3.3  Fragmentation .....................................   58
+         3.3.4  Local Multihoming .................................   60
+            3.3.4.1  Introduction .................................   60
+            3.3.4.2  Multihoming Requirements .....................   61
+            3.3.4.3  Choosing a Source Address ....................   64
+         3.3.5  Source Route Forwarding ...........................   65
+
+
+
+Internet Engineering Task Force                                 [Page 2]
+
+
+
+
+RFC1122                       INTRODUCTION                  October 1989
+
+
+         3.3.6  Broadcasts ........................................   66
+         3.3.7  IP Multicasting ...................................   67
+         3.3.8  Error Reporting ...................................   69
+      3.4  INTERNET/TRANSPORT LAYER INTERFACE .....................   69
+      3.5  INTERNET LAYER REQUIREMENTS SUMMARY ....................   72
+
+   4. TRANSPORT PROTOCOLS .........................................   77
+      4.1  USER DATAGRAM PROTOCOL -- UDP ..........................   77
+         4.1.1  INTRODUCTION ......................................   77
+         4.1.2  PROTOCOL WALK-THROUGH .............................   77
+         4.1.3  SPECIFIC ISSUES ...................................   77
+            4.1.3.1  Ports ........................................   77
+            4.1.3.2  IP Options ...................................   77
+            4.1.3.3  ICMP Messages ................................   78
+            4.1.3.4  UDP Checksums ................................   78
+            4.1.3.5  UDP Multihoming ..............................   79
+            4.1.3.6  Invalid Addresses ............................   79
+         4.1.4  UDP/APPLICATION LAYER INTERFACE ...................   79
+         4.1.5  UDP REQUIREMENTS SUMMARY ..........................   80
+      4.2  TRANSMISSION CONTROL PROTOCOL -- TCP ...................   82
+         4.2.1  INTRODUCTION ......................................   82
+         4.2.2  PROTOCOL WALK-THROUGH .............................   82
+            4.2.2.1  Well-Known Ports .............................   82
+            4.2.2.2  Use of Push ..................................   82
+            4.2.2.3  Window Size ..................................   83
+            4.2.2.4  Urgent Pointer ...............................   84
+            4.2.2.5  TCP Options ..................................   85
+            4.2.2.6  Maximum Segment Size Option ..................   85
+            4.2.2.7  TCP Checksum .................................   86
+            4.2.2.8  TCP Connection State Diagram .................   86
+            4.2.2.9  Initial Sequence Number Selection ............   87
+            4.2.2.10  Simultaneous Open Attempts ..................   87
+            4.2.2.11  Recovery from Old Duplicate SYN .............   87
+            4.2.2.12  RST Segment .................................   87
+            4.2.2.13  Closing a Connection ........................   87
+            4.2.2.14  Data Communication ..........................   89
+            4.2.2.15  Retransmission Timeout ......................   90
+            4.2.2.16  Managing the Window .........................   91
+            4.2.2.17  Probing Zero Windows ........................   92
+            4.2.2.18  Passive OPEN Calls ..........................   92
+            4.2.2.19  Time to Live ................................   93
+            4.2.2.20  Event Processing ............................   93
+            4.2.2.21  Acknowledging Queued Segments ...............   94
+         4.2.3  SPECIFIC ISSUES ...................................   95
+            4.2.3.1  Retransmission Timeout Calculation ...........   95
+            4.2.3.2  When to Send an ACK Segment ..................   96
+            4.2.3.3  When to Send a Window Update .................   97
+            4.2.3.4  When to Send Data ............................   98
+
+
+
+Internet Engineering Task Force                                 [Page 3]
+
+
+
+
+RFC1122                       INTRODUCTION                  October 1989
+
+
+            4.2.3.5  TCP Connection Failures ......................  100
+            4.2.3.6  TCP Keep-Alives ..............................  101
+            4.2.3.7  TCP Multihoming ..............................  103
+            4.2.3.8  IP Options ...................................  103
+            4.2.3.9  ICMP Messages ................................  103
+            4.2.3.10  Remote Address Validation ...................  104
+            4.2.3.11  TCP Traffic Patterns ........................  104
+            4.2.3.12  Efficiency ..................................  105
+         4.2.4  TCP/APPLICATION LAYER INTERFACE ...................  106
+            4.2.4.1  Asynchronous Reports .........................  106
+            4.2.4.2  Type-of-Service ..............................  107
+            4.2.4.3  Flush Call ...................................  107
+            4.2.4.4  Multihoming ..................................  108
+         4.2.5  TCP REQUIREMENT SUMMARY ...........................  108
+
+   5.  REFERENCES .................................................  112
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Internet Engineering Task Force                                 [Page 4]
+
+
+
+
+RFC1122                       INTRODUCTION                  October 1989
+
+
+1.  INTRODUCTION
+
+   This document is one of a pair that defines and discusses the
+   requirements for host system implementations of the Internet protocol
+   suite.  This RFC covers the communication protocol layers:  link
+   layer, IP layer, and transport layer.  Its companion RFC,
+   "Requirements for Internet Hosts -- Application and Support"
+   [INTRO:1], covers the application layer protocols.  This document
+   should also be read in conjunction with "Requirements for Internet
+   Gateways" [INTRO:2].
+
+   These documents are intended to provide guidance for vendors,
+   implementors, and users of Internet communication software.  They
+   represent the consensus of a large body of technical experience and
+   wisdom, contributed by the members of the Internet research and
+   vendor communities.
+
+   This RFC enumerates standard protocols that a host connected to the
+   Internet must use, and it incorporates by reference the RFCs and
+   other documents describing the current specifications for these
+   protocols.  It corrects errors in the referenced documents and adds
+   additional discussion and guidance for an implementor.
+
+   For each protocol, this document also contains an explicit set of
+   requirements, recommendations, and options.  The reader must
+   understand that the list of requirements in this document is
+   incomplete by itself; the complete set of requirements for an
+   Internet host is primarily defined in the standard protocol
+   specification documents, with the corrections, amendments, and
+   supplements contained in this RFC.
+
+   A good-faith implementation of the protocols that was produced after
+   careful reading of the RFC's and with some interaction with the
+   Internet technical community, and that followed good communications
+   software engineering practices, should differ from the requirements
+   of this document in only minor ways.  Thus, in many cases, the
+   "requirements" in this RFC are already stated or implied in the
+   standard protocol documents, so that their inclusion here is, in a
+   sense, redundant.  However, they were included because some past
+   implementation has made the wrong choice, causing problems of
+   interoperability, performance, and/or robustness.
+
+   This document includes discussion and explanation of many of the
+   requirements and recommendations.  A simple list of requirements
+   would be dangerous, because:
+
+   o    Some required features are more important than others, and some
+        features are optional.
+
+
+
+Internet Engineering Task Force                                 [Page 5]
+
+
+
+
+RFC1122                       INTRODUCTION                  October 1989
+
+
+   o    There may be valid reasons why particular vendor products that
+        are designed for restricted contexts might choose to use
+        different specifications.
+
+   However, the specifications of this document must be followed to meet
+   the general goal of arbitrary host interoperation across the
+   diversity and complexity of the Internet system.  Although most
+   current implementations fail to meet these requirements in various
+   ways, some minor and some major, this specification is the ideal
+   towards which we need to move.
+
+   These requirements are based on the current level of Internet
+   architecture.  This document will be updated as required to provide
+   additional clarifications or to include additional information in
+   those areas in which specifications are still evolving.
+
+   This introductory section begins with a brief overview of the
+   Internet architecture as it relates to hosts, and then gives some
+   general advice to host software vendors.  Finally, there is some
+   guidance on reading the rest of the document and some terminology.
+
+   1.1  The Internet Architecture
+
+      General background and discussion on the Internet architecture and
+      supporting protocol suite can be found in the DDN Protocol
+      Handbook [INTRO:3]; for background see for example [INTRO:9],
+      [INTRO:10], and [INTRO:11].  Reference [INTRO:5] describes the
+      procedure for obtaining Internet protocol documents, while
+      [INTRO:6] contains a list of the numbers assigned within Internet
+      protocols.
+
+      1.1.1  Internet Hosts
+
+         A host computer, or simply "host," is the ultimate consumer of
+         communication services.  A host generally executes application
+         programs on behalf of user(s), employing network and/or
+         Internet communication services in support of this function.
+         An Internet host corresponds to the concept of an "End-System"
+         used in the OSI protocol suite [INTRO:13].
+
+         An Internet communication system consists of interconnected
+         packet networks supporting communication among host computers
+         using the Internet protocols.  The networks are interconnected
+         using packet-switching computers called "gateways" or "IP
+         routers" by the Internet community, and "Intermediate Systems"
+         by the OSI world [INTRO:13].  The RFC "Requirements for
+         Internet Gateways" [INTRO:2] contains the official
+         specifications for Internet gateways.  That RFC together with
+
+
+
+Internet Engineering Task Force                                 [Page 6]
+
+
+
+
+RFC1122                       INTRODUCTION                  October 1989
+
+
+         the present document and its companion [INTRO:1] define the
+         rules for the current realization of the Internet architecture.
+
+         Internet hosts span a wide range of size, speed, and function.
+         They range in size from small microprocessors through
+         workstations to mainframes and supercomputers.  In function,
+         they range from single-purpose hosts (such as terminal servers)
+         to full-service hosts that support a variety of online network
+         services, typically including remote login, file transfer, and
+         electronic mail.
+
+         A host is generally said to be multihomed if it has more than
+         one interface to the same or to different networks.  See
+         Section 1.1.3 on "Terminology".
+
+      1.1.2  Architectural Assumptions
+
+         The current Internet architecture is based on a set of
+         assumptions about the communication system.  The assumptions
+         most relevant to hosts are as follows:
+
+         (a)  The Internet is a network of networks.
+
+              Each host is directly connected to some particular
+              network(s); its connection to the Internet is only
+              conceptual.  Two hosts on the same network communicate
+              with each other using the same set of protocols that they
+              would use to communicate with hosts on distant networks.
+
+         (b)  Gateways don't keep connection state information.
+
+              To improve robustness of the communication system,
+              gateways are designed to be stateless, forwarding each IP
+              datagram independently of other datagrams.  As a result,
+              redundant paths can be exploited to provide robust service
+              in spite of failures of intervening gateways and networks.
+
+              All state information required for end-to-end flow control
+              and reliability is implemented in the hosts, in the
+              transport layer or in application programs.  All
+              connection control information is thus co-located with the
+              end points of the communication, so it will be lost only
+              if an end point fails.
+
+         (c)  Routing complexity should be in the gateways.
+
+              Routing is a complex and difficult problem, and ought to
+              be performed by the gateways, not the hosts.  An important
+
+
+
+Internet Engineering Task Force                                 [Page 7]
+
+
+
+
+RFC1122                       INTRODUCTION                  October 1989
+
+
+              objective is to insulate host software from changes caused
+              by the inevitable evolution of the Internet routing
+              architecture.
+
+         (d)  The System must tolerate wide network variation.
+
+              A basic objective of the Internet design is to tolerate a
+              wide range of network characteristics -- e.g., bandwidth,
+              delay, packet loss, packet reordering, and maximum packet
+              size.  Another objective is robustness against failure of
+              individual networks, gateways, and hosts, using whatever
+              bandwidth is still available.  Finally, the goal is full
+              "open system interconnection": an Internet host must be
+              able to interoperate robustly and effectively with any
+              other Internet host, across diverse Internet paths.
+
+              Sometimes host implementors have designed for less
+              ambitious goals.  For example, the LAN environment is
+              typically much more benign than the Internet as a whole;
+              LANs have low packet loss and delay and do not reorder
+              packets.  Some vendors have fielded host implementations
+              that are adequate for a simple LAN environment, but work
+              badly for general interoperation.  The vendor justifies
+              such a product as being economical within the restricted
+              LAN market.  However, isolated LANs seldom stay isolated
+              for long; they are soon gatewayed to each other, to
+              organization-wide internets, and eventually to the global
+              Internet system.  In the end, neither the customer nor the
+              vendor is served by incomplete or substandard Internet
+              host software.
+
+              The requirements spelled out in this document are designed
+              for a full-function Internet host, capable of full
+              interoperation over an arbitrary Internet path.
+
+
+      1.1.3  Internet Protocol Suite
+
+         To communicate using the Internet system, a host must implement
+         the layered set of protocols comprising the Internet protocol
+         suite.  A host typically must implement at least one protocol
+         from each layer.
+
+         The protocol layers used in the Internet architecture are as
+         follows [INTRO:4]:
+
+
+         o  Application Layer
+
+
+
+Internet Engineering Task Force                                 [Page 8]
+
+
+
+
+RFC1122                       INTRODUCTION                  October 1989
+
+
+              The application layer is the top layer of the Internet
+              protocol suite.  The Internet suite does not further
+              subdivide the application layer, although some of the
+              Internet application layer protocols do contain some
+              internal sub-layering.  The application layer of the
+              Internet suite essentially combines the functions of the
+              top two layers -- Presentation and Application -- of the
+              OSI reference model.
+
+              We distinguish two categories of application layer
+              protocols:  user protocols that provide service directly
+              to users, and support protocols that provide common system
+              functions.  Requirements for user and support protocols
+              will be found in the companion RFC [INTRO:1].
+
+              The most common Internet user protocols are:
+
+                o  Telnet (remote login)
+                o  FTP    (file transfer)
+                o  SMTP   (electronic mail delivery)
+
+              There are a number of other standardized user protocols
+              [INTRO:4] and many private user protocols.
+
+              Support protocols, used for host name mapping, booting,
+              and management, include SNMP, BOOTP, RARP, and the Domain
+              Name System (DNS) protocols.
+
+
+         o  Transport Layer
+
+              The transport layer provides end-to-end communication
+              services for applications.  There are two primary
+              transport layer protocols at present:
+
+                o Transmission Control Protocol (TCP)
+                o User Datagram Protocol (UDP)
+
+              TCP is a reliable connection-oriented transport service
+              that provides end-to-end reliability, resequencing, and
+              flow control.  UDP is a connectionless ("datagram")
+              transport service.
+
+              Other transport protocols have been developed by the
+              research community, and the set of official Internet
+              transport protocols may be expanded in the future.
+
+              Transport layer protocols are discussed in Chapter 4.
+
+
+
+Internet Engineering Task Force                                 [Page 9]
+
+
+
+
+RFC1122                       INTRODUCTION                  October 1989
+
+
+         o  Internet Layer
+
+              All Internet transport protocols use the Internet Protocol
+              (IP) to carry data from source host to destination host.
+              IP is a connectionless or datagram internetwork service,
+              providing no end-to-end delivery guarantees. Thus, IP
+              datagrams may arrive at the destination host damaged,
+              duplicated, out of order, or not at all.  The layers above
+              IP are responsible for reliable delivery service when it
+              is required.  The IP protocol includes provision for
+              addressing, type-of-service specification, fragmentation
+              and reassembly, and security information.
+
+              The datagram or connectionless nature of the IP protocol
+              is a fundamental and characteristic feature of the
+              Internet architecture.  Internet IP was the model for the
+              OSI Connectionless Network Protocol [INTRO:12].
+
+              ICMP is a control protocol that is considered to be an
+              integral part of IP, although it is architecturally
+              layered upon IP, i.e., it uses IP to carry its data end-
+              to-end just as a transport protocol like TCP or UDP does.
+              ICMP provides error reporting, congestion reporting, and
+              first-hop gateway redirection.
+
+              IGMP is an Internet layer protocol used for establishing
+              dynamic host groups for IP multicasting.
+
+              The Internet layer protocols IP, ICMP, and IGMP are
+              discussed in Chapter 3.
+
+
+         o  Link Layer
+
+              To communicate on its directly-connected network, a host
+              must implement the communication protocol used to
+              interface to that network.  We call this a link layer or
+              media-access layer protocol.
+
+              There is a wide variety of link layer protocols,
+              corresponding to the many different types of networks.
+              See Chapter 2.
+
+
+      1.1.4  Embedded Gateway Code
+
+         Some Internet host software includes embedded gateway
+         functionality, so that these hosts can forward packets as a
+
+
+
+Internet Engineering Task Force                                [Page 10]
+
+
+
+
+RFC1122                       INTRODUCTION                  October 1989
+
+
+         gateway would, while still performing the application layer
+         functions of a host.
+
+         Such dual-purpose systems must follow the Gateway Requirements
+         RFC [INTRO:2]  with respect to their gateway functions, and
+         must follow the present document with respect to their host
+         functions.  In all overlapping cases, the two specifications
+         should be in agreement.
+
+         There are varying opinions in the Internet community about
+         embedded gateway functionality.  The main arguments are as
+         follows:
+
+         o    Pro: in a local network environment where networking is
+              informal, or in isolated internets, it may be convenient
+              and economical to use existing host systems as gateways.
+
+              There is also an architectural argument for embedded
+              gateway functionality: multihoming is much more common
+              than originally foreseen, and multihoming forces a host to
+              make routing decisions as if it were a gateway.  If the
+              multihomed  host contains an embedded gateway, it will
+              have full routing knowledge and as a result will be able
+              to make more optimal routing decisions.
+
+         o    Con: Gateway algorithms and protocols are still changing,
+              and they will continue to change as the Internet system
+              grows larger.  Attempting to include a general gateway
+              function within the host IP layer will force host system
+              maintainers to track these (more frequent) changes.  Also,
+              a larger pool of gateway implementations will make
+              coordinating the changes more difficult.  Finally, the
+              complexity of a gateway IP layer is somewhat greater than
+              that of a host, making the implementation and operation
+              tasks more complex.
+
+              In addition, the style of operation of some hosts is not
+              appropriate for providing stable and robust gateway
+              service.
+
+         There is considerable merit in both of these viewpoints.  One
+         conclusion can be drawn: an host administrator must have
+         conscious control over whether or not a given host acts as a
+         gateway.  See Section 3.1 for the detailed requirements.
+
+
+
+
+
+
+
+Internet Engineering Task Force                                [Page 11]
+
+
+
+
+RFC1122                       INTRODUCTION                  October 1989
+
+
+   1.2  General Considerations
+
+      There are two important lessons that vendors of Internet host
+      software have learned and which a new vendor should consider
+      seriously.
+
+      1.2.1  Continuing Internet Evolution
+
+         The enormous growth of the Internet has revealed problems of
+         management and scaling in a large datagram-based packet
+         communication system.  These problems are being addressed, and
+         as a result there will be continuing evolution of the
+         specifications described in this document.  These changes will
+         be carefully planned and controlled, since there is extensive
+         participation in this planning by the vendors and by the
+         organizations responsible for operations of the networks.
+
+         Development, evolution, and revision are characteristic of
+         computer network protocols today, and this situation will
+         persist for some years.  A vendor who develops computer
+         communication software for the Internet protocol suite (or any
+         other protocol suite!) and then fails to maintain and update
+         that software for changing specifications is going to leave a
+         trail of unhappy customers.  The Internet is a large
+         communication network, and the users are in constant contact
+         through it.  Experience has shown that knowledge of
+         deficiencies in vendor software propagates quickly through the
+         Internet technical community.
+
+      1.2.2  Robustness Principle
+
+         At every layer of the protocols, there is a general rule whose
+         application can lead to enormous benefits in robustness and
+         interoperability [IP:1]:
+
+                "Be liberal in what you accept, and
+                 conservative in what you send"
+
+         Software should be written to deal with every conceivable
+         error, no matter how unlikely; sooner or later a packet will
+         come in with that particular combination of errors and
+         attributes, and unless the software is prepared, chaos can
+         ensue.  In general, it is best to assume that the network is
+         filled with malevolent entities that will send in packets
+         designed to have the worst possible effect.  This assumption
+         will lead to suitable protective design, although the most
+         serious problems in the Internet have been caused by
+         unenvisaged mechanisms triggered by low-probability events;
+
+
+
+Internet Engineering Task Force                                [Page 12]
+
+
+
+
+RFC1122                       INTRODUCTION                  October 1989
+
+
+         mere human malice would never have taken so devious a course!
+
+         Adaptability to change must be designed into all levels of
+         Internet host software.  As a simple example, consider a
+         protocol specification that contains an enumeration of values
+         for a particular header field -- e.g., a type field, a port
+         number, or an error code; this enumeration must be assumed to
+         be incomplete.  Thus, if a protocol specification defines four
+         possible error codes, the software must not break when a fifth
+         code shows up.  An undefined code might be logged (see below),
+         but it must not cause a failure.
+
+         The second part of the principle is almost as important:
+         software on other hosts may contain deficiencies that make it
+         unwise to exploit legal but obscure protocol features.  It is
+         unwise to stray far from the obvious and simple, lest untoward
+         effects result elsewhere.  A corollary of this is "watch out
+         for misbehaving hosts"; host software should be prepared, not
+         just to survive other misbehaving hosts, but also to cooperate
+         to limit the amount of disruption such hosts can cause to the
+         shared communication facility.
+
+      1.2.3  Error Logging
+
+         The Internet includes a great variety of host and gateway
+         systems, each implementing many protocols and protocol layers,
+         and some of these contain bugs and mis-features in their
+         Internet protocol software.  As a result of complexity,
+         diversity, and distribution of function, the diagnosis of
+         Internet problems is often very difficult.
+
+         Problem diagnosis will be aided if host implementations include
+         a carefully designed facility for logging erroneous or
+         "strange" protocol events.  It is important to include as much
+         diagnostic information as possible when an error is logged.  In
+         particular, it is often useful to record the header(s) of a
+         packet that caused an error.  However, care must be taken to
+         ensure that error logging does not consume prohibitive amounts
+         of resources or otherwise interfere with the operation of the
+         host.
+
+         There is a tendency for abnormal but harmless protocol events
+         to overflow error logging files; this can be avoided by using a
+         "circular" log, or by enabling logging only while diagnosing a
+         known failure.  It may be useful to filter and count duplicate
+         successive messages.  One strategy that seems to work well is:
+         (1) always count abnormalities and make such counts accessible
+         through the management protocol (see [INTRO:1]); and (2) allow
+
+
+
+Internet Engineering Task Force                                [Page 13]
+
+
+
+
+RFC1122                       INTRODUCTION                  October 1989
+
+
+         the logging of a great variety of events to be selectively
+         enabled.  For example, it might useful to be able to "log
+         everything" or to "log everything for host X".
+
+         Note that different managements may have differing policies
+         about the amount of error logging that they want normally
+         enabled in a host.  Some will say, "if it doesn't hurt me, I
+         don't want to know about it", while others will want to take a
+         more watchful and aggressive attitude about detecting and
+         removing protocol abnormalities.
+
+      1.2.4  Configuration
+
+         It would be ideal if a host implementation of the Internet
+         protocol suite could be entirely self-configuring.  This would
+         allow the whole suite to be implemented in ROM or cast into
+         silicon, it would simplify diskless workstations, and it would
+         be an immense boon to harried LAN administrators as well as
+         system vendors.  We have not reached this ideal; in fact, we
+         are not even close.
+
+         At many points in this document, you will find a requirement
+         that a parameter be a configurable option.  There are several
+         different reasons behind such requirements.  In a few cases,
+         there is current uncertainty or disagreement about the best
+         value, and it may be necessary to update the recommended value
+         in the future.  In other cases, the value really depends on
+         external factors -- e.g., the size of the host and the
+         distribution of its communication load, or the speeds and
+         topology of nearby networks -- and self-tuning algorithms are
+         unavailable and may be insufficient.  In some cases,
+         configurability is needed because of administrative
+         requirements.
+
+         Finally, some configuration options are required to communicate
+         with obsolete or incorrect implementations of the protocols,
+         distributed without sources, that unfortunately persist in many
+         parts of the Internet.  To make correct systems coexist with
+         these faulty systems, administrators often have to "mis-
+         configure" the correct systems.  This problem will correct
+         itself gradually as the faulty systems are retired, but it
+         cannot be ignored by vendors.
+
+         When we say that a parameter must be configurable, we do not
+         intend to require that its value be explicitly read from a
+         configuration file at every boot time.  We recommend that
+         implementors set up a default for each parameter, so a
+         configuration file is only necessary to override those defaults
+
+
+
+Internet Engineering Task Force                                [Page 14]
+
+
+
+
+RFC1122                       INTRODUCTION                  October 1989
+
+
+         that are inappropriate in a particular installation.  Thus, the
+         configurability requirement is an assurance that it will be
+         POSSIBLE to override the default when necessary, even in a
+         binary-only or ROM-based product.
+
+         This document requires a particular value for such defaults in
+         some cases.  The choice of default is a sensitive issue when
+         the configuration item controls the accommodation to existing
+         faulty systems.  If the Internet is to converge successfully to
+         complete interoperability, the default values built into
+         implementations must implement the official protocol, not
+         "mis-configurations" to accommodate faulty implementations.
+         Although marketing considerations have led some vendors to
+         choose mis-configuration defaults, we urge vendors to choose
+         defaults that will conform to the standard.
+
+         Finally, we note that a vendor needs to provide adequate
+         documentation on all configuration parameters, their limits and
+         effects.
+
+
+   1.3  Reading this Document
+
+      1.3.1  Organization
+
+         Protocol layering, which is generally used as an organizing
+         principle in implementing network software, has also been used
+         to organize this document.  In describing the rules, we assume
+         that an implementation does strictly mirror the layering of the
+         protocols.  Thus, the following three major sections specify
+         the requirements for the link layer, the internet layer, and
+         the transport layer, respectively.  A companion RFC [INTRO:1]
+         covers application level software.  This layerist organization
+         was chosen for simplicity and clarity.
+
+         However, strict layering is an imperfect model, both for the
+         protocol suite and for recommended implementation approaches.
+         Protocols in different layers interact in complex and sometimes
+         subtle ways, and particular functions often involve multiple
+         layers.  There are many design choices in an implementation,
+         many of which involve creative "breaking" of strict layering.
+         Every implementor is urged to read references [INTRO:7] and
+         [INTRO:8].
+
+         This document describes the conceptual service interface
+         between layers using a functional ("procedure call") notation,
+         like that used in the TCP specification [TCP:1].  A host
+         implementation must support the logical information flow
+
+
+
+Internet Engineering Task Force                                [Page 15]
+
+
+
+
+RFC1122                       INTRODUCTION                  October 1989
+
+
+         implied by these calls, but need not literally implement the
+         calls themselves.  For example, many implementations reflect
+         the coupling between the transport layer and the IP layer by
+         giving them shared access to common data structures.  These
+         data structures, rather than explicit procedure calls, are then
+         the agency for passing much of the information that is
+         required.
+
+         In general, each major section of this document is organized
+         into the following subsections:
+
+         (1)  Introduction
+
+         (2)  Protocol Walk-Through -- considers the protocol
+              specification documents section-by-section, correcting
+              errors, stating requirements that may be ambiguous or
+              ill-defined, and providing further clarification or
+              explanation.
+
+         (3)  Specific Issues -- discusses protocol design and
+              implementation issues that were not included in the walk-
+              through.
+
+         (4)  Interfaces -- discusses the service interface to the next
+              higher layer.
+
+         (5)  Summary -- contains a summary of the requirements of the
+              section.
+
+
+         Under many of the individual topics in this document, there is
+         parenthetical material labeled "DISCUSSION" or
+         "IMPLEMENTATION". This material is intended to give
+         clarification and explanation of the preceding requirements
+         text.  It also includes some suggestions on possible future
+         directions or developments.  The implementation material
+         contains suggested approaches that an implementor may want to
+         consider.
+
+         The summary sections are intended to be guides and indexes to
+         the text, but are necessarily cryptic and incomplete.  The
+         summaries should never be used or referenced separately from
+         the complete RFC.
+
+      1.3.2  Requirements
+
+         In this document, the words that are used to define the
+         significance of each particular requirement are capitalized.
+
+
+
+Internet Engineering Task Force                                [Page 16]
+
+
+
+
+RFC1122                       INTRODUCTION                  October 1989
+
+
+         These words are:
+
+         *    "MUST"
+
+              This word or the adjective "REQUIRED" means that the item
+              is an absolute requirement of the specification.
+
+         *    "SHOULD"
+
+              This word or the adjective "RECOMMENDED" means that there
+              may exist valid reasons in particular circumstances to
+              ignore this item, but the full implications should be
+              understood and the case carefully weighed before choosing
+              a different course.
+
+         *    "MAY"
+
+              This word or the adjective "OPTIONAL" means that this item
+              is truly optional.  One vendor may choose to include the
+              item because a particular marketplace requires it or
+              because it enhances the product, for example; another
+              vendor may omit the same item.
+
+
+         An implementation is not compliant if it fails to satisfy one
+         or more of the MUST requirements for the protocols it
+         implements.  An implementation that satisfies all the MUST and
+         all the SHOULD requirements for its protocols is said to be
+         "unconditionally compliant"; one that satisfies all the MUST
+         requirements but not all the SHOULD requirements for its
+         protocols is said to be "conditionally compliant".
+
+      1.3.3  Terminology
+
+         This document uses the following technical terms:
+
+         Segment
+              A segment is the unit of end-to-end transmission in the
+              TCP protocol.  A segment consists of a TCP header followed
+              by application data.  A segment is transmitted by
+              encapsulation inside an IP datagram.
+
+         Message
+              In this description of the lower-layer protocols, a
+              message is the unit of transmission in a transport layer
+              protocol.  In particular, a TCP segment is a message.  A
+              message consists of a transport protocol header followed
+              by application protocol data.  To be transmitted end-to-
+
+
+
+Internet Engineering Task Force                                [Page 17]
+
+
+
+
+RFC1122                       INTRODUCTION                  October 1989
+
+
+              end through the Internet, a message must be encapsulated
+              inside a datagram.
+
+         IP Datagram
+              An IP datagram is the unit of end-to-end transmission in
+              the IP protocol.  An IP datagram consists of an IP header
+              followed by transport layer data, i.e., of an IP header
+              followed by a message.
+
+              In the description of the internet layer (Section 3), the
+              unqualified term "datagram" should be understood to refer
+              to an IP datagram.
+
+         Packet
+              A packet is the unit of data passed across the interface
+              between the internet layer and the link layer.  It
+              includes an IP header and data.  A packet may be a
+              complete IP datagram or a fragment of an IP datagram.
+
+         Frame
+              A frame is the unit of transmission in a link layer
+              protocol, and consists of a link-layer header followed by
+              a packet.
+
+         Connected Network
+              A network to which a host is interfaced is often known as
+              the "local network" or the "subnetwork" relative to that
+              host.  However, these terms can cause confusion, and
+              therefore we use the term "connected network" in this
+              document.
+
+         Multihomed
+              A host is said to be multihomed if it has multiple IP
+              addresses.  For a discussion of multihoming, see Section
+              3.3.4 below.
+
+         Physical network interface
+              This is a physical interface to a connected network and
+              has a (possibly unique) link-layer address.  Multiple
+              physical network interfaces on a single host may share the
+              same link-layer address, but the address must be unique
+              for different hosts on the same physical network.
+
+         Logical [network] interface
+              We define a logical [network] interface to be a logical
+              path, distinguished by a unique IP address, to a connected
+              network.  See Section 3.3.4.
+
+
+
+
+Internet Engineering Task Force                                [Page 18]
+
+
+
+
+RFC1122                       INTRODUCTION                  October 1989
+
+
+         Specific-destination address
+              This is the effective destination address of a datagram,
+              even if it is broadcast or multicast; see Section 3.2.1.3.
+
+         Path
+              At a given moment, all the IP datagrams from a particular
+              source host to a particular destination host will
+              typically traverse the same sequence of gateways.  We use
+              the term "path" for this sequence.  Note that a path is
+              uni-directional; it is not unusual to have different paths
+              in the two directions between a given host pair.
+
+         MTU
+              The maximum transmission unit, i.e., the size of the
+              largest packet that can be transmitted.
+
+
+         The terms frame, packet, datagram, message, and segment are
+         illustrated by the following schematic diagrams:
+
+         A. Transmission on connected network:
+           _______________________________________________
+          | LL hdr | IP hdr |         (data)              |
+          |________|________|_____________________________|
+
+           <---------- Frame ----------------------------->
+                    <----------Packet -------------------->
+
+
+         B. Before IP fragmentation or after IP reassembly:
+                    ______________________________________
+                   | IP hdr | transport| Application Data |
+                   |________|____hdr___|__________________|
+
+                    <--------  Datagram ------------------>
+                             <-------- Message ----------->
+           or, for TCP:
+                    ______________________________________
+                   | IP hdr |  TCP hdr | Application Data |
+                   |________|__________|__________________|
+
+                    <--------  Datagram ------------------>
+                             <-------- Segment ----------->
+
+
+
+
+
+
+
+
+Internet Engineering Task Force                                [Page 19]
+
+
+
+
+RFC1122                       INTRODUCTION                  October 1989
+
+
+   1.4  Acknowledgments
+
+      This document incorporates contributions and comments from a large
+      group of Internet protocol experts, including representatives of
+      university and research labs, vendors, and government agencies.
+      It was assembled primarily by the Host Requirements Working Group
+      of the Internet Engineering Task Force (IETF).
+
+      The Editor would especially like to acknowledge the tireless
+      dedication of the following people, who attended many long
+      meetings and generated 3 million bytes of electronic mail over the
+      past 18 months in pursuit of this document: Philip Almquist, Dave
+      Borman (Cray Research), Noel Chiappa, Dave Crocker (DEC), Steve
+      Deering (Stanford), Mike Karels (Berkeley), Phil Karn (Bellcore),
+      John Lekashman (NASA), Charles Lynn (BBN), Keith McCloghrie (TWG),
+      Paul Mockapetris (ISI), Thomas Narten (Purdue), Craig Partridge
+      (BBN), Drew Perkins (CMU), and James Van Bokkelen (FTP Software).
+
+      In addition, the following people made major contributions to the
+      effort: Bill Barns (Mitre), Steve Bellovin (AT&T), Mike Brescia
+      (BBN), Ed Cain (DCA), Annette DeSchon (ISI), Martin Gross (DCA),
+      Phill Gross (NRI), Charles Hedrick (Rutgers), Van Jacobson (LBL),
+      John Klensin (MIT), Mark Lottor (SRI), Milo Medin (NASA), Bill
+      Melohn (Sun Microsystems), Greg Minshall (Kinetics), Jeff Mogul
+      (DEC), John Mullen (CMC), Jon Postel (ISI), John Romkey (Epilogue
+      Technology), and Mike StJohns (DCA).  The following also made
+      significant contributions to particular areas: Eric Allman
+      (Berkeley), Rob Austein (MIT), Art Berggreen (ACC), Keith Bostic
+      (Berkeley), Vint Cerf (NRI), Wayne Hathaway (NASA), Matt Korn
+      (IBM), Erik Naggum (Naggum Software, Norway), Robert Ullmann
+      (Prime Computer), David Waitzman (BBN), Frank Wancho (USA), Arun
+      Welch (Ohio State), Bill Westfield (Cisco), and Rayan Zachariassen
+      (Toronto).
+
+      We are grateful to all, including any contributors who may have
+      been inadvertently omitted from this list.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Internet Engineering Task Force                                [Page 20]
+
+
+
+
+RFC1122                        LINK LAYER                   October 1989
+
+
+2. LINK LAYER
+
+   2.1  INTRODUCTION
+
+      All Internet systems, both hosts and gateways, have the same
+      requirements for link layer protocols.  These requirements are
+      given in Chapter 3 of "Requirements for Internet Gateways"
+      [INTRO:2], augmented with the material in this section.
+
+   2.2  PROTOCOL WALK-THROUGH
+
+      None.
+
+   2.3  SPECIFIC ISSUES
+
+      2.3.1  Trailer Protocol Negotiation
+
+         The trailer protocol [LINK:1] for link-layer encapsulation MAY
+         be used, but only when it has been verified that both systems
+         (host or gateway) involved in the link-layer communication
+         implement trailers.  If the system does not dynamically
+         negotiate use of the trailer protocol on a per-destination
+         basis, the default configuration MUST disable the protocol.
+
+         DISCUSSION:
+              The trailer protocol is a link-layer encapsulation
+              technique that rearranges the data contents of packets
+              sent on the physical network.  In some cases, trailers
+              improve the throughput of higher layer protocols by
+              reducing the amount of data copying within the operating
+              system.  Higher layer protocols are unaware of trailer
+              use, but both the sending and receiving host MUST
+              understand the protocol if it is used.
+
+              Improper use of trailers can result in very confusing
+              symptoms.  Only packets with specific size attributes are
+              encapsulated using trailers, and typically only a small
+              fraction of the packets being exchanged have these
+              attributes.  Thus, if a system using trailers exchanges
+              packets with a system that does not, some packets
+              disappear into a black hole while others are delivered
+              successfully.
+
+         IMPLEMENTATION:
+              On an Ethernet, packets encapsulated with trailers use a
+              distinct Ethernet type [LINK:1], and trailer negotiation
+              is performed at the time that ARP is used to discover the
+              link-layer address of a destination system.
+
+
+
+Internet Engineering Task Force                                [Page 21]
+
+
+
+
+RFC1122                        LINK LAYER                   October 1989
+
+
+              Specifically, the ARP exchange is completed in the usual
+              manner using the normal IP protocol type, but a host that
+              wants to speak trailers will send an additional "trailer
+              ARP reply" packet, i.e., an ARP reply that specifies the
+              trailer encapsulation protocol type but otherwise has the
+              format of a normal ARP reply.  If a host configured to use
+              trailers receives a trailer ARP reply message from a
+              remote machine, it can add that machine to the list of
+              machines that understand trailers, e.g., by marking the
+              corresponding entry in the ARP cache.
+
+              Hosts wishing to receive trailer encapsulations send
+              trailer ARP replies whenever they complete exchanges of
+              normal ARP messages for IP.  Thus, a host that received an
+              ARP request for its IP protocol address would send a
+              trailer ARP reply in addition to the normal IP ARP reply;
+              a host that sent the IP ARP request would send a trailer
+              ARP reply when it received the corresponding IP ARP reply.
+              In this way, either the requesting or responding host in
+              an IP ARP exchange may request that it receive trailer
+              encapsulations.
+
+              This scheme, using extra trailer ARP reply packets rather
+              than sending an ARP request for the trailer protocol type,
+              was designed to avoid a continuous exchange of ARP packets
+              with a misbehaving host that, contrary to any
+              specification or common sense, responded to an ARP reply
+              for trailers with another ARP reply for IP.  This problem
+              is avoided by sending a trailer ARP reply in response to
+              an IP ARP reply only when the IP ARP reply answers an
+              outstanding request; this is true when the hardware
+              address for the host is still unknown when the IP ARP
+              reply is received.  A trailer ARP reply may always be sent
+              along with an IP ARP reply responding to an IP ARP
+              request.
+
+      2.3.2  Address Resolution Protocol -- ARP
+
+         2.3.2.1  ARP Cache Validation
+
+            An implementation of the Address Resolution Protocol (ARP)
+            [LINK:2] MUST provide a mechanism to flush out-of-date cache
+            entries.  If this mechanism involves a timeout, it SHOULD be
+            possible to configure the timeout value.
+
+            A mechanism to prevent ARP flooding (repeatedly sending an
+            ARP Request for the same IP address, at a high rate) MUST be
+            included.  The recommended maximum rate is 1 per second per
+
+
+
+Internet Engineering Task Force                                [Page 22]
+
+
+
+
+RFC1122                        LINK LAYER                   October 1989
+
+
+            destination.
+
+            DISCUSSION:
+                 The ARP specification [LINK:2] suggests but does not
+                 require a timeout mechanism to invalidate cache entries
+                 when hosts change their Ethernet addresses.  The
+                 prevalence of proxy ARP (see Section 2.4 of [INTRO:2])
+                 has significantly increased the likelihood that cache
+                 entries in hosts will become invalid, and therefore
+                 some ARP-cache invalidation mechanism is now required
+                 for hosts.  Even in the absence of proxy ARP, a long-
+                 period cache timeout is useful in order to
+                 automatically correct any bad ARP data that might have
+                 been cached.
+
+            IMPLEMENTATION:
+                 Four mechanisms have been used, sometimes in
+                 combination, to flush out-of-date cache entries.
+
+                 (1)  Timeout -- Periodically time out cache entries,
+                      even if they are in use.  Note that this timeout
+                      should be restarted when the cache entry is
+                      "refreshed" (by observing the source fields,
+                      regardless of target address, of an ARP broadcast
+                      from the system in question).  For proxy ARP
+                      situations, the timeout needs to be on the order
+                      of a minute.
+
+                 (2)  Unicast Poll -- Actively poll the remote host by
+                      periodically sending a point-to-point ARP Request
+                      to it, and delete the entry if no ARP Reply is
+                      received from N successive polls.  Again, the
+                      timeout should be on the order of a minute, and
+                      typically N is 2.
+
+                 (3)  Link-Layer Advice -- If the link-layer driver
+                      detects a delivery problem, flush the
+                      corresponding ARP cache entry.
+
+                 (4)  Higher-layer Advice -- Provide a call from the
+                      Internet layer to the link layer to indicate a
+                      delivery problem.  The effect of this call would
+                      be to invalidate the corresponding cache entry.
+                      This call would be analogous to the
+                      "ADVISE_DELIVPROB()" call from the transport layer
+                      to the Internet layer (see Section 3.4), and in
+                      fact the ADVISE_DELIVPROB routine might in turn
+                      call the link-layer advice routine to invalidate
+
+
+
+Internet Engineering Task Force                                [Page 23]
+
+
+
+
+RFC1122                        LINK LAYER                   October 1989
+
+
+                      the ARP cache entry.
+
+                 Approaches (1) and (2) involve ARP cache timeouts on
+                 the order of a minute or less.  In the absence of proxy
+                 ARP, a timeout this short could create noticeable
+                 overhead traffic on a very large Ethernet.  Therefore,
+                 it may be necessary to configure a host to lengthen the
+                 ARP cache timeout.
+
+         2.3.2.2  ARP Packet Queue
+
+            The link layer SHOULD save (rather than discard) at least
+            one (the latest) packet of each set of packets destined to
+            the same unresolved IP address, and transmit the saved
+            packet when the address has been resolved.
+
+            DISCUSSION:
+                 Failure to follow this recommendation causes the first
+                 packet of every exchange to be lost.  Although higher-
+                 layer protocols can generally cope with packet loss by
+                 retransmission, packet loss does impact performance.
+                 For example, loss of a TCP open request causes the
+                 initial round-trip time estimate to be inflated.  UDP-
+                 based applications such as the Domain Name System are
+                 more seriously affected.
+
+      2.3.3  Ethernet and IEEE 802 Encapsulation
+
+         The IP encapsulation for Ethernets is described in RFC-894
+         [LINK:3], while RFC-1042 [LINK:4] describes the IP
+         encapsulation for IEEE 802 networks.  RFC-1042 elaborates and
+         replaces the discussion in Section 3.4 of [INTRO:2].
+
+         Every Internet host connected to a 10Mbps Ethernet cable:
+
+         o    MUST be able to send and receive packets using RFC-894
+              encapsulation;
+
+         o    SHOULD be able to receive RFC-1042 packets, intermixed
+              with RFC-894 packets; and
+
+         o    MAY be able to send packets using RFC-1042 encapsulation.
+
+
+         An Internet host that implements sending both the RFC-894 and
+         the RFC-1042 encapsulations MUST provide a configuration switch
+         to select which is sent, and this switch MUST default to RFC-
+         894.
+
+
+
+Internet Engineering Task Force                                [Page 24]
+
+
+
+
+RFC1122                        LINK LAYER                   October 1989
+
+
+         Note that the standard IP encapsulation in RFC-1042 does not
+         use the protocol id value (K1=6) that IEEE reserved for IP;
+         instead, it uses a value (K1=170) that implies an extension
+         (the "SNAP") which can be used to hold the Ether-Type field.
+         An Internet system MUST NOT send 802 packets using K1=6.
+
+         Address translation from Internet addresses to link-layer
+         addresses on Ethernet and IEEE 802 networks MUST be managed by
+         the Address Resolution Protocol (ARP).
+
+         The MTU for an Ethernet is 1500 and for 802.3 is 1492.
+
+         DISCUSSION:
+              The IEEE 802.3 specification provides for operation over a
+              10Mbps Ethernet cable, in which case Ethernet and IEEE
+              802.3 frames can be physically intermixed.  A receiver can
+              distinguish Ethernet and 802.3 frames by the value of the
+              802.3 Length field; this two-octet field coincides in the
+              header with the Ether-Type field of an Ethernet frame.  In
+              particular, the 802.3 Length field must be less than or
+              equal to 1500, while all valid Ether-Type values are
+              greater than 1500.
+
+              Another compatibility problem arises with link-layer
+              broadcasts.  A broadcast sent with one framing will not be
+              seen by hosts that can receive only the other framing.
+
+              The provisions of this section were designed to provide
+              direct interoperation between 894-capable and 1042-capable
+              systems on the same cable, to the maximum extent possible.
+              It is intended to support the present situation where
+              894-only systems predominate, while providing an easy
+              transition to a possible future in which 1042-capable
+              systems become common.
+
+              Note that 894-only systems cannot interoperate directly
+              with 1042-only systems.  If the two system types are set
+              up as two different logical networks on the same cable,
+              they can communicate only through an IP gateway.
+              Furthermore, it is not useful or even possible for a
+              dual-format host to discover automatically which format to
+              send, because of the problem of link-layer broadcasts.
+
+   2.4  LINK/INTERNET LAYER INTERFACE
+
+      The packet receive interface between the IP layer and the link
+      layer MUST include a flag to indicate whether the incoming packet
+      was addressed to a link-layer broadcast address.
+
+
+
+Internet Engineering Task Force                                [Page 25]
+
+
+
+
+RFC1122                        LINK LAYER                   October 1989
+
+
+      DISCUSSION
+           Although the IP layer does not generally know link layer
+           addresses (since every different network medium typically has
+           a different address format), the broadcast address on a
+           broadcast-capable medium is an important special case.  See
+           Section 3.2.2, especially the DISCUSSION concerning broadcast
+           storms.
+
+      The packet send interface between the IP and link layers MUST
+      include the 5-bit TOS field (see Section 3.2.1.6).
+
+      The link layer MUST NOT report a Destination Unreachable error to
+      IP solely because there is no ARP cache entry for a destination.
+
+   2.5  LINK LAYER REQUIREMENTS SUMMARY
+
+                                                  |       | | | |S| |
+                                                  |       | | | |H| |F
+                                                  |       | | | |O|M|o
+                                                  |       | |S| |U|U|o
+                                                  |       | |H| |L|S|t
+                                                  |       |M|O| |D|T|n
+                                                  |       |U|U|M| | |o
+                                                  |       |S|L|A|N|N|t
+                                                  |       |T|D|Y|O|O|t
+FEATURE                                           |SECTION| | | |T|T|e
+--------------------------------------------------|-------|-|-|-|-|-|--
+                                                  |       | | | | | |
+Trailer encapsulation                             |2.3.1  | | |x| | |
+Send Trailers by default without negotiation      |2.3.1  | | | | |x|
+ARP                                               |2.3.2  | | | | | |
+  Flush out-of-date ARP cache entries             |2.3.2.1|x| | | | |
+  Prevent ARP floods                              |2.3.2.1|x| | | | |
+  Cache timeout configurable                      |2.3.2.1| |x| | | |
+  Save at least one (latest) unresolved pkt       |2.3.2.2| |x| | | |
+Ethernet and IEEE 802 Encapsulation               |2.3.3  | | | | | |
+  Host able to:                                   |2.3.3  | | | | | |
+    Send & receive RFC-894 encapsulation          |2.3.3  |x| | | | |
+    Receive RFC-1042 encapsulation                |2.3.3  | |x| | | |
+    Send RFC-1042 encapsulation                   |2.3.3  | | |x| | |
+      Then config. sw. to select, RFC-894 dflt    |2.3.3  |x| | | | |
+  Send K1=6 encapsulation                         |2.3.3  | | | | |x|
+  Use ARP on Ethernet and IEEE 802 nets           |2.3.3  |x| | | | |
+Link layer report b'casts to IP layer             |2.4    |x| | | | |
+IP layer pass TOS to link layer                   |2.4    |x| | | | |
+No ARP cache entry treated as Dest. Unreach.      |2.4    | | | | |x|
+
+
+
+
+
+Internet Engineering Task Force                                [Page 26]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+3. INTERNET LAYER PROTOCOLS
+
+   3.1 INTRODUCTION
+
+      The Robustness Principle: "Be liberal in what you accept, and
+      conservative in what you send" is particularly important in the
+      Internet layer, where one misbehaving host can deny Internet
+      service to many other hosts.
+
+      The protocol standards used in the Internet layer are:
+
+      o    RFC-791 [IP:1] defines the IP protocol and gives an
+           introduction to the architecture of the Internet.
+
+      o    RFC-792 [IP:2] defines ICMP, which provides routing,
+           diagnostic and error functionality for IP.  Although ICMP
+           messages are encapsulated within IP datagrams, ICMP
+           processing is considered to be (and is typically implemented
+           as) part of the IP layer.  See Section 3.2.2.
+
+      o    RFC-950 [IP:3] defines the mandatory subnet extension to the
+           addressing architecture.
+
+      o    RFC-1112 [IP:4] defines the Internet Group Management
+           Protocol IGMP, as part of a recommended extension to hosts
+           and to the host-gateway interface to support Internet-wide
+           multicasting at the IP level.  See Section 3.2.3.
+
+           The target of an IP multicast may be an arbitrary group of
+           Internet hosts.  IP multicasting is designed as a natural
+           extension of the link-layer multicasting facilities of some
+           networks, and it provides a standard means for local access
+           to such link-layer multicasting facilities.
+
+      Other important references are listed in Section 5 of this
+      document.
+
+      The Internet layer of host software MUST implement both IP and
+      ICMP.  See Section 3.3.7 for the requirements on support of IGMP.
+
+      The host IP layer has two basic functions:  (1) choose the "next
+      hop" gateway or host for outgoing IP datagrams and (2) reassemble
+      incoming IP datagrams.  The IP layer may also (3) implement
+      intentional fragmentation of outgoing datagrams.  Finally, the IP
+      layer must (4) provide diagnostic and error functionality.  We
+      expect that IP layer functions may increase somewhat in the
+      future, as further Internet control and management facilities are
+      developed.
+
+
+
+Internet Engineering Task Force                                [Page 27]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+      For normal datagrams, the processing is straightforward.  For
+      incoming datagrams, the IP layer:
+
+      (1)  verifies that the datagram is correctly formatted;
+
+      (2)  verifies that it is destined to the local host;
+
+      (3)  processes options;
+
+      (4)  reassembles the datagram if necessary; and
+
+      (5)  passes the encapsulated message to the appropriate
+           transport-layer protocol module.
+
+      For outgoing datagrams, the IP layer:
+
+      (1)  sets any fields not set by the transport layer;
+
+      (2)  selects the correct first hop on the connected network (a
+           process called "routing");
+
+      (3)  fragments the datagram if necessary and if intentional
+           fragmentation is implemented (see Section 3.3.3); and
+
+      (4)  passes the packet(s) to the appropriate link-layer driver.
+
+
+      A host is said to be multihomed if it has multiple IP addresses.
+      Multihoming introduces considerable confusion and complexity into
+      the protocol suite, and it is an area in which the Internet
+      architecture falls seriously short of solving all problems.  There
+      are two distinct problem areas in multihoming:
+
+      (1)  Local multihoming --  the host itself is multihomed; or
+
+      (2)  Remote multihoming -- the local host needs to communicate
+           with a remote multihomed host.
+
+      At present, remote multihoming MUST be handled at the application
+      layer, as discussed in the companion RFC [INTRO:1].  A host MAY
+      support local multihoming, which is discussed in this document,
+      and in particular in Section 3.3.4.
+
+      Any host that forwards datagrams generated by another host is
+      acting as a gateway and MUST also meet the specifications laid out
+      in the gateway requirements RFC [INTRO:2].  An Internet host that
+      includes embedded gateway code MUST have a configuration switch to
+      disable the gateway function, and this switch MUST default to the
+
+
+
+Internet Engineering Task Force                                [Page 28]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+      non-gateway mode.  In this mode, a datagram arriving through one
+      interface will not be forwarded to another host or gateway (unless
+      it is source-routed), regardless of whether the host is single-
+      homed or multihomed.  The host software MUST NOT automatically
+      move into gateway mode if the host has more than one interface, as
+      the operator of the machine may neither want to provide that
+      service nor be competent to do so.
+
+      In the following, the action specified in certain cases is to
+      "silently discard" a received datagram.  This means that the
+      datagram will be discarded without further processing and that the
+      host will not send any ICMP error message (see Section 3.2.2) as a
+      result.  However, for diagnosis of problems a host SHOULD provide
+      the capability of logging the error (see Section 1.2.3), including
+      the contents of the silently-discarded datagram, and SHOULD record
+      the event in a statistics counter.
+
+      DISCUSSION:
+           Silent discard of erroneous datagrams is generally intended
+           to prevent "broadcast storms".
+
+   3.2  PROTOCOL WALK-THROUGH
+
+      3.2.1 Internet Protocol -- IP
+
+         3.2.1.1  Version Number: RFC-791 Section 3.1
+
+            A datagram whose version number is not 4 MUST be silently
+            discarded.
+
+         3.2.1.2  Checksum: RFC-791 Section 3.1
+
+            A host MUST verify the IP header checksum on every received
+            datagram and silently discard every datagram that has a bad
+            checksum.
+
+         3.2.1.3  Addressing: RFC-791 Section 3.2
+
+            There are now five classes of IP addresses: Class A through
+            Class E.  Class D addresses are used for IP multicasting
+            [IP:4], while Class E addresses are reserved for
+            experimental use.
+
+            A multicast (Class D) address is a 28-bit logical address
+            that stands for a group of hosts, and may be either
+            permanent or transient.  Permanent multicast addresses are
+            allocated by the Internet Assigned Number Authority
+            [INTRO:6], while transient addresses may be allocated
+
+
+
+Internet Engineering Task Force                                [Page 29]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+            dynamically to transient groups.  Group membership is
+            determined dynamically using IGMP [IP:4].
+
+            We now summarize the important special cases for Class A, B,
+            and C IP addresses, using the following notation for an IP
+            address:
+
+                { <Network-number>, <Host-number> }
+
+            or
+                { <Network-number>, <Subnet-number>, <Host-number> }
+
+            and the notation "-1" for a field that contains all 1 bits.
+            This notation is not intended to imply that the 1-bits in an
+            address mask need be contiguous.
+
+            (a)  { 0, 0 }
+
+                 This host on this network.  MUST NOT be sent, except as
+                 a source address as part of an initialization procedure
+                 by which the host learns its own IP address.
+
+                 See also Section 3.3.6 for a non-standard use of {0,0}.
+
+            (b)  { 0, <Host-number> }
+
+                 Specified host on this network.  It MUST NOT be sent,
+                 except as a source address as part of an initialization
+                 procedure by which the host learns its full IP address.
+
+            (c)  { -1, -1 }
+
+                 Limited broadcast.  It MUST NOT be used as a source
+                 address.
+
+                 A datagram with this destination address will be
+                 received by every host on the connected physical
+                 network but will not be forwarded outside that network.
+
+            (d)  { <Network-number>, -1 }
+
+                 Directed broadcast to the specified network.  It MUST
+                 NOT be used as a source address.
+
+            (e)  { <Network-number>, <Subnet-number>, -1 }
+
+                 Directed broadcast to the specified subnet.  It MUST
+                 NOT be used as a source address.
+
+
+
+Internet Engineering Task Force                                [Page 30]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+            (f)  { <Network-number>, -1, -1 }
+
+                 Directed broadcast to all subnets of the specified
+                 subnetted network.  It MUST NOT be used as a source
+                 address.
+
+            (g)  { 127, <any> }
+
+                 Internal host loopback address.  Addresses of this form
+                 MUST NOT appear outside a host.
+
+            The <Network-number> is administratively assigned so that
+            its value will be unique in the entire world.
+
+            IP addresses are not permitted to have the value 0 or -1 for
+            any of the <Host-number>, <Network-number>, or <Subnet-
+            number> fields (except in the special cases listed above).
+            This implies that each of these fields will be at least two
+            bits long.
+
+            For further discussion of broadcast addresses, see Section
+            3.3.6.
+
+            A host MUST support the subnet extensions to IP [IP:3].  As
+            a result, there will be an address mask of the form:
+            {-1, -1, 0} associated with each of the host's local IP
+            addresses; see Sections 3.2.2.9 and 3.3.1.1.
+
+            When a host sends any datagram, the IP source address MUST
+            be one of its own IP addresses (but not a broadcast or
+            multicast address).
+
+            A host MUST silently discard an incoming datagram that is
+            not destined for the host.  An incoming datagram is destined
+            for the host if the datagram's destination address field is:
+
+            (1)  (one of) the host's IP address(es); or
+
+            (2)  an IP broadcast address valid for the connected
+                 network; or
+
+            (3)  the address for a multicast group of which the host is
+                 a member on the incoming physical interface.
+
+            For most purposes, a datagram addressed to a broadcast or
+            multicast destination is processed as if it had been
+            addressed to one of the host's IP addresses; we use the term
+            "specific-destination address" for the equivalent local IP
+
+
+
+Internet Engineering Task Force                                [Page 31]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+            address of the host.  The specific-destination address is
+            defined to be the destination address in the IP header
+            unless the header contains a broadcast or multicast address,
+            in which case the specific-destination is an IP address
+            assigned to the physical interface on which the datagram
+            arrived.
+
+            A host MUST silently discard an incoming datagram containing
+            an IP source address that is invalid by the rules of this
+            section.  This validation could be done in either the IP
+            layer or by each protocol in the transport layer.
+
+            DISCUSSION:
+                 A mis-addressed datagram might be caused by a link-
+                 layer broadcast of a unicast datagram or by a gateway
+                 or host that is confused or mis-configured.
+
+                 An architectural goal for Internet hosts was to allow
+                 IP addresses to be featureless 32-bit numbers, avoiding
+                 algorithms that required a knowledge of the IP address
+                 format.  Otherwise, any future change in the format or
+                 interpretation of IP addresses will require host
+                 software changes.  However, validation of broadcast and
+                 multicast addresses violates this goal; a few other
+                 violations are described elsewhere in this document.
+
+                 Implementers should be aware that applications
+                 depending upon the all-subnets directed broadcast
+                 address (f) may be unusable on some networks.  All-
+                 subnets broadcast is not widely implemented in vendor
+                 gateways at present, and even when it is implemented, a
+                 particular network administration may disable it in the
+                 gateway configuration.
+
+         3.2.1.4  Fragmentation and Reassembly: RFC-791 Section 3.2
+
+            The Internet model requires that every host support
+            reassembly.  See Sections 3.3.2 and 3.3.3 for the
+            requirements on fragmentation and reassembly.
+
+         3.2.1.5  Identification: RFC-791 Section 3.2
+
+            When sending an identical copy of an earlier datagram, a
+            host MAY optionally retain the same Identification field in
+            the copy.
+
+
+
+
+
+
+Internet Engineering Task Force                                [Page 32]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+            DISCUSSION:
+                 Some Internet protocol experts have maintained that
+                 when a host sends an identical copy of an earlier
+                 datagram, the new copy should contain the same
+                 Identification value as the original.  There are two
+                 suggested advantages:  (1) if the datagrams are
+                 fragmented and some of the fragments are lost, the
+                 receiver may be able to reconstruct a complete datagram
+                 from fragments of the original and the copies; (2) a
+                 congested gateway might use the IP Identification field
+                 (and Fragment Offset) to discard duplicate datagrams
+                 from the queue.
+
+                 However, the observed patterns of datagram loss in the
+                 Internet do not favor the probability of retransmitted
+                 fragments filling reassembly gaps, while other
+                 mechanisms (e.g., TCP repacketizing upon
+                 retransmission) tend to prevent retransmission of an
+                 identical datagram [IP:9].  Therefore, we believe that
+                 retransmitting the same Identification field is not
+                 useful.  Also, a connectionless transport protocol like
+                 UDP would require the cooperation of the application
+                 programs to retain the same Identification value in
+                 identical datagrams.
+
+         3.2.1.6  Type-of-Service: RFC-791 Section 3.2
+
+            The "Type-of-Service" byte in the IP header is divided into
+            two sections:  the Precedence field (high-order 3 bits), and
+            a field that is customarily called "Type-of-Service" or
+            "TOS" (low-order 5 bits).  In this document, all references
+            to "TOS" or the "TOS field" refer to the low-order 5 bits
+            only.
+
+            The Precedence field is intended for Department of Defense
+            applications of the Internet protocols.  The use of non-zero
+            values in this field is outside the scope of this document
+            and the IP standard specification.  Vendors should consult
+            the Defense Communication Agency (DCA) for guidance on the
+            IP Precedence field and its implications for other protocol
+            layers.  However, vendors should note that the use of
+            precedence will most likely require that its value be passed
+            between protocol layers in just the same way as the TOS
+            field is passed.
+
+            The IP layer MUST provide a means for the transport layer to
+            set the TOS field of every datagram that is sent; the
+            default is all zero bits.  The IP layer SHOULD pass received
+
+
+
+Internet Engineering Task Force                                [Page 33]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+            TOS values up to the transport layer.
+
+            The particular link-layer mappings of TOS contained in RFC-
+            795 SHOULD NOT be implemented.
+
+            DISCUSSION:
+                 While the TOS field has been little used in the past,
+                 it is expected to play an increasing role in the near
+                 future.  The TOS field is expected to be used to
+                 control two aspects of gateway operations: routing and
+                 queueing algorithms.  See Section 2 of [INTRO:1] for
+                 the requirements on application programs to specify TOS
+                 values.
+
+                 The TOS field may also be mapped into link-layer
+                 service selectors.  This has been applied to provide
+                 effective sharing of serial lines by different classes
+                 of TCP traffic, for example.  However, the mappings
+                 suggested in RFC-795 for networks that were included in
+                 the Internet as of 1981 are now obsolete.
+
+         3.2.1.7  Time-to-Live: RFC-791 Section 3.2
+
+            A host MUST NOT send a datagram with a Time-to-Live (TTL)
+            value of zero.
+
+            A host MUST NOT discard a datagram just because it was
+            received with TTL less than 2.
+
+            The IP layer MUST provide a means for the transport layer to
+            set the TTL field of every datagram that is sent.  When a
+            fixed TTL value is used, it MUST be configurable.  The
+            current suggested value will be published in the "Assigned
+            Numbers" RFC.
+
+            DISCUSSION:
+                 The TTL field has two functions: limit the lifetime of
+                 TCP segments (see RFC-793 [TCP:1], p. 28), and
+                 terminate Internet routing loops.  Although TTL is a
+                 time in seconds, it also has some attributes of a hop-
+                 count, since each gateway is required to reduce the TTL
+                 field by at least one.
+
+                 The intent is that TTL expiration will cause a datagram
+                 to be discarded by a gateway but not by the destination
+                 host; however, hosts that act as gateways by forwarding
+                 datagrams must follow the gateway rules for TTL.
+
+
+
+
+Internet Engineering Task Force                                [Page 34]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+                 A higher-layer protocol may want to set the TTL in
+                 order to implement an "expanding scope" search for some
+                 Internet resource.  This is used by some diagnostic
+                 tools, and is expected to be useful for locating the
+                 "nearest" server of a given class using IP
+                 multicasting, for example.  A particular transport
+                 protocol may also want to specify its own TTL bound on
+                 maximum datagram lifetime.
+
+                 A fixed value must be at least big enough for the
+                 Internet "diameter," i.e., the longest possible path.
+                 A reasonable value is about twice the diameter, to
+                 allow for continued Internet growth.
+
+         3.2.1.8  Options: RFC-791 Section 3.2
+
+            There MUST be a means for the transport layer to specify IP
+            options to be included in transmitted IP datagrams (see
+            Section 3.4).
+
+            All IP options (except NOP or END-OF-LIST) received in
+            datagrams MUST be passed to the transport layer (or to ICMP
+            processing when the datagram is an ICMP message).  The IP
+            and transport layer MUST each interpret those IP options
+            that they understand and silently ignore the others.
+
+            Later sections of this document discuss specific IP option
+            support required by each of ICMP, TCP, and UDP.
+
+            DISCUSSION:
+                 Passing all received IP options to the transport layer
+                 is a deliberate "violation of strict layering" that is
+                 designed to ease the introduction of new transport-
+                 relevant IP options in the future.  Each layer must
+                 pick out any options that are relevant to its own
+                 processing and ignore the rest.  For this purpose,
+                 every IP option except NOP and END-OF-LIST will include
+                 a specification of its own length.
+
+                 This document does not define the order in which a
+                 receiver must process multiple options in the same IP
+                 header.  Hosts sending multiple options must be aware
+                 that this introduces an ambiguity in the meaning of
+                 certain options when combined with a source-route
+                 option.
+
+            IMPLEMENTATION:
+                 The IP layer must not crash as the result of an option
+
+
+
+Internet Engineering Task Force                                [Page 35]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+                 length that is outside the possible range.  For
+                 example, erroneous option lengths have been observed to
+                 put some IP implementations into infinite loops.
+
+            Here are the requirements for specific IP options:
+
+
+            (a)  Security Option
+
+                 Some environments require the Security option in every
+                 datagram; such a requirement is outside the scope of
+                 this document and the IP standard specification.  Note,
+                 however, that the security options described in RFC-791
+                 and RFC-1038 are obsolete.  For DoD applications,
+                 vendors should consult [IP:8] for guidance.
+
+
+            (b)  Stream Identifier Option
+
+                 This option is obsolete; it SHOULD NOT be sent, and it
+                 MUST be silently ignored if received.
+
+
+            (c)  Source Route Options
+
+                 A host MUST support originating a source route and MUST
+                 be able to act as the final destination of a source
+                 route.
+
+                 If host receives a datagram containing a completed
+                 source route (i.e., the pointer points beyond the last
+                 field), the datagram has reached its final destination;
+                 the option as received (the recorded route) MUST be
+                 passed up to the transport layer (or to ICMP message
+                 processing).  This recorded route will be reversed and
+                 used to form a return source route for reply datagrams
+                 (see discussion of IP Options in Section 4).  When a
+                 return source route is built, it MUST be correctly
+                 formed even if the recorded route included the source
+                 host (see case (B) in the discussion below).
+
+                 An IP header containing more than one Source Route
+                 option MUST NOT be sent; the effect on routing of
+                 multiple Source Route options is implementation-
+                 specific.
+
+                 Section 3.3.5 presents the rules for a host acting as
+                 an intermediate hop in a source route, i.e., forwarding
+
+
+
+Internet Engineering Task Force                                [Page 36]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+                 a source-routed datagram.
+
+                 DISCUSSION:
+                      If a source-routed datagram is fragmented, each
+                      fragment will contain a copy of the source route.
+                      Since the processing of IP options (including a
+                      source route) must precede reassembly, the
+                      original datagram will not be reassembled until
+                      the final destination is reached.
+
+                      Suppose a source routed datagram is to be routed
+                      from host S to host D via gateways G1, G2, ... Gn.
+                      There was an ambiguity in the specification over
+                      whether the source route option in a datagram sent
+                      out by S should be (A) or (B):
+
+                          (A):  {>>G2, G3, ... Gn, D}     <--- CORRECT
+
+                          (B):  {S, >>G2, G3, ... Gn, D}  <---- WRONG
+
+                      (where >> represents the pointer).  If (A) is
+                      sent, the datagram received at D will contain the
+                      option: {G1, G2, ... Gn >>}, with S and D as the
+                      IP source and destination addresses.  If (B) were
+                      sent, the datagram received at D would again
+                      contain S and D as the same IP source and
+                      destination addresses, but the option would be:
+                      {S, G1, ...Gn >>}; i.e., the originating host
+                      would be the first hop in the route.
+
+
+            (d)  Record Route Option
+
+                 Implementation of originating and processing the Record
+                 Route option is OPTIONAL.
+
+
+            (e)  Timestamp Option
+
+                 Implementation of originating and processing the
+                 Timestamp option is OPTIONAL.  If it is implemented,
+                 the following rules apply:
+
+                 o    The originating host MUST record a timestamp in a
+                      Timestamp option whose Internet address fields are
+                      not pre-specified or whose first pre-specified
+                      address is the host's interface address.
+
+
+
+
+Internet Engineering Task Force                                [Page 37]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+                 o    The destination host MUST (if possible) add the
+                      current timestamp to a Timestamp option before
+                      passing the option to the transport layer or to
+                      ICMP for processing.
+
+                 o    A timestamp value MUST follow the rules given in
+                      Section 3.2.2.8 for the ICMP Timestamp message.
+
+
+      3.2.2 Internet Control Message Protocol -- ICMP
+
+         ICMP messages are grouped into two classes.
+
+         *
+              ICMP error messages:
+
+               Destination Unreachable   (see Section 3.2.2.1)
+               Redirect                  (see Section 3.2.2.2)
+               Source Quench             (see Section 3.2.2.3)
+               Time Exceeded             (see Section 3.2.2.4)
+               Parameter Problem         (see Section 3.2.2.5)
+
+
+         *
+              ICMP query messages:
+
+                Echo                     (see Section 3.2.2.6)
+                Information              (see Section 3.2.2.7)
+                Timestamp                (see Section 3.2.2.8)
+                Address Mask             (see Section 3.2.2.9)
+
+
+         If an ICMP message of unknown type is received, it MUST be
+         silently discarded.
+
+         Every ICMP error message includes the Internet header and at
+         least the first 8 data octets of the datagram that triggered
+         the error; more than 8 octets MAY be sent; this header and data
+         MUST be unchanged from the received datagram.
+
+         In those cases where the Internet layer is required to pass an
+         ICMP error message to the transport layer, the IP protocol
+         number MUST be extracted from the original header and used to
+         select the appropriate transport protocol entity to handle the
+         error.
+
+         An ICMP error message SHOULD be sent with normal (i.e., zero)
+         TOS bits.
+
+
+
+Internet Engineering Task Force                                [Page 38]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+         An ICMP error message MUST NOT be sent as the result of
+         receiving:
+
+         *    an ICMP error message, or
+
+         *    a datagram destined to an IP broadcast or IP multicast
+              address, or
+
+         *    a datagram sent as a link-layer broadcast, or
+
+         *    a non-initial fragment, or
+
+         *    a datagram whose source address does not define a single
+              host -- e.g., a zero address, a loopback address, a
+              broadcast address, a multicast address, or a Class E
+              address.
+
+         NOTE: THESE RESTRICTIONS TAKE PRECEDENCE OVER ANY REQUIREMENT
+         ELSEWHERE IN THIS DOCUMENT FOR SENDING ICMP ERROR MESSAGES.
+
+         DISCUSSION:
+              These rules will prevent the "broadcast storms" that have
+              resulted from hosts returning ICMP error messages in
+              response to broadcast datagrams.  For example, a broadcast
+              UDP segment to a non-existent port could trigger a flood
+              of ICMP Destination Unreachable datagrams from all
+              machines that do not have a client for that destination
+              port.  On a large Ethernet, the resulting collisions can
+              render the network useless for a second or more.
+
+              Every datagram that is broadcast on the connected network
+              should have a valid IP broadcast address as its IP
+              destination (see Section 3.3.6).  However, some hosts
+              violate this rule.  To be certain to detect broadcast
+              datagrams, therefore, hosts are required to check for a
+              link-layer broadcast as well as an IP-layer broadcast
+              address.
+
+         IMPLEMENTATION:
+              This requires that the link layer inform the IP layer when
+              a link-layer broadcast datagram has been received; see
+              Section 2.4.
+
+         3.2.2.1  Destination Unreachable: RFC-792
+
+            The following additional codes are hereby defined:
+
+                    6 = destination network unknown
+
+
+
+Internet Engineering Task Force                                [Page 39]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+                    7 = destination host unknown
+
+                    8 = source host isolated
+
+                    9 = communication with destination network
+                            administratively prohibited
+
+                   10 = communication with destination host
+                            administratively prohibited
+
+                   11 = network unreachable for type of service
+
+                   12 = host unreachable for type of service
+
+            A host SHOULD generate Destination Unreachable messages with
+            code:
+
+            2    (Protocol Unreachable), when the designated transport
+                 protocol is not supported; or
+
+            3    (Port Unreachable), when the designated transport
+                 protocol (e.g., UDP) is unable to demultiplex the
+                 datagram but has no protocol mechanism to inform the
+                 sender.
+
+            A Destination Unreachable message that is received MUST be
+            reported to the transport layer.  The transport layer SHOULD
+            use the information appropriately; for example, see Sections
+            4.1.3.3, 4.2.3.9, and 4.2.4 below.  A transport protocol
+            that has its own mechanism for notifying the sender that a
+            port is unreachable (e.g., TCP, which sends RST segments)
+            MUST nevertheless accept an ICMP Port Unreachable for the
+            same purpose.
+
+            A Destination Unreachable message that is received with code
+            0 (Net), 1 (Host), or 5 (Bad Source Route) may result from a
+            routing transient and MUST therefore be interpreted as only
+            a hint, not proof, that the specified destination is
+            unreachable [IP:11].  For example, it MUST NOT be used as
+            proof of a dead gateway (see Section 3.3.1).
+
+         3.2.2.2  Redirect: RFC-792
+
+            A host SHOULD NOT send an ICMP Redirect message; Redirects
+            are to be sent only by gateways.
+
+            A host receiving a Redirect message MUST update its routing
+            information accordingly.  Every host MUST be prepared to
+
+
+
+Internet Engineering Task Force                                [Page 40]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+            accept both Host and Network Redirects and to process them
+            as described in Section 3.3.1.2 below.
+
+            A Redirect message SHOULD be silently discarded if the new
+            gateway address it specifies is not on the same connected
+            (sub-) net through which the Redirect arrived [INTRO:2,
+            Appendix A], or if the source of the Redirect is not the
+            current first-hop gateway for the specified destination (see
+            Section 3.3.1).
+
+         3.2.2.3  Source Quench: RFC-792
+
+            A host MAY send a Source Quench message if it is
+            approaching, or has reached, the point at which it is forced
+            to discard incoming datagrams due to a shortage of
+            reassembly buffers or other resources.  See Section 2.2.3 of
+            [INTRO:2] for suggestions on when to send Source Quench.
+
+            If a Source Quench message is received, the IP layer MUST
+            report it to the transport layer (or ICMP processing). In
+            general, the transport or application layer SHOULD implement
+            a mechanism to respond to Source Quench for any protocol
+            that can send a sequence of datagrams to the same
+            destination and which can reasonably be expected to maintain
+            enough state information to make this feasible.  See Section
+            4 for the handling of Source Quench by TCP and UDP.
+
+            DISCUSSION:
+                 A Source Quench may be generated by the target host or
+                 by some gateway in the path of a datagram.  The host
+                 receiving a Source Quench should throttle itself back
+                 for a period of time, then gradually increase the
+                 transmission rate again.  The mechanism to respond to
+                 Source Quench may be in the transport layer (for
+                 connection-oriented protocols like TCP) or in the
+                 application layer (for protocols that are built on top
+                 of UDP).
+
+                 A mechanism has been proposed [IP:14] to make the IP
+                 layer respond directly to Source Quench by controlling
+                 the rate at which datagrams are sent, however, this
+                 proposal is currently experimental and not currently
+                 recommended.
+
+         3.2.2.4  Time Exceeded: RFC-792
+
+            An incoming Time Exceeded message MUST be passed to the
+            transport layer.
+
+
+
+Internet Engineering Task Force                                [Page 41]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+            DISCUSSION:
+                 A gateway will send a Time Exceeded Code 0 (In Transit)
+                 message when it discards a datagram due to an expired
+                 TTL field.  This indicates either a gateway routing
+                 loop or too small an initial TTL value.
+
+                 A host may receive a Time Exceeded Code 1 (Reassembly
+                 Timeout) message from a destination host that has timed
+                 out and discarded an incomplete datagram; see Section
+                 3.3.2 below.  In the future, receipt of this message
+                 might be part of some "MTU discovery" procedure, to
+                 discover the maximum datagram size that can be sent on
+                 the path without fragmentation.
+
+         3.2.2.5  Parameter Problem: RFC-792
+
+            A host SHOULD generate Parameter Problem messages.  An
+            incoming Parameter Problem message MUST be passed to the
+            transport layer, and it MAY be reported to the user.
+
+            DISCUSSION:
+                 The ICMP Parameter Problem message is sent to the
+                 source host for any problem not specifically covered by
+                 another ICMP message.  Receipt of a Parameter Problem
+                 message generally indicates some local or remote
+                 implementation error.
+
+            A new variant on the Parameter Problem message is hereby
+            defined:
+              Code 1 = required option is missing.
+
+            DISCUSSION:
+                 This variant is currently in use in the military
+                 community for a missing security option.
+
+         3.2.2.6  Echo Request/Reply: RFC-792
+
+            Every host MUST implement an ICMP Echo server function that
+            receives Echo Requests and sends corresponding Echo Replies.
+            A host SHOULD also implement an application-layer interface
+            for sending an Echo Request and receiving an Echo Reply, for
+            diagnostic purposes.
+
+            An ICMP Echo Request destined to an IP broadcast or IP
+            multicast address MAY be silently discarded.
+
+
+
+
+
+
+Internet Engineering Task Force                                [Page 42]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+            DISCUSSION:
+                 This neutral provision results from a passionate debate
+                 between those who feel that ICMP Echo to a broadcast
+                 address provides a valuable diagnostic capability and
+                 those who feel that misuse of this feature can too
+                 easily create packet storms.
+
+            The IP source address in an ICMP Echo Reply MUST be the same
+            as the specific-destination address (defined in Section
+            3.2.1.3) of the corresponding ICMP Echo Request message.
+
+            Data received in an ICMP Echo Request MUST be entirely
+            included in the resulting Echo Reply.  However, if sending
+            the Echo Reply requires intentional fragmentation that is
+            not implemented, the datagram MUST be truncated to maximum
+            transmission size (see Section 3.3.3) and sent.
+
+            Echo Reply messages MUST be passed to the ICMP user
+            interface, unless the corresponding Echo Request originated
+            in the IP layer.
+
+            If a Record Route and/or Time Stamp option is received in an
+            ICMP Echo Request, this option (these options) SHOULD be
+            updated to include the current host and included in the IP
+            header of the Echo Reply message, without "truncation".
+            Thus, the recorded route will be for the entire round trip.
+
+            If a Source Route option is received in an ICMP Echo
+            Request, the return route MUST be reversed and used as a
+            Source Route option for the Echo Reply message.
+
+         3.2.2.7  Information Request/Reply: RFC-792
+
+            A host SHOULD NOT implement these messages.
+
+            DISCUSSION:
+                 The Information Request/Reply pair was intended to
+                 support self-configuring systems such as diskless
+                 workstations, to allow them to discover their IP
+                 network numbers at boot time.  However, the RARP and
+                 BOOTP protocols provide better mechanisms for a host to
+                 discover its own IP address.
+
+         3.2.2.8  Timestamp and Timestamp Reply: RFC-792
+
+            A host MAY implement Timestamp and Timestamp Reply.  If they
+            are implemented, the following rules MUST be followed.
+
+
+
+
+Internet Engineering Task Force                                [Page 43]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+            o    The ICMP Timestamp server function returns a Timestamp
+                 Reply to every Timestamp message that is received.  If
+                 this function is implemented, it SHOULD be designed for
+                 minimum variability in delay (e.g., implemented in the
+                 kernel to avoid delay in scheduling a user process).
+
+            The following cases for Timestamp are to be handled
+            according to the corresponding rules for ICMP Echo:
+
+            o    An ICMP Timestamp Request message to an IP broadcast or
+                 IP multicast address MAY be silently discarded.
+
+            o    The IP source address in an ICMP Timestamp Reply MUST
+                 be the same as the specific-destination address of the
+                 corresponding Timestamp Request message.
+
+            o    If a Source-route option is received in an ICMP Echo
+                 Request, the return route MUST be reversed and used as
+                 a Source Route option for the Timestamp Reply message.
+
+            o    If a Record Route and/or Timestamp option is received
+                 in a Timestamp Request, this (these) option(s) SHOULD
+                 be updated to include the current host and included in
+                 the IP header of the Timestamp Reply message.
+
+            o    Incoming Timestamp Reply messages MUST be passed up to
+                 the ICMP user interface.
+
+            The preferred form for a timestamp value (the "standard
+            value") is in units of milliseconds since midnight Universal
+            Time.  However, it may be difficult to provide this value
+            with millisecond resolution.  For example, many systems use
+            clocks that update only at line frequency, 50 or 60 times
+            per second.  Therefore, some latitude is allowed in a
+            "standard value":
+
+            (a)  A "standard value" MUST be updated at least 15 times
+                 per second (i.e., at most the six low-order bits of the
+                 value may be undefined).
+
+            (b)  The accuracy of a "standard value" MUST approximate
+                 that of operator-set CPU clocks, i.e., correct within a
+                 few minutes.
+
+
+
+
+
+
+
+
+Internet Engineering Task Force                                [Page 44]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+         3.2.2.9  Address Mask Request/Reply: RFC-950
+
+            A host MUST support the first, and MAY implement all three,
+            of the following methods for determining the address mask(s)
+            corresponding to its IP address(es):
+
+            (1)  static configuration information;
+
+            (2)  obtaining the address mask(s) dynamically as a side-
+                 effect of the system initialization process (see
+                 [INTRO:1]); and
+
+            (3)  sending ICMP Address Mask Request(s) and receiving ICMP
+                 Address Mask Reply(s).
+
+            The choice of method to be used in a particular host MUST be
+            configurable.
+
+            When method (3), the use of Address Mask messages, is
+            enabled, then:
+
+            (a)  When it initializes, the host MUST broadcast an Address
+                 Mask Request message on the connected network
+                 corresponding to the IP address.  It MUST retransmit
+                 this message a small number of times if it does not
+                 receive an immediate Address Mask Reply.
+
+            (b)  Until it has received an Address Mask Reply, the host
+                 SHOULD assume a mask appropriate for the address class
+                 of the IP address, i.e., assume that the connected
+                 network is not subnetted.
+
+            (c)  The first Address Mask Reply message received MUST be
+                 used to set the address mask corresponding to the
+                 particular local IP address.  This is true even if the
+                 first Address Mask Reply message is "unsolicited", in
+                 which case it will have been broadcast and may arrive
+                 after the host has ceased to retransmit Address Mask
+                 Requests.  Once the mask has been set by an Address
+                 Mask Reply, later Address Mask Reply messages MUST be
+                 (silently) ignored.
+
+            Conversely, if Address Mask messages are disabled, then no
+            ICMP Address Mask Requests will be sent, and any ICMP
+            Address Mask Replies received for that local IP address MUST
+            be (silently) ignored.
+
+            A host SHOULD make some reasonableness check on any address
+
+
+
+Internet Engineering Task Force                                [Page 45]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+            mask it installs; see IMPLEMENTATION section below.
+
+            A system MUST NOT send an Address Mask Reply unless it is an
+            authoritative agent for address masks.  An authoritative
+            agent may be a host or a gateway, but it MUST be explicitly
+            configured as a address mask agent.  Receiving an address
+            mask via an Address Mask Reply does not give the receiver
+            authority and MUST NOT be used as the basis for issuing
+            Address Mask Replies.
+
+            With a statically configured address mask, there SHOULD be
+            an additional configuration flag that determines whether the
+            host is to act as an authoritative agent for this mask,
+            i.e., whether it will answer Address Mask Request messages
+            using this mask.
+
+            If it is configured as an agent, the host MUST broadcast an
+            Address Mask Reply for the mask on the appropriate interface
+            when it initializes.
+
+            See "System Initialization" in [INTRO:1] for more
+            information about the use of Address Mask Request/Reply
+            messages.
+
+            DISCUSSION
+                 Hosts that casually send Address Mask Replies with
+                 invalid address masks have often been a serious
+                 nuisance.  To prevent this, Address Mask Replies ought
+                 to be sent only by authoritative agents that have been
+                 selected by explicit administrative action.
+
+                 When an authoritative agent receives an Address Mask
+                 Request message, it will send a unicast Address Mask
+                 Reply to the source IP address.  If the network part of
+                 this address is zero (see (a) and (b) in 3.2.1.3), the
+                 Reply will be broadcast.
+
+                 Getting no reply to its Address Mask Request messages,
+                 a host will assume there is no agent and use an
+                 unsubnetted mask, but the agent may be only temporarily
+                 unreachable.  An agent will broadcast an unsolicited
+                 Address Mask Reply whenever it initializes, in order to
+                 update the masks of all hosts that have initialized in
+                 the meantime.
+
+            IMPLEMENTATION:
+                 The following reasonableness check on an address mask
+                 is suggested: the mask is not all 1 bits, and it is
+
+
+
+Internet Engineering Task Force                                [Page 46]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+                 either zero or else the 8 highest-order bits are on.
+
+      3.2.3  Internet Group Management Protocol IGMP
+
+         IGMP [IP:4] is a protocol used between hosts and gateways on a
+         single network to establish hosts' membership in particular
+         multicast groups.  The gateways use this information, in
+         conjunction with a multicast routing protocol, to support IP
+         multicasting across the Internet.
+
+         At this time, implementation of IGMP is OPTIONAL; see Section
+         3.3.7 for more information.  Without IGMP, a host can still
+         participate in multicasting local to its connected networks.
+
+   3.3  SPECIFIC ISSUES
+
+      3.3.1  Routing Outbound Datagrams
+
+         The IP layer chooses the correct next hop for each datagram it
+         sends.  If the destination is on a connected network, the
+         datagram is sent directly to the destination host; otherwise,
+         it has to be routed to a gateway on a connected network.
+
+         3.3.1.1  Local/Remote Decision
+
+            To decide if the destination is on a connected network, the
+            following algorithm MUST be used [see IP:3]:
+
+            (a)  The address mask (particular to a local IP address for
+                 a multihomed host) is a 32-bit mask that selects the
+                 network number and subnet number fields of the
+                 corresponding IP address.
+
+            (b)  If the IP destination address bits extracted by the
+                 address mask match the IP source address bits extracted
+                 by the same mask, then the destination is on the
+                 corresponding connected network, and the datagram is to
+                 be transmitted directly to the destination host.
+
+            (c)  If not, then the destination is accessible only through
+                 a gateway.  Selection of a gateway is described below
+                 (3.3.1.2).
+
+            A special-case destination address is handled as follows:
+
+            *    For a limited broadcast or a multicast address, simply
+                 pass the datagram to the link layer for the appropriate
+                 interface.
+
+
+
+Internet Engineering Task Force                                [Page 47]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+            *    For a (network or subnet) directed broadcast, the
+                 datagram can use the standard routing algorithms.
+
+            The host IP layer MUST operate correctly in a minimal
+            network environment, and in particular, when there are no
+            gateways.  For example, if the IP layer of a host insists on
+            finding at least one gateway to initialize, the host will be
+            unable to operate on a single isolated broadcast net.
+
+         3.3.1.2  Gateway Selection
+
+            To efficiently route a series of datagrams to the same
+            destination, the source host MUST keep a "route cache" of
+            mappings to next-hop gateways.  A host uses the following
+            basic algorithm on this cache to route a datagram; this
+            algorithm is designed to put the primary routing burden on
+            the gateways [IP:11].
+
+            (a)  If the route cache contains no information for a
+                 particular destination, the host chooses a "default"
+                 gateway and sends the datagram to it.  It also builds a
+                 corresponding Route Cache entry.
+
+            (b)  If that gateway is not the best next hop to the
+                 destination, the gateway will forward the datagram to
+                 the best next-hop gateway and return an ICMP Redirect
+                 message to the source host.
+
+            (c)  When it receives a Redirect, the host updates the
+                 next-hop gateway in the appropriate route cache entry,
+                 so later datagrams to the same destination will go
+                 directly to the best gateway.
+
+            Since the subnet mask appropriate to the destination address
+            is generally not known, a Network Redirect message SHOULD be
+            treated identically to a Host Redirect message; i.e., the
+            cache entry for the destination host (only) would be updated
+            (or created, if an entry for that host did not exist) for
+            the new gateway.
+
+            DISCUSSION:
+                 This recommendation is to protect against gateways that
+                 erroneously send Network Redirects for a subnetted
+                 network, in violation of the gateway requirements
+                 [INTRO:2].
+
+            When there is no route cache entry for the destination host
+            address (and the destination is not on the connected
+
+
+
+Internet Engineering Task Force                                [Page 48]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+            network), the IP layer MUST pick a gateway from its list of
+            "default" gateways.  The IP layer MUST support multiple
+            default gateways.
+
+            As an extra feature, a host IP layer MAY implement a table
+            of "static routes".  Each such static route MAY include a
+            flag specifying whether it may be overridden by ICMP
+            Redirects.
+
+            DISCUSSION:
+                 A host generally needs to know at least one default
+                 gateway to get started.  This information can be
+                 obtained from a configuration file or else from the
+                 host startup sequence, e.g., the BOOTP protocol (see
+                 [INTRO:1]).
+
+                 It has been suggested that a host can augment its list
+                 of default gateways by recording any new gateways it
+                 learns about.  For example, it can record every gateway
+                 to which it is ever redirected.  Such a feature, while
+                 possibly useful in some circumstances, may cause
+                 problems in other cases (e.g., gateways are not all
+                 equal), and it is not recommended.
+
+                 A static route is typically a particular preset mapping
+                 from destination host or network into a particular
+                 next-hop gateway; it might also depend on the Type-of-
+                 Service (see next section).  Static routes would be set
+                 up by system administrators to override the normal
+                 automatic routing mechanism, to handle exceptional
+                 situations.  However, any static routing information is
+                 a potential source of failure as configurations change
+                 or equipment fails.
+
+         3.3.1.3  Route Cache
+
+            Each route cache entry needs to include the following
+            fields:
+
+            (1)  Local IP address (for a multihomed host)
+
+            (2)  Destination IP address
+
+            (3)  Type(s)-of-Service
+
+            (4)  Next-hop gateway IP address
+
+            Field (2) MAY be the full IP address of the destination
+
+
+
+Internet Engineering Task Force                                [Page 49]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+            host, or only the destination network number.  Field (3),
+            the TOS, SHOULD be included.
+
+            See Section 3.3.4.2 for a discussion of the implications of
+            multihoming for the lookup procedure in this cache.
+
+            DISCUSSION:
+                 Including the Type-of-Service field in the route cache
+                 and considering it in the host route algorithm will
+                 provide the necessary mechanism for the future when
+                 Type-of-Service routing is commonly used in the
+                 Internet.  See Section 3.2.1.6.
+
+                 Each route cache entry defines the endpoints of an
+                 Internet path.  Although the connecting path may change
+                 dynamically in an arbitrary way, the transmission
+                 characteristics of the path tend to remain
+                 approximately constant over a time period longer than a
+                 single typical host-host transport connection.
+                 Therefore, a route cache entry is a natural place to
+                 cache data on the properties of the path.  Examples of
+                 such properties might be the maximum unfragmented
+                 datagram size (see Section 3.3.3), or the average
+                 round-trip delay measured by a transport protocol.
+                 This data will generally be both gathered and used by a
+                 higher layer protocol, e.g., by TCP, or by an
+                 application using UDP.  Experiments are currently in
+                 progress on caching path properties in this manner.
+
+                 There is no consensus on whether the route cache should
+                 be keyed on destination host addresses alone, or allow
+                 both host and network addresses.  Those who favor the
+                 use of only host addresses argue that:
+
+                 (1)  As required in Section 3.3.1.2, Redirect messages
+                      will generally result in entries keyed on
+                      destination host addresses; the simplest and most
+                      general scheme would be to use host addresses
+                      always.
+
+                 (2)  The IP layer may not always know the address mask
+                      for a network address in a complex subnetted
+                      environment.
+
+                 (3)  The use of only host addresses allows the
+                      destination address to be used as a pure 32-bit
+                      number, which may allow the Internet architecture
+                      to be more easily extended in the future without
+
+
+
+Internet Engineering Task Force                                [Page 50]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+                      any change to the hosts.
+
+                 The opposing view is that allowing a mixture of
+                 destination hosts and networks in the route cache:
+
+                 (1)  Saves memory space.
+
+                 (2)  Leads to a simpler data structure, easily
+                      combining the cache with the tables of default and
+                      static routes (see below).
+
+                 (3)  Provides a more useful place to cache path
+                      properties, as discussed earlier.
+
+
+            IMPLEMENTATION:
+                 The cache needs to be large enough to include entries
+                 for the maximum number of destination hosts that may be
+                 in use at one time.
+
+                 A route cache entry may also include control
+                 information used to choose an entry for replacement.
+                 This might take the form of a "recently used" bit, a
+                 use count, or a last-used timestamp, for example.  It
+                 is recommended that it include the time of last
+                 modification of the entry, for diagnostic purposes.
+
+                 An implementation may wish to reduce the overhead of
+                 scanning the route cache for every datagram to be
+                 transmitted.  This may be accomplished with a hash
+                 table to speed the lookup, or by giving a connection-
+                 oriented transport protocol a "hint" or temporary
+                 handle on the appropriate cache entry, to be passed to
+                 the IP layer with each subsequent datagram.
+
+                 Although we have described the route cache, the lists
+                 of default gateways, and a table of static routes as
+                 conceptually distinct, in practice they may be combined
+                 into a single "routing table" data structure.
+
+         3.3.1.4  Dead Gateway Detection
+
+            The IP layer MUST be able to detect the failure of a "next-
+            hop" gateway that is listed in its route cache and to choose
+            an alternate gateway (see Section 3.3.1.5).
+
+            Dead gateway detection is covered in some detail in RFC-816
+            [IP:11]. Experience to date has not produced a complete
+
+
+
+Internet Engineering Task Force                                [Page 51]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+            algorithm which is totally satisfactory, though it has
+            identified several forbidden paths and promising techniques.
+
+            *    A particular gateway SHOULD NOT be used indefinitely in
+                 the absence of positive indications that it is
+                 functioning.
+
+            *    Active probes such as "pinging" (i.e., using an ICMP
+                 Echo Request/Reply exchange) are expensive and scale
+                 poorly.  In particular, hosts MUST NOT actively check
+                 the status of a first-hop gateway by simply pinging the
+                 gateway continuously.
+
+            *    Even when it is the only effective way to verify a
+                 gateway's status, pinging MUST be used only when
+                 traffic is being sent to the gateway and when there is
+                 no other positive indication to suggest that the
+                 gateway is functioning.
+
+            *    To avoid pinging, the layers above and/or below the
+                 Internet layer SHOULD be able to give "advice" on the
+                 status of route cache entries when either positive
+                 (gateway OK) or negative (gateway dead) information is
+                 available.
+
+
+            DISCUSSION:
+                 If an implementation does not include an adequate
+                 mechanism for detecting a dead gateway and re-routing,
+                 a gateway failure may cause datagrams to apparently
+                 vanish into a "black hole".  This failure can be
+                 extremely confusing for users and difficult for network
+                 personnel to debug.
+
+                 The dead-gateway detection mechanism must not cause
+                 unacceptable load on the host, on connected networks,
+                 or on first-hop gateway(s).  The exact constraints on
+                 the timeliness of dead gateway detection and on
+                 acceptable load may vary somewhat depending on the
+                 nature of the host's mission, but a host generally
+                 needs to detect a failed first-hop gateway quickly
+                 enough that transport-layer connections will not break
+                 before an alternate gateway can be selected.
+
+                 Passing advice from other layers of the protocol stack
+                 complicates the interfaces between the layers, but it
+                 is the preferred approach to dead gateway detection.
+                 Advice can come from almost any part of the IP/TCP
+
+
+
+Internet Engineering Task Force                                [Page 52]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+                 architecture, but it is expected to come primarily from
+                 the transport and link layers.  Here are some possible
+                 sources for gateway advice:
+
+                 o    TCP or any connection-oriented transport protocol
+                      should be able to give negative advice, e.g.,
+                      triggered by excessive retransmissions.
+
+                 o    TCP may give positive advice when (new) data is
+                      acknowledged.  Even though the route may be
+                      asymmetric, an ACK for new data proves that the
+                      acknowleged data must have been transmitted
+                      successfully.
+
+                 o    An ICMP Redirect message from a particular gateway
+                      should be used as positive advice about that
+                      gateway.
+
+                 o    Link-layer information that reliably detects and
+                      reports host failures (e.g., ARPANET Destination
+                      Dead messages) should be used as negative advice.
+
+                 o    Failure to ARP or to re-validate ARP mappings may
+                      be used as negative advice for the corresponding
+                      IP address.
+
+                 o    Packets arriving from a particular link-layer
+                      address are evidence that the system at this
+                      address is alive.  However, turning this
+                      information into advice about gateways requires
+                      mapping the link-layer address into an IP address,
+                      and then checking that IP address against the
+                      gateways pointed to by the route cache.  This is
+                      probably prohibitively inefficient.
+
+                 Note that positive advice that is given for every
+                 datagram received may cause unacceptable overhead in
+                 the implementation.
+
+                 While advice might be passed using required arguments
+                 in all interfaces to the IP layer, some transport and
+                 application layer protocols cannot deduce the correct
+                 advice.  These interfaces must therefore allow a
+                 neutral value for advice, since either always-positive
+                 or always-negative advice leads to incorrect behavior.
+
+                 There is another technique for dead gateway detection
+                 that has been commonly used but is not recommended.
+
+
+
+Internet Engineering Task Force                                [Page 53]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+                 This technique depends upon the host passively
+                 receiving ("wiretapping") the Interior Gateway Protocol
+                 (IGP) datagrams that the gateways are broadcasting to
+                 each other.  This approach has the drawback that a host
+                 needs to recognize all the interior gateway protocols
+                 that gateways may use (see [INTRO:2]).  In addition, it
+                 only works on a broadcast network.
+
+                 At present, pinging (i.e., using ICMP Echo messages) is
+                 the mechanism for gateway probing when absolutely
+                 required.  A successful ping guarantees that the
+                 addressed interface and its associated machine are up,
+                 but it does not guarantee that the machine is a gateway
+                 as opposed to a host.  The normal inference is that if
+                 a Redirect or other evidence indicates that a machine
+                 was a gateway, successful pings will indicate that the
+                 machine is still up and hence still a gateway.
+                 However, since a host silently discards packets that a
+                 gateway would forward or redirect, this assumption
+                 could sometimes fail.  To avoid this problem, a new
+                 ICMP message under development will ask "are you a
+                 gateway?"
+
+            IMPLEMENTATION:
+                 The following specific algorithm has been suggested:
+
+                 o    Associate a "reroute timer" with each gateway
+                      pointed to by the route cache.  Initialize the
+                      timer to a value Tr, which must be small enough to
+                      allow detection of a dead gateway before transport
+                      connections time out.
+
+                 o    Positive advice would reset the reroute timer to
+                      Tr.  Negative advice would reduce or zero the
+                      reroute timer.
+
+                 o    Whenever the IP layer used a particular gateway to
+                      route a datagram, it would check the corresponding
+                      reroute timer.  If the timer had expired (reached
+                      zero), the IP layer would send a ping to the
+                      gateway, followed immediately by the datagram.
+
+                 o    The ping (ICMP Echo) would be sent again if
+                      necessary, up to N times.  If no ping reply was
+                      received in N tries, the gateway would be assumed
+                      to have failed, and a new first-hop gateway would
+                      be chosen for all cache entries pointing to the
+                      failed gateway.
+
+
+
+Internet Engineering Task Force                                [Page 54]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+                 Note that the size of Tr is inversely related to the
+                 amount of advice available.  Tr should be large enough
+                 to insure that:
+
+                 *    Any pinging will be at a low level (e.g., <10%) of
+                      all packets sent to a gateway from the host, AND
+
+                 *    pinging is infrequent (e.g., every 3 minutes)
+
+                 Since the recommended algorithm is concerned with the
+                 gateways pointed to by route cache entries, rather than
+                 the cache entries themselves, a two level data
+                 structure (perhaps coordinated with ARP or similar
+                 caches) may be desirable for implementing a route
+                 cache.
+
+         3.3.1.5  New Gateway Selection
+
+            If the failed gateway is not the current default, the IP
+            layer can immediately switch to a default gateway.  If it is
+            the current default that failed, the IP layer MUST select a
+            different default gateway (assuming more than one default is
+            known) for the failed route and for establishing new routes.
+
+            DISCUSSION:
+                 When a gateway does fail, the other gateways on the
+                 connected network will learn of the failure through
+                 some inter-gateway routing protocol.  However, this
+                 will not happen instantaneously, since gateway routing
+                 protocols typically have a settling time of 30-60
+                 seconds.  If the host switches to an alternative
+                 gateway before the gateways have agreed on the failure,
+                 the new target gateway will probably forward the
+                 datagram to the failed gateway and send a Redirect back
+                 to the host pointing to the failed gateway (!).  The
+                 result is likely to be a rapid oscillation in the
+                 contents of the host's route cache during the gateway
+                 settling period.  It has been proposed that the dead-
+                 gateway logic should include some hysteresis mechanism
+                 to prevent such oscillations.  However, experience has
+                 not shown any harm from such oscillations, since
+                 service cannot be restored to the host until the
+                 gateways' routing information does settle down.
+
+            IMPLEMENTATION:
+                 One implementation technique for choosing a new default
+                 gateway is to simply round-robin among the default
+                 gateways in the host's list.  Another is to rank the
+
+
+
+Internet Engineering Task Force                                [Page 55]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+                 gateways in priority order, and when the current
+                 default gateway is not the highest priority one, to
+                 "ping" the higher-priority gateways slowly to detect
+                 when they return to service.  This pinging can be at a
+                 very low rate, e.g., 0.005 per second.
+
+         3.3.1.6  Initialization
+
+            The following information MUST be configurable:
+
+            (1)  IP address(es).
+
+            (2)  Address mask(s).
+
+            (3)  A list of default gateways, with a preference level.
+
+            A manual method of entering this configuration data MUST be
+            provided.  In addition, a variety of methods can be used to
+            determine this information dynamically; see the section on
+            "Host Initialization" in [INTRO:1].
+
+            DISCUSSION:
+                 Some host implementations use "wiretapping" of gateway
+                 protocols on a broadcast network to learn what gateways
+                 exist.  A standard method for default gateway discovery
+                 is under development.
+
+      3.3.2  Reassembly
+
+         The IP layer MUST implement reassembly of IP datagrams.
+
+         We designate the largest datagram size that can be reassembled
+         by EMTU_R ("Effective MTU to receive"); this is sometimes
+         called the "reassembly buffer size".  EMTU_R MUST be greater
+         than or equal to 576, SHOULD be either configurable or
+         indefinite, and SHOULD be greater than or equal to the MTU of
+         the connected network(s).
+
+         DISCUSSION:
+              A fixed EMTU_R limit should not be built into the code
+              because some application layer protocols require EMTU_R
+              values larger than 576.
+
+         IMPLEMENTATION:
+              An implementation may use a contiguous reassembly buffer
+              for each datagram, or it may use a more complex data
+              structure that places no definite limit on the reassembled
+              datagram size; in the latter case, EMTU_R is said to be
+
+
+
+Internet Engineering Task Force                                [Page 56]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+              "indefinite".
+
+              Logically, reassembly is performed by simply copying each
+              fragment into the packet buffer at the proper offset.
+              Note that fragments may overlap if successive
+              retransmissions use different packetizing but the same
+              reassembly Id.
+
+              The tricky part of reassembly is the bookkeeping to
+              determine when all bytes of the datagram have been
+              reassembled.  We recommend Clark's algorithm [IP:10] that
+              requires no additional data space for the bookkeeping.
+              However, note that, contrary to [IP:10], the first
+              fragment header needs to be saved for inclusion in a
+              possible ICMP Time Exceeded (Reassembly Timeout) message.
+
+         There MUST be a mechanism by which the transport layer can
+         learn MMS_R, the maximum message size that can be received and
+         reassembled in an IP datagram (see GET_MAXSIZES calls in
+         Section 3.4).  If EMTU_R is not indefinite, then the value of
+         MMS_R is given by:
+
+            MMS_R = EMTU_R - 20
+
+         since 20 is the minimum size of an IP header.
+
+         There MUST be a reassembly timeout.  The reassembly timeout
+         value SHOULD be a fixed value, not set from the remaining TTL.
+         It is recommended that the value lie between 60 seconds and 120
+         seconds.  If this timeout expires, the partially-reassembled
+         datagram MUST be discarded and an ICMP Time Exceeded message
+         sent to the source host (if fragment zero has been received).
+
+         DISCUSSION:
+              The IP specification says that the reassembly timeout
+              should be the remaining TTL from the IP header, but this
+              does not work well because gateways generally treat TTL as
+              a simple hop count rather than an elapsed time.  If the
+              reassembly timeout is too small, datagrams will be
+              discarded unnecessarily, and communication may fail.  The
+              timeout needs to be at least as large as the typical
+              maximum delay across the Internet.  A realistic minimum
+              reassembly timeout would be 60 seconds.
+
+              It has been suggested that a cache might be kept of
+              round-trip times measured by transport protocols for
+              various destinations, and that these values might be used
+              to dynamically determine a reasonable reassembly timeout
+
+
+
+Internet Engineering Task Force                                [Page 57]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+              value.  Further investigation of this approach is
+              required.
+
+              If the reassembly timeout is set too high, buffer
+              resources in the receiving host will be tied up too long,
+              and the MSL (Maximum Segment Lifetime) [TCP:1] will be
+              larger than necessary.  The MSL controls the maximum rate
+              at which fragmented datagrams can be sent using distinct
+              values of the 16-bit Ident field; a larger MSL lowers the
+              maximum rate.  The TCP specification [TCP:1] arbitrarily
+              assumes a value of 2 minutes for MSL.  This sets an upper
+              limit on a reasonable reassembly timeout value.
+
+      3.3.3  Fragmentation
+
+         Optionally, the IP layer MAY implement a mechanism to fragment
+         outgoing datagrams intentionally.
+
+         We designate by EMTU_S ("Effective MTU for sending") the
+         maximum IP datagram size that may be sent, for a particular
+         combination of IP source and destination addresses and perhaps
+         TOS.
+
+         A host MUST implement a mechanism to allow the transport layer
+         to learn MMS_S, the maximum transport-layer message size that
+         may be sent for a given {source, destination, TOS} triplet (see
+         GET_MAXSIZES call in Section 3.4).  If no local fragmentation
+         is performed, the value of MMS_S will be:
+
+            MMS_S = EMTU_S - <IP header size>
+
+         and EMTU_S must be less than or equal to the MTU of the network
+         interface corresponding to the source address of the datagram.
+         Note that <IP header size> in this equation will be 20, unless
+         the IP reserves space to insert IP options for its own purposes
+         in addition to any options inserted by the transport layer.
+
+         A host that does not implement local fragmentation MUST ensure
+         that the transport layer (for TCP) or the application layer
+         (for UDP) obtains MMS_S from the IP layer and does not send a
+         datagram exceeding MMS_S in size.
+
+         It is generally desirable to avoid local fragmentation and to
+         choose EMTU_S low enough to avoid fragmentation in any gateway
+         along the path.  In the absence of actual knowledge of the
+         minimum MTU along the path, the IP layer SHOULD use
+         EMTU_S <= 576 whenever the destination address is not on a
+         connected network, and otherwise use the connected network's
+
+
+
+Internet Engineering Task Force                                [Page 58]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+         MTU.
+
+         The MTU of each physical interface MUST be configurable.
+
+         A host IP layer implementation MAY have a configuration flag
+         "All-Subnets-MTU", indicating that the MTU of the connected
+         network is to be used for destinations on different subnets
+         within the same network, but not for other networks.  Thus,
+         this flag causes the network class mask, rather than the subnet
+         address mask, to be used to choose an EMTU_S.  For a multihomed
+         host, an "All-Subnets-MTU" flag is needed for each network
+         interface.
+
+         DISCUSSION:
+              Picking the correct datagram size to use when sending data
+              is a complex topic [IP:9].
+
+              (a)  In general, no host is required to accept an IP
+                   datagram larger than 576 bytes (including header and
+                   data), so a host must not send a larger datagram
+                   without explicit knowledge or prior arrangement with
+                   the destination host.  Thus, MMS_S is only an upper
+                   bound on the datagram size that a transport protocol
+                   may send; even when MMS_S exceeds 556, the transport
+                   layer must limit its messages to 556 bytes in the
+                   absence of other knowledge about the destination
+                   host.
+
+              (b)  Some transport protocols (e.g., TCP) provide a way to
+                   explicitly inform the sender about the largest
+                   datagram the other end can receive and reassemble
+                   [IP:7].  There is no corresponding mechanism in the
+                   IP layer.
+
+                   A transport protocol that assumes an EMTU_R larger
+                   than 576 (see Section 3.3.2), can send a datagram of
+                   this larger size to another host that implements the
+                   same protocol.
+
+              (c)  Hosts should ideally limit their EMTU_S for a given
+                   destination to the minimum MTU of all the networks
+                   along the path, to avoid any fragmentation.  IP
+                   fragmentation, while formally correct, can create a
+                   serious transport protocol performance problem,
+                   because loss of a single fragment means all the
+                   fragments in the segment must be retransmitted
+                   [IP:9].
+
+
+
+
+Internet Engineering Task Force                                [Page 59]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+              Since nearly all networks in the Internet currently
+              support an MTU of 576 or greater, we strongly recommend
+              the use of 576 for datagrams sent to non-local networks.
+
+              It has been suggested that a host could determine the MTU
+              over a given path by sending a zero-offset datagram
+              fragment and waiting for the receiver to time out the
+              reassembly (which cannot complete!) and return an ICMP
+              Time Exceeded message.  This message would include the
+              largest remaining fragment header in its body.  More
+              direct mechanisms are being experimented with, but have
+              not yet been adopted (see e.g., RFC-1063).
+
+      3.3.4  Local Multihoming
+
+         3.3.4.1  Introduction
+
+            A multihomed host has multiple IP addresses, which we may
+            think of as "logical interfaces".  These logical interfaces
+            may be associated with one or more physical interfaces, and
+            these physical interfaces may be connected to the same or
+            different networks.
+
+            Here are some important cases of multihoming:
+
+            (a)  Multiple Logical Networks
+
+                 The Internet architects envisioned that each physical
+                 network would have a single unique IP network (or
+                 subnet) number.  However, LAN administrators have
+                 sometimes found it useful to violate this assumption,
+                 operating a LAN with multiple logical networks per
+                 physical connected network.
+
+                 If a host connected to such a physical network is
+                 configured to handle traffic for each of N different
+                 logical networks, then the host will have N logical
+                 interfaces.  These could share a single physical
+                 interface, or might use N physical interfaces to the
+                 same network.
+
+            (b)  Multiple Logical Hosts
+
+                 When a host has multiple IP addresses that all have the
+                 same <Network-number> part (and the same <Subnet-
+                 number> part, if any), the logical interfaces are known
+                 as "logical hosts".  These logical interfaces might
+                 share a single physical interface or might use separate
+
+
+
+Internet Engineering Task Force                                [Page 60]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+                 physical interfaces to the same physical network.
+
+            (c)  Simple Multihoming
+
+                 In this case, each logical interface is mapped into a
+                 separate physical interface and each physical interface
+                 is connected to a different physical network.  The term
+                 "multihoming" was originally applied only to this case,
+                 but it is now applied more generally.
+
+                 A host with embedded gateway functionality will
+                 typically fall into the simple multihoming case.  Note,
+                 however, that a host may be simply multihomed without
+                 containing an embedded gateway, i.e., without
+                 forwarding datagrams from one connected network to
+                 another.
+
+                 This case presents the most difficult routing problems.
+                 The choice of interface (i.e., the choice of first-hop
+                 network) may significantly affect performance or even
+                 reachability of remote parts of the Internet.
+
+
+            Finally, we note another possibility that is NOT
+            multihoming:  one logical interface may be bound to multiple
+            physical interfaces, in order to increase the reliability or
+            throughput between directly connected machines by providing
+            alternative physical paths between them.  For instance, two
+            systems might be connected by multiple point-to-point links.
+            We call this "link-layer multiplexing".  With link-layer
+            multiplexing, the protocols above the link layer are unaware
+            that multiple physical interfaces are present; the link-
+            layer device driver is responsible for multiplexing and
+            routing packets across the physical interfaces.
+
+            In the Internet protocol architecture, a transport protocol
+            instance ("entity") has no address of its own, but instead
+            uses a single Internet Protocol (IP) address.  This has
+            implications for the IP, transport, and application layers,
+            and for the interfaces between them.  In particular, the
+            application software may have to be aware of the multiple IP
+            addresses of a multihomed host; in other cases, the choice
+            can be made within the network software.
+
+         3.3.4.2  Multihoming Requirements
+
+            The following general rules apply to the selection of an IP
+            source address for sending a datagram from a multihomed
+
+
+
+Internet Engineering Task Force                                [Page 61]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+            host.
+
+            (1)  If the datagram is sent in response to a received
+                 datagram, the source address for the response SHOULD be
+                 the specific-destination address of the request.  See
+                 Sections 4.1.3.5 and 4.2.3.7 and the "General Issues"
+                 section of [INTRO:1] for more specific requirements on
+                 higher layers.
+
+                 Otherwise, a source address must be selected.
+
+            (2)  An application MUST be able to explicitly specify the
+                 source address for initiating a connection or a
+                 request.
+
+            (3)  In the absence of such a specification, the networking
+                 software MUST choose a source address.  Rules for this
+                 choice are described below.
+
+
+            There are two key requirement issues related to multihoming:
+
+            (A)  A host MAY silently discard an incoming datagram whose
+                 destination address does not correspond to the physical
+                 interface through which it is received.
+
+            (B)  A host MAY restrict itself to sending (non-source-
+                 routed) IP datagrams only through the physical
+                 interface that corresponds to the IP source address of
+                 the datagrams.
+
+
+            DISCUSSION:
+                 Internet host implementors have used two different
+                 conceptual models for multihoming, briefly summarized
+                 in the following discussion.  This document takes no
+                 stand on which model is preferred; each seems to have a
+                 place.  This ambivalence is reflected in the issues (A)
+                 and (B) being optional.
+
+                 o    Strong ES Model
+
+                      The Strong ES (End System, i.e., host) model
+                      emphasizes the host/gateway (ES/IS) distinction,
+                      and would therefore substitute MUST for MAY in
+                      issues (A) and (B) above.  It tends to model a
+                      multihomed host as a set of logical hosts within
+                      the same physical host.
+
+
+
+Internet Engineering Task Force                                [Page 62]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+                      With respect to (A), proponents of the Strong ES
+                      model note that automatic Internet routing
+                      mechanisms could not route a datagram to a
+                      physical interface that did not correspond to the
+                      destination address.
+
+                      Under the Strong ES model, the route computation
+                      for an outgoing datagram is the mapping:
+
+                         route(src IP addr, dest IP addr, TOS)
+                                                        -> gateway
+
+                      Here the source address is included as a parameter
+                      in order to select a gateway that is directly
+                      reachable on the corresponding physical interface.
+                      Note that this model logically requires that in
+                      general there be at least one default gateway, and
+                      preferably multiple defaults, for each IP source
+                      address.
+
+                 o    Weak ES Model
+
+                      This view de-emphasizes the ES/IS distinction, and
+                      would therefore substitute MUST NOT for MAY in
+                      issues (A) and (B).  This model may be the more
+                      natural one for hosts that wiretap gateway routing
+                      protocols, and is necessary for hosts that have
+                      embedded gateway functionality.
+
+                      The Weak ES Model may cause the Redirect mechanism
+                      to fail.  If a datagram is sent out a physical
+                      interface that does not correspond to the
+                      destination address, the first-hop gateway will
+                      not realize when it needs to send a Redirect.  On
+                      the other hand, if the host has embedded gateway
+                      functionality, then it has routing information
+                      without listening to Redirects.
+
+                      In the Weak ES model, the route computation for an
+                      outgoing datagram is the mapping:
+
+                         route(dest IP addr, TOS) -> gateway, interface
+
+
+
+
+
+
+
+
+
+Internet Engineering Task Force                                [Page 63]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+         3.3.4.3  Choosing a Source Address
+
+            DISCUSSION:
+                 When it sends an initial connection request (e.g., a
+                 TCP "SYN" segment) or a datagram service request (e.g.,
+                 a UDP-based query), the transport layer on a multihomed
+                 host needs to know which source address to use.  If the
+                 application does not specify it, the transport layer
+                 must ask the IP layer to perform the conceptual
+                 mapping:
+
+                     GET_SRCADDR(remote IP addr, TOS)
+                                               -> local IP address
+
+                 Here TOS is the Type-of-Service value (see Section
+                 3.2.1.6), and the result is the desired source address.
+                 The following rules are suggested for implementing this
+                 mapping:
+
+                 (a)  If the remote Internet address lies on one of the
+                      (sub-) nets to which the host is directly
+                      connected, a corresponding source address may be
+                      chosen, unless the corresponding interface is
+                      known to be down.
+
+                 (b)  The route cache may be consulted, to see if there
+                      is an active route to the specified destination
+                      network through any network interface; if so, a
+                      local IP address corresponding to that interface
+                      may be chosen.
+
+                 (c)  The table of static routes, if any (see Section
+                      3.3.1.2) may be similarly consulted.
+
+                 (d)  The default gateways may be consulted.  If these
+                      gateways are assigned to different interfaces, the
+                      interface corresponding to the gateway with the
+                      highest preference may be chosen.
+
+                 In the future, there may be a defined way for a
+                 multihomed host to ask the gateways on all connected
+                 networks for advice about the best network to use for a
+                 given destination.
+
+            IMPLEMENTATION:
+                 It will be noted that this process is essentially the
+                 same as datagram routing (see Section 3.3.1), and
+                 therefore hosts may be able to combine the
+
+
+
+Internet Engineering Task Force                                [Page 64]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+                 implementation of the two functions.
+
+      3.3.5  Source Route Forwarding
+
+         Subject to restrictions given below, a host MAY be able to act
+         as an intermediate hop in a source route, forwarding a source-
+         routed datagram to the next specified hop.
+
+         However, in performing this gateway-like function, the host
+         MUST obey all the relevant rules for a gateway forwarding
+         source-routed datagrams [INTRO:2].  This includes the following
+         specific provisions, which override the corresponding host
+         provisions given earlier in this document:
+
+         (A)  TTL (ref. Section 3.2.1.7)
+
+              The TTL field MUST be decremented and the datagram perhaps
+              discarded as specified for a gateway in [INTRO:2].
+
+         (B)  ICMP Destination Unreachable (ref. Section 3.2.2.1)
+
+              A host MUST be able to generate Destination Unreachable
+              messages with the following codes:
+
+              4    (Fragmentation Required but DF Set) when a source-
+                   routed datagram cannot be fragmented to fit into the
+                   target network;
+
+              5    (Source Route Failed) when a source-routed datagram
+                   cannot be forwarded, e.g., because of a routing
+                   problem or because the next hop of a strict source
+                   route is not on a connected network.
+
+         (C)  IP Source Address (ref. Section 3.2.1.3)
+
+              A source-routed datagram being forwarded MAY (and normally
+              will) have a source address that is not one of the IP
+              addresses of the forwarding host.
+
+         (D)  Record Route Option (ref. Section 3.2.1.8d)
+
+              A host that is forwarding a source-routed datagram
+              containing a Record Route option MUST update that option,
+              if it has room.
+
+         (E)  Timestamp Option (ref. Section 3.2.1.8e)
+
+              A host that is forwarding a source-routed datagram
+
+
+
+Internet Engineering Task Force                                [Page 65]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+              containing a Timestamp Option MUST add the current
+              timestamp to that option, according to the rules for this
+              option.
+
+         To define the rules restricting host forwarding of source-
+         routed datagrams, we use the term "local source-routing" if the
+         next hop will be through the same physical interface through
+         which the datagram arrived; otherwise, it is "non-local
+         source-routing".
+
+         o    A host is permitted to perform local source-routing
+              without restriction.
+
+         o    A host that supports non-local source-routing MUST have a
+              configurable switch to disable forwarding, and this switch
+              MUST default to disabled.
+
+         o    The host MUST satisfy all gateway requirements for
+              configurable policy filters [INTRO:2] restricting non-
+              local forwarding.
+
+         If a host receives a datagram with an incomplete source route
+         but does not forward it for some reason, the host SHOULD return
+         an ICMP Destination Unreachable (code 5, Source Route Failed)
+         message, unless the datagram was itself an ICMP error message.
+
+      3.3.6  Broadcasts
+
+         Section 3.2.1.3 defined the four standard IP broadcast address
+         forms:
+
+           Limited Broadcast:  {-1, -1}
+
+           Directed Broadcast:  {<Network-number>,-1}
+
+           Subnet Directed Broadcast:
+                              {<Network-number>,<Subnet-number>,-1}
+
+           All-Subnets Directed Broadcast: {<Network-number>,-1,-1}
+
+         A host MUST recognize any of these forms in the destination
+         address of an incoming datagram.
+
+         There is a class of hosts* that use non-standard broadcast
+         address forms, substituting 0 for -1.  All hosts SHOULD
+_________________________
+*4.2BSD Unix and its derivatives, but not 4.3BSD.
+
+
+
+
+Internet Engineering Task Force                                [Page 66]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+         recognize and accept any of these non-standard broadcast
+         addresses as the destination address of an incoming datagram.
+         A host MAY optionally have a configuration option to choose the
+         0 or the -1 form of broadcast address, for each physical
+         interface, but this option SHOULD default to the standard (-1)
+         form.
+
+         When a host sends a datagram to a link-layer broadcast address,
+         the IP destination address MUST be a legal IP broadcast or IP
+         multicast address.
+
+         A host SHOULD silently discard a datagram that is received via
+         a link-layer broadcast (see Section 2.4) but does not specify
+         an IP multicast or broadcast destination address.
+
+         Hosts SHOULD use the Limited Broadcast address to broadcast to
+         a connected network.
+
+
+         DISCUSSION:
+              Using the Limited Broadcast address instead of a Directed
+              Broadcast address may improve system robustness.  Problems
+              are often caused by machines that do not understand the
+              plethora of broadcast addresses (see Section 3.2.1.3), or
+              that may have different ideas about which broadcast
+              addresses are in use.  The prime example of the latter is
+              machines that do not understand subnetting but are
+              attached to a subnetted net.  Sending a Subnet Broadcast
+              for the connected network will confuse those machines,
+              which will see it as a message to some other host.
+
+              There has been discussion on whether a datagram addressed
+              to the Limited Broadcast address ought to be sent from all
+              the interfaces of a multihomed host.  This specification
+              takes no stand on the issue.
+
+      3.3.7  IP Multicasting
+
+         A host SHOULD support local IP multicasting on all connected
+         networks for which a mapping from Class D IP addresses to
+         link-layer addresses has been specified (see below).  Support
+         for local IP multicasting includes sending multicast datagrams,
+         joining multicast groups and receiving multicast datagrams, and
+         leaving multicast groups.  This implies support for all of
+         [IP:4] except the IGMP protocol itself, which is OPTIONAL.
+
+
+
+
+
+
+Internet Engineering Task Force                                [Page 67]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+         DISCUSSION:
+              IGMP provides gateways that are capable of multicast
+              routing with the information required to support IP
+              multicasting across multiple networks.  At this time,
+              multicast-routing gateways are in the experimental stage
+              and are not widely available.  For hosts that are not
+              connected to networks with multicast-routing gateways or
+              that do not need to receive multicast datagrams
+              originating on other networks, IGMP serves no purpose and
+              is therefore optional for now.  However, the rest of
+              [IP:4] is currently recommended for the purpose of
+              providing IP-layer access to local network multicast
+              addressing, as a preferable alternative to local broadcast
+              addressing.  It is expected that IGMP will become
+              recommended at some future date, when multicast-routing
+              gateways have become more widely available.
+
+         If IGMP is not implemented, a host SHOULD still join the "all-
+         hosts" group (224.0.0.1) when the IP layer is initialized and
+         remain a member for as long as the IP layer is active.
+
+         DISCUSSION:
+              Joining the "all-hosts" group will support strictly local
+              uses of multicasting, e.g., a gateway discovery protocol,
+              even if IGMP is not implemented.
+
+         The mapping of IP Class D addresses to local addresses is
+         currently specified for the following types of networks:
+
+         o    Ethernet/IEEE 802.3, as defined in [IP:4].
+
+         o    Any network that supports broadcast but not multicast,
+              addressing: all IP Class D addresses map to the local
+              broadcast address.
+
+         o    Any type of point-to-point link (e.g., SLIP or HDLC
+              links): no mapping required.  All IP multicast datagrams
+              are sent as-is, inside the local framing.
+
+         Mappings for other types of networks will be specified in the
+         future.
+
+         A host SHOULD provide a way for higher-layer protocols or
+         applications to determine which of the host's connected
+         network(s) support IP multicast addressing.
+
+
+
+
+
+
+Internet Engineering Task Force                                [Page 68]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+      3.3.8  Error Reporting
+
+         Wherever practical, hosts MUST return ICMP error datagrams on
+         detection of an error, except in those cases where returning an
+         ICMP error message is specifically prohibited.
+
+         DISCUSSION:
+              A common phenomenon in datagram networks is the "black
+              hole disease": datagrams are sent out, but nothing comes
+              back.  Without any error datagrams, it is difficult for
+              the user to figure out what the problem is.
+
+   3.4  INTERNET/TRANSPORT LAYER INTERFACE
+
+      The interface between the IP layer and the transport layer MUST
+      provide full access to all the mechanisms of the IP layer,
+      including options, Type-of-Service, and Time-to-Live.  The
+      transport layer MUST either have mechanisms to set these interface
+      parameters, or provide a path to pass them through from an
+      application, or both.
+
+      DISCUSSION:
+           Applications are urged to make use of these mechanisms where
+           applicable, even when the mechanisms are not currently
+           effective in the Internet (e.g., TOS).  This will allow these
+           mechanisms to be immediately useful when they do become
+           effective, without a large amount of retrofitting of host
+           software.
+
+      We now describe a conceptual interface between the transport layer
+      and the IP layer, as a set of procedure calls.  This is an
+      extension of the information in Section 3.3 of RFC-791 [IP:1].
+
+
+      *    Send Datagram
+
+                SEND(src, dst, prot, TOS, TTL, BufPTR, len, Id, DF, opt
+                     => result )
+
+           where the parameters are defined in RFC-791.  Passing an Id
+           parameter is optional; see Section 3.2.1.5.
+
+
+      *    Receive Datagram
+
+                RECV(BufPTR, prot
+                     => result, src, dst, SpecDest, TOS, len, opt)
+
+
+
+
+Internet Engineering Task Force                                [Page 69]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+           All the parameters are defined in RFC-791, except for:
+
+                SpecDest = specific-destination address of datagram
+                            (defined in Section 3.2.1.3)
+
+           The result parameter dst contains the datagram's destination
+           address.  Since this may be a broadcast or multicast address,
+           the SpecDest parameter (not shown in RFC-791) MUST be passed.
+           The parameter opt contains all the IP options received in the
+           datagram; these MUST also be passed to the transport layer.
+
+
+      *    Select Source Address
+
+                GET_SRCADDR(remote, TOS)  -> local
+
+                remote = remote IP address
+                TOS = Type-of-Service
+                local = local IP address
+
+           See Section 3.3.4.3.
+
+
+      *    Find Maximum Datagram Sizes
+
+                GET_MAXSIZES(local, remote, TOS) -> MMS_R, MMS_S
+
+                MMS_R = maximum receive transport-message size.
+                MMS_S = maximum send transport-message size.
+               (local, remote, TOS defined above)
+
+           See Sections 3.3.2 and 3.3.3.
+
+
+      *    Advice on Delivery Success
+
+                ADVISE_DELIVPROB(sense, local, remote, TOS)
+
+           Here the parameter sense is a 1-bit flag indicating whether
+           positive or negative advice is being given; see the
+           discussion in Section 3.3.1.4. The other parameters were
+           defined earlier.
+
+
+      *    Send ICMP Message
+
+                SEND_ICMP(src, dst, TOS, TTL, BufPTR, len, Id, DF, opt)
+                     -> result
+
+
+
+Internet Engineering Task Force                                [Page 70]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+                (Parameters defined in RFC-791).
+
+           Passing an Id parameter is optional; see Section 3.2.1.5.
+           The transport layer MUST be able to send certain ICMP
+           messages:  Port Unreachable or any of the query-type
+           messages.  This function could be considered to be a special
+           case of the SEND() call, of course; we describe it separately
+           for clarity.
+
+
+      *    Receive ICMP Message
+
+                RECV_ICMP(BufPTR ) -> result, src, dst, len, opt
+
+                (Parameters defined in RFC-791).
+
+           The IP layer MUST pass certain ICMP messages up to the
+           appropriate transport-layer routine.  This function could be
+           considered to be a special case of the RECV() call, of
+           course; we describe it separately for clarity.
+
+           For an ICMP error message, the data that is passed up MUST
+           include the original Internet header plus all the octets of
+           the original message that are included in the ICMP message.
+           This data will be used by the transport layer to locate the
+           connection state information, if any.
+
+           In particular, the following ICMP messages are to be passed
+           up:
+
+           o    Destination Unreachable
+
+           o    Source Quench
+
+           o    Echo Reply (to ICMP user interface, unless the Echo
+                Request originated in the IP layer)
+
+           o    Timestamp Reply (to ICMP user interface)
+
+           o    Time Exceeded
+
+
+      DISCUSSION:
+           In the future, there may be additions to this interface to
+           pass path data (see Section 3.3.1.3) between the IP and
+           transport layers.
+
+
+
+
+
+Internet Engineering Task Force                                [Page 71]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+   3.5  INTERNET LAYER REQUIREMENTS SUMMARY
+
+
+                                                 |        | | | |S| |
+                                                 |        | | | |H| |F
+                                                 |        | | | |O|M|o
+                                                 |        | |S| |U|U|o
+                                                 |        | |H| |L|S|t
+                                                 |        |M|O| |D|T|n
+                                                 |        |U|U|M| | |o
+                                                 |        |S|L|A|N|N|t
+                                                 |        |T|D|Y|O|O|t
+FEATURE                                          |SECTION | | | |T|T|e
+-------------------------------------------------|--------|-|-|-|-|-|--
+                                                 |        | | | | | |
+Implement IP and ICMP                            |3.1     |x| | | | |
+Handle remote multihoming in application layer   |3.1     |x| | | | |
+Support local multihoming                        |3.1     | | |x| | |
+Meet gateway specs if forward datagrams          |3.1     |x| | | | |
+Configuration switch for embedded gateway        |3.1     |x| | | | |1
+   Config switch default to non-gateway          |3.1     |x| | | | |1
+   Auto-config based on number of interfaces     |3.1     | | | | |x|1
+Able to log discarded datagrams                  |3.1     | |x| | | |
+   Record in counter                             |3.1     | |x| | | |
+                                                 |        | | | | | |
+Silently discard Version != 4                    |3.2.1.1 |x| | | | |
+Verify IP checksum, silently discard bad dgram   |3.2.1.2 |x| | | | |
+Addressing:                                      |        | | | | | |
+  Subnet addressing (RFC-950)                    |3.2.1.3 |x| | | | |
+  Src address must be host's own IP address      |3.2.1.3 |x| | | | |
+  Silently discard datagram with bad dest addr   |3.2.1.3 |x| | | | |
+  Silently discard datagram with bad src addr    |3.2.1.3 |x| | | | |
+Support reassembly                               |3.2.1.4 |x| | | | |
+Retain same Id field in identical datagram       |3.2.1.5 | | |x| | |
+                                                 |        | | | | | |
+TOS:                                             |        | | | | | |
+  Allow transport layer to set TOS               |3.2.1.6 |x| | | | |
+  Pass received TOS up to transport layer        |3.2.1.6 | |x| | | |
+  Use RFC-795 link-layer mappings for TOS        |3.2.1.6 | | | |x| |
+TTL:                                             |        | | | | | |
+  Send packet with TTL of 0                      |3.2.1.7 | | | | |x|
+  Discard received packets with TTL < 2          |3.2.1.7 | | | | |x|
+  Allow transport layer to set TTL               |3.2.1.7 |x| | | | |
+  Fixed TTL is configurable                      |3.2.1.7 |x| | | | |
+                                                 |        | | | | | |
+IP Options:                                      |        | | | | | |
+  Allow transport layer to send IP options       |3.2.1.8 |x| | | | |
+  Pass all IP options rcvd to higher layer       |3.2.1.8 |x| | | | |
+
+
+
+Internet Engineering Task Force                                [Page 72]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+  IP layer silently ignore unknown options       |3.2.1.8 |x| | | | |
+  Security option                                |3.2.1.8a| | |x| | |
+  Send Stream Identifier option                  |3.2.1.8b| | | |x| |
+  Silently ignore Stream Identifer option        |3.2.1.8b|x| | | | |
+  Record Route option                            |3.2.1.8d| | |x| | |
+  Timestamp option                               |3.2.1.8e| | |x| | |
+Source Route Option:                             |        | | | | | |
+  Originate & terminate Source Route options     |3.2.1.8c|x| | | | |
+  Datagram with completed SR passed up to TL     |3.2.1.8c|x| | | | |
+  Build correct (non-redundant) return route     |3.2.1.8c|x| | | | |
+  Send multiple SR options in one header         |3.2.1.8c| | | | |x|
+                                                 |        | | | | | |
+ICMP:                                            |        | | | | | |
+  Silently discard ICMP msg with unknown type    |3.2.2   |x| | | | |
+  Include more than 8 octets of orig datagram    |3.2.2   | | |x| | |
+      Included octets same as received           |3.2.2   |x| | | | |
+  Demux ICMP Error to transport protocol         |3.2.2   |x| | | | |
+  Send ICMP error message with TOS=0             |3.2.2   | |x| | | |
+  Send ICMP error message for:                   |        | | | | | |
+   - ICMP error msg                              |3.2.2   | | | | |x|
+   - IP b'cast or IP m'cast                      |3.2.2   | | | | |x|
+   - Link-layer b'cast                           |3.2.2   | | | | |x|
+   - Non-initial fragment                        |3.2.2   | | | | |x|
+   - Datagram with non-unique src address        |3.2.2   | | | | |x|
+  Return ICMP error msgs (when not prohibited)   |3.3.8   |x| | | | |
+                                                 |        | | | | | |
+  Dest Unreachable:                              |        | | | | | |
+    Generate Dest Unreachable (code 2/3)         |3.2.2.1 | |x| | | |
+    Pass ICMP Dest Unreachable to higher layer   |3.2.2.1 |x| | | | |
+    Higher layer act on Dest Unreach             |3.2.2.1 | |x| | | |
+      Interpret Dest Unreach as only hint        |3.2.2.1 |x| | | | |
+  Redirect:                                      |        | | | | | |
+    Host send Redirect                           |3.2.2.2 | | | |x| |
+    Update route cache when recv Redirect        |3.2.2.2 |x| | | | |
+    Handle both Host and Net Redirects           |3.2.2.2 |x| | | | |
+    Discard illegal Redirect                     |3.2.2.2 | |x| | | |
+  Source Quench:                                 |        | | | | | |
+    Send Source Quench if buffering exceeded     |3.2.2.3 | | |x| | |
+    Pass Source Quench to higher layer           |3.2.2.3 |x| | | | |
+    Higher layer act on Source Quench            |3.2.2.3 | |x| | | |
+  Time Exceeded: pass to higher layer            |3.2.2.4 |x| | | | |
+  Parameter Problem:                             |        | | | | | |
+    Send Parameter Problem messages              |3.2.2.5 | |x| | | |
+    Pass Parameter Problem to higher layer       |3.2.2.5 |x| | | | |
+    Report Parameter Problem to user             |3.2.2.5 | | |x| | |
+                                                 |        | | | | | |
+  ICMP Echo Request or Reply:                    |        | | | | | |
+    Echo server and Echo client                  |3.2.2.6 |x| | | | |
+
+
+
+Internet Engineering Task Force                                [Page 73]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+    Echo client                                  |3.2.2.6 | |x| | | |
+    Discard Echo Request to broadcast address    |3.2.2.6 | | |x| | |
+    Discard Echo Request to multicast address    |3.2.2.6 | | |x| | |
+    Use specific-dest addr as Echo Reply src     |3.2.2.6 |x| | | | |
+    Send same data in Echo Reply                 |3.2.2.6 |x| | | | |
+    Pass Echo Reply to higher layer              |3.2.2.6 |x| | | | |
+    Reflect Record Route, Time Stamp options     |3.2.2.6 | |x| | | |
+    Reverse and reflect Source Route option      |3.2.2.6 |x| | | | |
+                                                 |        | | | | | |
+  ICMP Information Request or Reply:             |3.2.2.7 | | | |x| |
+  ICMP Timestamp and Timestamp Reply:            |3.2.2.8 | | |x| | |
+    Minimize delay variability                   |3.2.2.8 | |x| | | |1
+    Silently discard b'cast Timestamp            |3.2.2.8 | | |x| | |1
+    Silently discard m'cast Timestamp            |3.2.2.8 | | |x| | |1
+    Use specific-dest addr as TS Reply src       |3.2.2.8 |x| | | | |1
+    Reflect Record Route, Time Stamp options     |3.2.2.6 | |x| | | |1
+    Reverse and reflect Source Route option      |3.2.2.8 |x| | | | |1
+    Pass Timestamp Reply to higher layer         |3.2.2.8 |x| | | | |1
+    Obey rules for "standard value"              |3.2.2.8 |x| | | | |1
+                                                 |        | | | | | |
+  ICMP Address Mask Request and Reply:           |        | | | | | |
+    Addr Mask source configurable                |3.2.2.9 |x| | | | |
+    Support static configuration of addr mask    |3.2.2.9 |x| | | | |
+    Get addr mask dynamically during booting     |3.2.2.9 | | |x| | |
+    Get addr via ICMP Addr Mask Request/Reply    |3.2.2.9 | | |x| | |
+      Retransmit Addr Mask Req if no Reply       |3.2.2.9 |x| | | | |3
+      Assume default mask if no Reply            |3.2.2.9 | |x| | | |3
+      Update address mask from first Reply only  |3.2.2.9 |x| | | | |3
+    Reasonableness check on Addr Mask            |3.2.2.9 | |x| | | |
+    Send unauthorized Addr Mask Reply msgs       |3.2.2.9 | | | | |x|
+      Explicitly configured to be agent          |3.2.2.9 |x| | | | |
+    Static config=> Addr-Mask-Authoritative flag |3.2.2.9 | |x| | | |
+      Broadcast Addr Mask Reply when init.       |3.2.2.9 |x| | | | |3
+                                                 |        | | | | | |
+ROUTING OUTBOUND DATAGRAMS:                      |        | | | | | |
+  Use address mask in local/remote decision      |3.3.1.1 |x| | | | |
+  Operate with no gateways on conn network       |3.3.1.1 |x| | | | |
+  Maintain "route cache" of next-hop gateways    |3.3.1.2 |x| | | | |
+  Treat Host and Net Redirect the same           |3.3.1.2 | |x| | | |
+  If no cache entry, use default gateway         |3.3.1.2 |x| | | | |
+    Support multiple default gateways            |3.3.1.2 |x| | | | |
+  Provide table of static routes                 |3.3.1.2 | | |x| | |
+    Flag: route overridable by Redirects         |3.3.1.2 | | |x| | |
+  Key route cache on host, not net address       |3.3.1.3 | | |x| | |
+  Include TOS in route cache                     |3.3.1.3 | |x| | | |
+                                                 |        | | | | | |
+  Able to detect failure of next-hop gateway     |3.3.1.4 |x| | | | |
+  Assume route is good forever                   |3.3.1.4 | | | |x| |
+
+
+
+Internet Engineering Task Force                                [Page 74]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+  Ping gateways continuously                     |3.3.1.4 | | | | |x|
+  Ping only when traffic being sent              |3.3.1.4 |x| | | | |
+  Ping only when no positive indication          |3.3.1.4 |x| | | | |
+  Higher and lower layers give advice            |3.3.1.4 | |x| | | |
+  Switch from failed default g'way to another    |3.3.1.5 |x| | | | |
+  Manual method of entering config info          |3.3.1.6 |x| | | | |
+                                                 |        | | | | | |
+REASSEMBLY and FRAGMENTATION:                    |        | | | | | |
+  Able to reassemble incoming datagrams          |3.3.2   |x| | | | |
+    At least 576 byte datagrams                  |3.3.2   |x| | | | |
+    EMTU_R configurable or indefinite            |3.3.2   | |x| | | |
+  Transport layer able to learn MMS_R            |3.3.2   |x| | | | |
+  Send ICMP Time Exceeded on reassembly timeout  |3.3.2   |x| | | | |
+    Fixed reassembly timeout value               |3.3.2   | |x| | | |
+                                                 |        | | | | | |
+  Pass MMS_S to higher layers                    |3.3.3   |x| | | | |
+  Local fragmentation of outgoing packets        |3.3.3   | | |x| | |
+     Else don't send bigger than MMS_S           |3.3.3   |x| | | | |
+  Send max 576 to off-net destination            |3.3.3   | |x| | | |
+  All-Subnets-MTU configuration flag             |3.3.3   | | |x| | |
+                                                 |        | | | | | |
+MULTIHOMING:                                     |        | | | | | |
+  Reply with same addr as spec-dest addr         |3.3.4.2 | |x| | | |
+  Allow application to choose local IP addr      |3.3.4.2 |x| | | | |
+  Silently discard d'gram in "wrong" interface   |3.3.4.2 | | |x| | |
+  Only send d'gram through "right" interface     |3.3.4.2 | | |x| | |4
+                                                 |        | | | | | |
+SOURCE-ROUTE FORWARDING:                         |        | | | | | |
+  Forward datagram with Source Route option      |3.3.5   | | |x| | |1
+    Obey corresponding gateway rules             |3.3.5   |x| | | | |1
+      Update TTL by gateway rules                |3.3.5   |x| | | | |1
+      Able to generate ICMP err code 4, 5        |3.3.5   |x| | | | |1
+      IP src addr not local host                 |3.3.5   | | |x| | |1
+      Update Timestamp, Record Route options     |3.3.5   |x| | | | |1
+    Configurable switch for non-local SRing      |3.3.5   |x| | | | |1
+      Defaults to OFF                            |3.3.5   |x| | | | |1
+    Satisfy gwy access rules for non-local SRing |3.3.5   |x| | | | |1
+    If not forward, send Dest Unreach (cd 5)     |3.3.5   | |x| | | |2
+                                                 |        | | | | | |
+BROADCAST:                                       |        | | | | | |
+  Broadcast addr as IP source addr               |3.2.1.3 | | | | |x|
+  Receive 0 or -1 broadcast formats OK           |3.3.6   | |x| | | |
+  Config'ble option to send 0 or -1 b'cast       |3.3.6   | | |x| | |
+    Default to -1 broadcast                      |3.3.6   | |x| | | |
+  Recognize all broadcast address formats        |3.3.6   |x| | | | |
+  Use IP b'cast/m'cast addr in link-layer b'cast |3.3.6   |x| | | | |
+  Silently discard link-layer-only b'cast dg's   |3.3.6   | |x| | | |
+  Use Limited Broadcast addr for connected net   |3.3.6   | |x| | | |
+
+
+
+Internet Engineering Task Force                                [Page 75]
+
+
+
+
+RFC1122                      INTERNET LAYER                 October 1989
+
+
+                                                 |        | | | | | |
+MULTICAST:                                       |        | | | | | |
+  Support local IP multicasting (RFC-1112)       |3.3.7   | |x| | | |
+  Support IGMP (RFC-1112)                        |3.3.7   | | |x| | |
+  Join all-hosts group at startup                |3.3.7   | |x| | | |
+  Higher layers learn i'face m'cast capability   |3.3.7   | |x| | | |
+                                                 |        | | | | | |
+INTERFACE:                                       |        | | | | | |
+  Allow transport layer to use all IP mechanisms |3.4     |x| | | | |
+  Pass interface ident up to transport layer     |3.4     |x| | | | |
+  Pass all IP options up to transport layer      |3.4     |x| | | | |
+  Transport layer can send certain ICMP messages |3.4     |x| | | | |
+  Pass spec'd ICMP messages up to transp. layer  |3.4     |x| | | | |
+     Include IP hdr+8 octets or more from orig.  |3.4     |x| | | | |
+  Able to leap tall buildings at a single bound  |3.5     | |x| | | |
+
+Footnotes:
+
+(1)  Only if feature is implemented.
+
+(2)  This requirement is overruled if datagram is an ICMP error message.
+
+(3)  Only if feature is implemented and is configured "on".
+
+(4)  Unless has embedded gateway functionality or is source routed.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Internet Engineering Task Force                                [Page 76]
+
+
+
+
+RFC1122                  TRANSPORT LAYER -- UDP             October 1989
+
+
+4. TRANSPORT PROTOCOLS
+
+   4.1  USER DATAGRAM PROTOCOL -- UDP
+
+      4.1.1  INTRODUCTION
+
+         The User Datagram Protocol UDP [UDP:1] offers only a minimal
+         transport service -- non-guaranteed datagram delivery -- and
+         gives applications direct access to the datagram service of the
+         IP layer.  UDP is used by applications that do not require the
+         level of service of TCP or that wish to use communications
+         services (e.g., multicast or broadcast delivery) not available
+         from TCP.
+
+         UDP is almost a null protocol; the only services it provides
+         over IP are checksumming of data and multiplexing by port
+         number.  Therefore, an application program running over UDP
+         must deal directly with end-to-end communication problems that
+         a connection-oriented protocol would have handled -- e.g.,
+         retransmission for reliable delivery, packetization and
+         reassembly, flow control, congestion avoidance, etc., when
+         these are required.  The fairly complex coupling between IP and
+         TCP will be mirrored in the coupling between UDP and many
+         applications using UDP.
+
+      4.1.2  PROTOCOL WALK-THROUGH
+
+         There are no known errors in the specification of UDP.
+
+      4.1.3  SPECIFIC ISSUES
+
+         4.1.3.1  Ports
+
+            UDP well-known ports follow the same rules as TCP well-known
+            ports; see Section 4.2.2.1 below.
+
+            If a datagram arrives addressed to a UDP port for which
+            there is no pending LISTEN call, UDP SHOULD send an ICMP
+            Port Unreachable message.
+
+         4.1.3.2  IP Options
+
+            UDP MUST pass any IP option that it receives from the IP
+            layer transparently to the application layer.
+
+            An application MUST be able to specify IP options to be sent
+            in its UDP datagrams, and UDP MUST pass these options to the
+            IP layer.
+
+
+
+Internet Engineering Task Force                                [Page 77]
+
+
+
+
+RFC1122                  TRANSPORT LAYER -- UDP             October 1989
+
+
+            DISCUSSION:
+                 At present, the only options that need be passed
+                 through UDP are Source Route, Record Route, and Time
+                 Stamp.  However, new options may be defined in the
+                 future, and UDP need not and should not make any
+                 assumptions about the format or content of options it
+                 passes to or from the application; an exception to this
+                 might be an IP-layer security option.
+
+                 An application based on UDP will need to obtain a
+                 source route from a request datagram and supply a
+                 reversed route for sending the corresponding reply.
+
+         4.1.3.3  ICMP Messages
+
+            UDP MUST pass to the application layer all ICMP error
+            messages that it receives from the IP layer.  Conceptually
+            at least, this may be accomplished with an upcall to the
+            ERROR_REPORT routine (see Section 4.2.4.1).
+
+            DISCUSSION:
+                 Note that ICMP error messages resulting from sending a
+                 UDP datagram are received asynchronously.  A UDP-based
+                 application that wants to receive ICMP error messages
+                 is responsible for maintaining the state necessary to
+                 demultiplex these messages when they arrive; for
+                 example, the application may keep a pending receive
+                 operation for this purpose.  The application is also
+                 responsible to avoid confusion from a delayed ICMP
+                 error message resulting from an earlier use of the same
+                 port(s).
+
+         4.1.3.4  UDP Checksums
+
+            A host MUST implement the facility to generate and validate
+            UDP checksums.  An application MAY optionally be able to
+            control whether a UDP checksum will be generated, but it
+            MUST default to checksumming on.
+
+            If a UDP datagram is received with a checksum that is non-
+            zero and invalid, UDP MUST silently discard the datagram.
+            An application MAY optionally be able to control whether UDP
+            datagrams without checksums should be discarded or passed to
+            the application.
+
+            DISCUSSION:
+                 Some applications that normally run only across local
+                 area networks have chosen to turn off UDP checksums for
+
+
+
+Internet Engineering Task Force                                [Page 78]
+
+
+
+
+RFC1122                  TRANSPORT LAYER -- UDP             October 1989
+
+
+                 efficiency.  As a result, numerous cases of undetected
+                 errors have been reported.  The advisability of ever
+                 turning off UDP checksumming is very controversial.
+
+            IMPLEMENTATION:
+                 There is a common implementation error in UDP
+                 checksums.  Unlike the TCP checksum, the UDP checksum
+                 is optional; the value zero is transmitted in the
+                 checksum field of a UDP header to indicate the absence
+                 of a checksum.  If the transmitter really calculates a
+                 UDP checksum of zero, it must transmit the checksum as
+                 all 1's (65535).  No special action is required at the
+                 receiver, since zero and 65535 are equivalent in 1's
+                 complement arithmetic.
+
+         4.1.3.5  UDP Multihoming
+
+            When a UDP datagram is received, its specific-destination
+            address MUST be passed up to the application layer.
+
+            An application program MUST be able to specify the IP source
+            address to be used for sending a UDP datagram or to leave it
+            unspecified (in which case the networking software will
+            choose an appropriate source address).  There SHOULD be a
+            way to communicate the chosen source address up to the
+            application layer (e.g, so that the application can later
+            receive a reply datagram only from the corresponding
+            interface).
+
+            DISCUSSION:
+                 A request/response application that uses UDP should use
+                 a source address for the response that is the same as
+                 the specific destination address of the request.  See
+                 the "General Issues" section of [INTRO:1].
+
+         4.1.3.6  Invalid Addresses
+
+            A UDP datagram received with an invalid IP source address
+            (e.g., a broadcast or multicast address) must be discarded
+            by UDP or by the IP layer (see Section 3.2.1.3).
+
+            When a host sends a UDP datagram, the source address MUST be
+            (one of) the IP address(es) of the host.
+
+      4.1.4  UDP/APPLICATION LAYER INTERFACE
+
+         The application interface to UDP MUST provide the full services
+         of the IP/transport interface described in Section 3.4 of this
+
+
+
+Internet Engineering Task Force                                [Page 79]
+
+
+
+
+RFC1122                  TRANSPORT LAYER -- UDP             October 1989
+
+
+         document.  Thus, an application using UDP needs the functions
+         of the GET_SRCADDR(), GET_MAXSIZES(), ADVISE_DELIVPROB(), and
+         RECV_ICMP() calls described in Section 3.4.  For example,
+         GET_MAXSIZES() can be used to learn the effective maximum UDP
+         maximum datagram size for a particular {interface,remote
+         host,TOS} triplet.
+
+         An application-layer program MUST be able to set the TTL and
+         TOS values as well as IP options for sending a UDP datagram,
+         and these values must be passed transparently to the IP layer.
+         UDP MAY pass the received TOS up to the application layer.
+
+      4.1.5  UDP REQUIREMENTS SUMMARY
+
+
+                                                 |        | | | |S| |
+                                                 |        | | | |H| |F
+                                                 |        | | | |O|M|o
+                                                 |        | |S| |U|U|o
+                                                 |        | |H| |L|S|t
+                                                 |        |M|O| |D|T|n
+                                                 |        |U|U|M| | |o
+                                                 |        |S|L|A|N|N|t
+                                                 |        |T|D|Y|O|O|t
+FEATURE                                          |SECTION | | | |T|T|e
+-------------------------------------------------|--------|-|-|-|-|-|--
+                                                 |        | | | | | |
+    UDP                                          |        | | | | | |
+-------------------------------------------------|--------|-|-|-|-|-|--
+                                                 |        | | | | | |
+UDP send Port Unreachable                        |4.1.3.1 | |x| | | |
+                                                 |        | | | | | |
+IP Options in UDP                                |        | | | | | |
+ - Pass rcv'd IP options to applic layer         |4.1.3.2 |x| | | | |
+ - Applic layer can specify IP options in Send   |4.1.3.2 |x| | | | |
+ - UDP passes IP options down to IP layer        |4.1.3.2 |x| | | | |
+                                                 |        | | | | | |
+Pass ICMP msgs up to applic layer                |4.1.3.3 |x| | | | |
+                                                 |        | | | | | |
+UDP checksums:                                   |        | | | | | |
+ - Able to generate/check checksum               |4.1.3.4 |x| | | | |
+ - Silently discard bad checksum                 |4.1.3.4 |x| | | | |
+ - Sender Option to not generate checksum        |4.1.3.4 | | |x| | |
+   - Default is to checksum                      |4.1.3.4 |x| | | | |
+ - Receiver Option to require checksum           |4.1.3.4 | | |x| | |
+                                                 |        | | | | | |
+UDP Multihoming                                  |        | | | | | |
+ - Pass spec-dest addr to application            |4.1.3.5 |x| | | | |
+
+
+
+Internet Engineering Task Force                                [Page 80]
+
+
+
+
+RFC1122                  TRANSPORT LAYER -- UDP             October 1989
+
+
+ - Applic layer can specify Local IP addr        |4.1.3.5 |x| | | | |
+ - Applic layer specify wild Local IP addr       |4.1.3.5 |x| | | | |
+ - Applic layer notified of Local IP addr used   |4.1.3.5 | |x| | | |
+                                                 |        | | | | | |
+Bad IP src addr silently discarded by UDP/IP     |4.1.3.6 |x| | | | |
+Only send valid IP source address                |4.1.3.6 |x| | | | |
+UDP Application Interface Services               |        | | | | | |
+Full IP interface of 3.4 for application         |4.1.4   |x| | | | |
+ - Able to spec TTL, TOS, IP opts when send dg   |4.1.4   |x| | | | |
+ - Pass received TOS up to applic layer          |4.1.4   | | |x| | |
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Internet Engineering Task Force                                [Page 81]
+
+
+
+
+RFC1122                  TRANSPORT LAYER -- TCP             October 1989
+
+
+   4.2  TRANSMISSION CONTROL PROTOCOL -- TCP
+
+      4.2.1  INTRODUCTION
+
+         The Transmission Control Protocol TCP [TCP:1] is the primary
+         virtual-circuit transport protocol for the Internet suite.  TCP
+         provides reliable, in-sequence delivery of a full-duplex stream
+         of octets (8-bit bytes).  TCP is used by those applications
+         needing reliable, connection-oriented transport service, e.g.,
+         mail (SMTP), file transfer (FTP), and virtual terminal service
+         (Telnet); requirements for these application-layer protocols
+         are described in [INTRO:1].
+
+      4.2.2  PROTOCOL WALK-THROUGH
+
+         4.2.2.1  Well-Known Ports: RFC-793 Section 2.7
+
+            DISCUSSION:
+                 TCP reserves port numbers in the range 0-255 for
+                 "well-known" ports, used to access services that are
+                 standardized across the Internet.  The remainder of the
+                 port space can be freely allocated to application
+                 processes.  Current well-known port definitions are
+                 listed in the RFC entitled "Assigned Numbers"
+                 [INTRO:6].  A prerequisite for defining a new well-
+                 known port is an RFC documenting the proposed service
+                 in enough detail to allow new implementations.
+
+                 Some systems extend this notion by adding a third
+                 subdivision of the TCP port space: reserved ports,
+                 which are generally used for operating-system-specific
+                 services.  For example, reserved ports might fall
+                 between 256 and some system-dependent upper limit.
+                 Some systems further choose to protect well-known and
+                 reserved ports by permitting only privileged users to
+                 open TCP connections with those port values.  This is
+                 perfectly reasonable as long as the host does not
+                 assume that all hosts protect their low-numbered ports
+                 in this manner.
+
+         4.2.2.2  Use of Push: RFC-793 Section 2.8
+
+            When an application issues a series of SEND calls without
+            setting the PUSH flag, the TCP MAY aggregate the data
+            internally without sending it.  Similarly, when a series of
+            segments is received without the PSH bit, a TCP MAY queue
+            the data internally without passing it to the receiving
+            application.
+
+
+
+Internet Engineering Task Force                                [Page 82]
+
+
+
+
+RFC1122                  TRANSPORT LAYER -- TCP             October 1989
+
+
+            The PSH bit is not a record marker and is independent of
+            segment boundaries.  The transmitter SHOULD collapse
+            successive PSH bits when it packetizes data, to send the
+            largest possible segment.
+
+            A TCP MAY implement PUSH flags on SEND calls.  If PUSH flags
+            are not implemented, then the sending TCP: (1) must not
+            buffer data indefinitely, and (2) MUST set the PSH bit in
+            the last buffered segment (i.e., when there is no more
+            queued data to be sent).
+
+            The discussion in RFC-793 on pages 48, 50, and 74
+            erroneously implies that a received PSH flag must be passed
+            to the application layer.  Passing a received PSH flag to
+            the application layer is now OPTIONAL.
+
+            An application program is logically required to set the PUSH
+            flag in a SEND call whenever it needs to force delivery of
+            the data to avoid a communication deadlock.  However, a TCP
+            SHOULD send a maximum-sized segment whenever possible, to
+            improve performance (see Section 4.2.3.4).
+
+            DISCUSSION:
+                 When the PUSH flag is not implemented on SEND calls,
+                 i.e., when the application/TCP interface uses a pure
+                 streaming model, responsibility for aggregating any
+                 tiny data fragments to form reasonable sized segments
+                 is partially borne by the application layer.
+
+                 Generally, an interactive application protocol must set
+                 the PUSH flag at least in the last SEND call in each
+                 command or response sequence.  A bulk transfer protocol
+                 like FTP should set the PUSH flag on the last segment
+                 of a file or when necessary to prevent buffer deadlock.
+
+                 At the receiver, the PSH bit forces buffered data to be
+                 delivered to the application (even if less than a full
+                 buffer has been received). Conversely, the lack of a
+                 PSH bit can be used to avoid unnecessary wakeup calls
+                 to the application process; this can be an important
+                 performance optimization for large timesharing hosts.
+                 Passing the PSH bit to the receiving application allows
+                 an analogous optimization within the application.
+
+         4.2.2.3  Window Size: RFC-793 Section 3.1
+
+            The window size MUST be treated as an unsigned number, or
+            else large window sizes will appear like negative windows
+
+
+
+Internet Engineering Task Force                                [Page 83]
+
+
+
+
+RFC1122                  TRANSPORT LAYER -- TCP             October 1989
+
+
+            and TCP will not work.  It is RECOMMENDED that
+            implementations reserve 32-bit fields for the send and
+            receive window sizes in the connection record and do all
+            window computations with 32 bits.
+
+            DISCUSSION:
+                 It is known that the window field in the TCP header is
+                 too small for high-speed, long-delay paths.
+                 Experimental TCP options have been defined to extend
+                 the window size; see for example [TCP:11].  In
+                 anticipation of the adoption of such an extension, TCP
+                 implementors should treat windows as 32 bits.
+
+         4.2.2.4  Urgent Pointer: RFC-793 Section 3.1
+
+            The second sentence is in error: the urgent pointer points
+            to the sequence number of the LAST octet (not LAST+1) in a
+            sequence of urgent data.  The description on page 56 (last
+            sentence) is correct.
+
+            A TCP MUST support a sequence of urgent data of any length.
+
+            A TCP MUST inform the application layer asynchronously
+            whenever it receives an Urgent pointer and there was
+            previously no pending urgent data, or whenever the Urgent
+            pointer advances in the data stream.  There MUST be a way
+            for the application to learn how much urgent data remains to
+            be read from the connection, or at least to determine
+            whether or not more urgent data remains to be read.
+
+            DISCUSSION:
+                 Although the Urgent mechanism may be used for any
+                 application, it is normally used to send "interrupt"-
+                 type commands to a Telnet program (see "Using Telnet
+                 Synch Sequence" section in [INTRO:1]).
+
+                 The asynchronous or "out-of-band" notification will
+                 allow the application to go into "urgent mode", reading
+                 data from the TCP connection.  This allows control
+                 commands to be sent to an application whose normal
+                 input buffers are full of unprocessed data.
+
+            IMPLEMENTATION:
+                 The generic ERROR-REPORT() upcall described in Section
+                 4.2.4.1 is a possible mechanism for informing the
+                 application of the arrival of urgent data.
+
+
+
+
+
+Internet Engineering Task Force                                [Page 84]
+
+
+
+
+RFC1122                  TRANSPORT LAYER -- TCP             October 1989
+
+
+         4.2.2.5  TCP Options: RFC-793 Section 3.1
+
+            A TCP MUST be able to receive a TCP option in any segment.
+            A TCP MUST ignore without error any TCP option it does not
+            implement, assuming that the option has a length field (all
+            TCP options defined in the future will have length fields).
+            TCP MUST be prepared to handle an illegal option length
+            (e.g., zero) without crashing; a suggested procedure is to
+            reset the connection and log the reason.
+
+         4.2.2.6  Maximum Segment Size Option: RFC-793 Section 3.1
+
+            TCP MUST implement both sending and receiving the Maximum
+            Segment Size option [TCP:4].
+
+            TCP SHOULD send an MSS (Maximum Segment Size) option in
+            every SYN segment when its receive MSS differs from the
+            default 536, and MAY send it always.
+
+            If an MSS option is not received at connection setup, TCP
+            MUST assume a default send MSS of 536 (576-40) [TCP:4].
+
+            The maximum size of a segment that TCP really sends, the
+            "effective send MSS," MUST be the smaller of the send MSS
+            (which reflects the available reassembly buffer size at the
+            remote host) and the largest size permitted by the IP layer:
+
+               Eff.snd.MSS =
+
+                  min(SendMSS+20, MMS_S) - TCPhdrsize - IPoptionsize
+
+            where:
+
+            *    SendMSS is the MSS value received from the remote host,
+                 or the default 536 if no MSS option is received.
+
+            *    MMS_S is the maximum size for a transport-layer message
+                 that TCP may send.
+
+            *    TCPhdrsize is the size of the TCP header; this is
+                 normally 20, but may be larger if TCP options are to be
+                 sent.
+
+            *    IPoptionsize is the size of any IP options that TCP
+                 will pass to the IP layer with the current message.
+
+
+            The MSS value to be sent in an MSS option must be less than
+
+
+
+Internet Engineering Task Force                                [Page 85]
+
+
+
+
+RFC1122                  TRANSPORT LAYER -- TCP             October 1989
+
+
+            or equal to:
+
+               MMS_R - 20
+
+            where MMS_R is the maximum size for a transport-layer
+            message that can be received (and reassembled).  TCP obtains
+            MMS_R and MMS_S from the IP layer; see the generic call
+            GET_MAXSIZES in Section 3.4.
+
+            DISCUSSION:
+                 The choice of TCP segment size has a strong effect on
+                 performance.  Larger segments increase throughput by
+                 amortizing header size and per-datagram processing
+                 overhead over more data bytes; however, if the packet
+                 is so large that it causes IP fragmentation, efficiency
+                 drops sharply if any fragments are lost [IP:9].
+
+                 Some TCP implementations send an MSS option only if the
+                 destination host is on a non-connected network.
+                 However, in general the TCP layer may not have the
+                 appropriate information to make this decision, so it is
+                 preferable to leave to the IP layer the task of
+                 determining a suitable MTU for the Internet path.  We
+                 therefore recommend that TCP always send the option (if
+                 not 536) and that the IP layer determine MMS_R as
+                 specified in 3.3.3 and 3.4.  A proposed IP-layer
+                 mechanism to measure the MTU would then modify the IP
+                 layer without changing TCP.
+
+         4.2.2.7  TCP Checksum: RFC-793 Section 3.1
+
+            Unlike the UDP checksum (see Section 4.1.3.4), the TCP
+            checksum is never optional.  The sender MUST generate it and
+            the receiver MUST check it.
+
+         4.2.2.8  TCP Connection State Diagram: RFC-793 Section 3.2,
+            page 23
+
+            There are several problems with this diagram:
+
+            (a)  The arrow from SYN-SENT to SYN-RCVD should be labeled
+                 with "snd SYN,ACK", to agree with the text on page 68
+                 and with Figure 8.
+
+            (b)  There could be an arrow from SYN-RCVD state to LISTEN
+                 state, conditioned on receiving a RST after a passive
+                 open (see text page 70).
+
+
+
+
+Internet Engineering Task Force                                [Page 86]
+
+
+
+
+RFC1122                  TRANSPORT LAYER -- TCP             October 1989
+
+
+            (c)  It is possible to go directly from FIN-WAIT-1 to the
+                 TIME-WAIT state (see page 75 of the spec).
+
+
+         4.2.2.9  Initial Sequence Number Selection: RFC-793 Section
+            3.3, page 27
+
+            A TCP MUST use the specified clock-driven selection of
+            initial sequence numbers.
+
+         4.2.2.10  Simultaneous Open Attempts: RFC-793 Section 3.4, page
+            32
+
+            There is an error in Figure 8: the packet on line 7 should
+            be identical to the packet on line 5.
+
+            A TCP MUST support simultaneous open attempts.
+
+            DISCUSSION:
+                 It sometimes surprises implementors that if two
+                 applications attempt to simultaneously connect to each
+                 other, only one connection is generated instead of two.
+                 This was an intentional design decision; don't try to
+                 "fix" it.
+
+         4.2.2.11  Recovery from Old Duplicate SYN: RFC-793 Section 3.4,
+            page 33
+
+            Note that a TCP implementation MUST keep track of whether a
+            connection has reached SYN_RCVD state as the result of a
+            passive OPEN or an active OPEN.
+
+         4.2.2.12  RST Segment: RFC-793 Section 3.4
+
+            A TCP SHOULD allow a received RST segment to include data.
+
+            DISCUSSION
+                 It has been suggested that a RST segment could contain
+                 ASCII text that encoded and explained the cause of the
+                 RST.  No standard has yet been established for such
+                 data.
+
+         4.2.2.13  Closing a Connection: RFC-793 Section 3.5
+
+            A TCP connection may terminate in two ways: (1) the normal
+            TCP close sequence using a FIN handshake, and (2) an "abort"
+            in which one or more RST segments are sent and the
+            connection state is immediately discarded.  If a TCP
+
+
+
+Internet Engineering Task Force                                [Page 87]
+
+
+
+
+RFC1122                  TRANSPORT LAYER -- TCP             October 1989
+
+
+            connection is closed by the remote site, the local
+            application MUST be informed whether it closed normally or
+            was aborted.
+
+            The normal TCP close sequence delivers buffered data
+            reliably in both directions.  Since the two directions of a
+            TCP connection are closed independently, it is possible for
+            a connection to be "half closed," i.e., closed in only one
+            direction, and a host is permitted to continue sending data
+            in the open direction on a half-closed connection.
+
+            A host MAY implement a "half-duplex" TCP close sequence, so
+            that an application that has called CLOSE cannot continue to
+            read data from the connection.  If such a host issues a
+            CLOSE call while received data is still pending in TCP, or
+            if new data is received after CLOSE is called, its TCP
+            SHOULD send a RST to show that data was lost.
+
+            When a connection is closed actively, it MUST linger in
+            TIME-WAIT state for a time 2xMSL (Maximum Segment Lifetime).
+            However, it MAY accept a new SYN from the remote TCP to
+            reopen the connection directly from TIME-WAIT state, if it:
+
+            (1)  assigns its initial sequence number for the new
+                 connection to be larger than the largest sequence
+                 number it used on the previous connection incarnation,
+                 and
+
+            (2)  returns to TIME-WAIT state if the SYN turns out to be
+                 an old duplicate.
+
+
+            DISCUSSION:
+                 TCP's full-duplex data-preserving close is a feature
+                 that is not included in the analogous ISO transport
+                 protocol TP4.
+
+                 Some systems have not implemented half-closed
+                 connections, presumably because they do not fit into
+                 the I/O model of their particular operating system.  On
+                 these systems, once an application has called CLOSE, it
+                 can no longer read input data from the connection; this
+                 is referred to as a "half-duplex" TCP close sequence.
+
+                 The graceful close algorithm of TCP requires that the
+                 connection state remain defined on (at least)  one end
+                 of the connection, for a timeout period of 2xMSL, i.e.,
+                 4 minutes.  During this period, the (remote socket,
+
+
+
+Internet Engineering Task Force                                [Page 88]
+
+
+
+
+RFC1122                  TRANSPORT LAYER -- TCP             October 1989
+
+
+                 local socket) pair that defines the connection is busy
+                 and cannot be reused.  To shorten the time that a given
+                 port pair is tied up, some TCPs allow a new SYN to be
+                 accepted in TIME-WAIT state.
+
+         4.2.2.14  Data Communication: RFC-793 Section 3.7, page 40
+
+            Since RFC-793 was written, there has been extensive work on
+            TCP algorithms to achieve efficient data communication.
+            Later sections of the present document describe required and
+            recommended TCP algorithms to determine when to send data
+            (Section 4.2.3.4), when to send an acknowledgment (Section
+            4.2.3.2), and when to update the window (Section 4.2.3.3).
+
+            DISCUSSION:
+                 One important performance issue is "Silly Window
+                 Syndrome" or "SWS" [TCP:5], a stable pattern of small
+                 incremental window movements resulting in extremely
+                 poor TCP performance.  Algorithms to avoid SWS are
+                 described below for both the sending side (Section
+                 4.2.3.4) and the receiving side (Section 4.2.3.3).
+
+                 In brief, SWS is caused by the receiver advancing the
+                 right window edge whenever it has any new buffer space
+                 available to receive data and by the sender using any
+                 incremental window, no matter how small, to send more
+                 data [TCP:5].  The result can be a stable pattern of
+                 sending tiny data segments, even though both sender and
+                 receiver have a large total buffer space for the
+                 connection.  SWS can only occur during the transmission
+                 of a large amount of data; if the connection goes
+                 quiescent, the problem will disappear.  It is caused by
+                 typical straightforward implementation of window
+                 management, but the sender and receiver algorithms
+                 given below will avoid it.
+
+                 Another important TCP performance issue is that some
+                 applications, especially remote login to character-at-
+                 a-time hosts, tend to send streams of one-octet data
+                 segments.  To avoid deadlocks, every TCP SEND call from
+                 such applications must be "pushed", either explicitly
+                 by the application or else implicitly by TCP.  The
+                 result may be a stream of TCP segments that contain one
+                 data octet each, which makes very inefficient use of
+                 the Internet and contributes to Internet congestion.
+                 The Nagle Algorithm described in Section 4.2.3.4
+                 provides a simple and effective solution to this
+                 problem.  It does have the effect of clumping
+
+
+
+Internet Engineering Task Force                                [Page 89]
+
+
+
+
+RFC1122                  TRANSPORT LAYER -- TCP             October 1989
+
+
+                 characters over Telnet connections; this may initially
+                 surprise users accustomed to single-character echo, but
+                 user acceptance has not been a problem.
+
+                 Note that the Nagle algorithm and the send SWS
+                 avoidance algorithm play complementary roles in
+                 improving performance.  The Nagle algorithm discourages
+                 sending tiny segments when the data to be sent
+                 increases in small increments, while the SWS avoidance
+                 algorithm discourages small segments resulting from the
+                 right window edge advancing in small increments.
+
+                 A careless implementation can send two or more
+                 acknowledgment segments per data segment received.  For
+                 example, suppose the receiver acknowledges every data
+                 segment immediately.  When the application program
+                 subsequently consumes the data and increases the
+                 available receive buffer space again, the receiver may
+                 send a second acknowledgment segment to update the
+                 window at the sender.  The extreme case occurs with
+                 single-character segments on TCP connections using the
+                 Telnet protocol for remote login service.  Some
+                 implementations have been observed in which each
+                 incoming 1-character segment generates three return
+                 segments: (1) the acknowledgment, (2) a one byte
+                 increase in the window, and (3) the echoed character,
+                 respectively.
+
+         4.2.2.15  Retransmission Timeout: RFC-793 Section 3.7, page 41
+
+            The algorithm suggested in RFC-793 for calculating the
+            retransmission timeout is now known to be inadequate; see
+            Section 4.2.3.1 below.
+
+            Recent work by Jacobson [TCP:7] on Internet congestion and
+            TCP retransmission stability has produced a transmission
+            algorithm combining "slow start" with "congestion
+            avoidance".  A TCP MUST implement this algorithm.
+
+            If a retransmitted packet is identical to the original
+            packet (which implies not only that the data boundaries have
+            not changed, but also that the window and acknowledgment
+            fields of the header have not changed), then the same IP
+            Identification field MAY be used (see Section 3.2.1.5).
+
+            IMPLEMENTATION:
+                 Some TCP implementors have chosen to "packetize" the
+                 data stream, i.e., to pick segment boundaries when
+
+
+
+Internet Engineering Task Force                                [Page 90]
+
+
+
+
+RFC1122                  TRANSPORT LAYER -- TCP             October 1989
+
+
+                 segments are originally sent and to queue these
+                 segments in a "retransmission queue" until they are
+                 acknowledged.  Another design (which may be simpler) is
+                 to defer packetizing until each time data is
+                 transmitted or retransmitted, so there will be no
+                 segment retransmission queue.
+
+                 In an implementation with a segment retransmission
+                 queue, TCP performance may be enhanced by repacketizing
+                 the segments awaiting acknowledgment when the first
+                 retransmission timeout occurs.  That is, the
+                 outstanding segments that fitted would be combined into
+                 one maximum-sized segment, with a new IP Identification
+                 value.  The TCP would then retain this combined segment
+                 in the retransmit queue until it was acknowledged.
+                 However, if the first two segments in the
+                 retransmission queue totalled more than one maximum-
+                 sized segment, the TCP would retransmit only the first
+                 segment using the original IP Identification field.
+
+         4.2.2.16  Managing the Window: RFC-793 Section 3.7, page 41
+
+            A TCP receiver SHOULD NOT shrink the window, i.e., move the
+            right window edge to the left.  However, a sending TCP MUST
+            be robust against window shrinking, which may cause the
+            "useable window" (see Section 4.2.3.4) to become negative.
+
+            If this happens, the sender SHOULD NOT send new data, but
+            SHOULD retransmit normally the old unacknowledged data
+            between SND.UNA and SND.UNA+SND.WND.  The sender MAY also
+            retransmit old data beyond SND.UNA+SND.WND, but SHOULD NOT
+            time out the connection if data beyond the right window edge
+            is not acknowledged.  If the window shrinks to zero, the TCP
+            MUST probe it in the standard way (see next Section).
+
+            DISCUSSION:
+                 Many TCP implementations become confused if the window
+                 shrinks from the right after data has been sent into a
+                 larger window.  Note that TCP has a heuristic to select
+                 the latest window update despite possible datagram
+                 reordering; as a result, it may ignore a window update
+                 with a smaller window than previously offered if
+                 neither the sequence number nor the acknowledgment
+                 number is increased.
+
+
+
+
+
+
+
+Internet Engineering Task Force                                [Page 91]
+
+
+
+
+RFC1122                  TRANSPORT LAYER -- TCP             October 1989
+
+
+         4.2.2.17  Probing Zero Windows: RFC-793 Section 3.7, page 42
+
+            Probing of zero (offered) windows MUST be supported.
+
+            A TCP MAY keep its offered receive window closed
+            indefinitely.  As long as the receiving TCP continues to
+            send acknowledgments in response to the probe segments, the
+            sending TCP MUST allow the connection to stay open.
+
+            DISCUSSION:
+                 It is extremely important to remember that ACK
+                 (acknowledgment) segments that contain no data are not
+                 reliably transmitted by TCP.  If zero window probing is
+                 not supported, a connection may hang forever when an
+                 ACK segment that re-opens the window is lost.
+
+                 The delay in opening a zero window generally occurs
+                 when the receiving application stops taking data from
+                 its TCP.  For example, consider a printer daemon
+                 application, stopped because the printer ran out of
+                 paper.
+
+            The transmitting host SHOULD send the first zero-window
+            probe when a zero window has existed for the retransmission
+            timeout period (see Section 4.2.2.15), and SHOULD increase
+            exponentially the interval between successive probes.
+
+            DISCUSSION:
+                 This procedure minimizes delay if the zero-window
+                 condition is due to a lost ACK segment containing a
+                 window-opening update.  Exponential backoff is
+                 recommended, possibly with some maximum interval not
+                 specified here.  This procedure is similar to that of
+                 the retransmission algorithm, and it may be possible to
+                 combine the two procedures in the implementation.
+
+         4.2.2.18  Passive OPEN Calls:  RFC-793 Section 3.8
+
+            Every passive OPEN call either creates a new connection
+            record in LISTEN state, or it returns an error; it MUST NOT
+            affect any previously created connection record.
+
+            A TCP that supports multiple concurrent users MUST provide
+            an OPEN call that will functionally allow an application to
+            LISTEN on a port while a connection block with the same
+            local port is in SYN-SENT or SYN-RECEIVED state.
+
+            DISCUSSION:
+
+
+
+Internet Engineering Task Force                                [Page 92]
+
+
+
+
+RFC1122                  TRANSPORT LAYER -- TCP             October 1989
+
+
+                 Some applications (e.g., SMTP servers) may need to
+                 handle multiple connection attempts at about the same
+                 time.  The probability of a connection attempt failing
+                 is reduced by giving the application some means of
+                 listening for a new connection at the same time that an
+                 earlier connection attempt is going through the three-
+                 way handshake.
+
+            IMPLEMENTATION:
+                 Acceptable implementations of concurrent opens may
+                 permit multiple passive OPEN calls, or they may allow
+                 "cloning" of LISTEN-state connections from a single
+                 passive OPEN call.
+
+         4.2.2.19  Time to Live: RFC-793 Section 3.9, page 52
+
+            RFC-793 specified that TCP was to request the IP layer to
+            send TCP segments with TTL = 60.  This is obsolete; the TTL
+            value used to send TCP segments MUST be configurable.  See
+            Section 3.2.1.7 for discussion.
+
+         4.2.2.20  Event Processing: RFC-793 Section 3.9
+
+            While it is not strictly required, a TCP SHOULD be capable
+            of queueing out-of-order TCP segments.  Change the "may" in
+            the last sentence of the first paragraph on page 70 to
+            "should".
+
+            DISCUSSION:
+                 Some small-host implementations have omitted segment
+                 queueing because of limited buffer space.  This
+                 omission may be expected to adversely affect TCP
+                 throughput, since loss of a single segment causes all
+                 later segments to appear to be "out of sequence".
+
+            In general, the processing of received segments MUST be
+            implemented to aggregate ACK segments whenever possible.
+            For example, if the TCP is processing a series of queued
+            segments, it MUST process them all before sending any ACK
+            segments.
+
+            Here are some detailed error corrections and notes on the
+            Event Processing section of RFC-793.
+
+            (a)  CLOSE Call, CLOSE-WAIT state, p. 61: enter LAST-ACK
+                 state, not CLOSING.
+
+            (b)  LISTEN state, check for SYN (pp. 65, 66): With a SYN
+
+
+
+Internet Engineering Task Force                                [Page 93]
+
+
+
+
+RFC1122                  TRANSPORT LAYER -- TCP             October 1989
+
+
+                 bit, if the security/compartment or the precedence is
+                 wrong for the segment, a reset is sent.  The wrong form
+                 of reset is shown in the text; it should be:
+
+                   <SEQ=0><ACK=SEG.SEQ+SEG.LEN><CTL=RST,ACK>
+
+
+            (c)  SYN-SENT state, Check for SYN, p. 68: When the
+                 connection enters ESTABLISHED state, the following
+                 variables must be set:
+                    SND.WND <- SEG.WND
+                    SND.WL1 <- SEG.SEQ
+                    SND.WL2 <- SEG.ACK
+
+
+            (d)  Check security and precedence, p. 71: The first heading
+                 "ESTABLISHED STATE" should really be a list of all
+                 states other than SYN-RECEIVED: ESTABLISHED, FIN-WAIT-
+                 1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, and
+                 TIME-WAIT.
+
+            (e)  Check SYN bit, p. 71:  "In SYN-RECEIVED state and if
+                 the connection was initiated with a passive OPEN, then
+                 return this connection to the LISTEN state and return.
+                 Otherwise...".
+
+            (f)  Check ACK field, SYN-RECEIVED state, p. 72: When the
+                 connection enters ESTABLISHED state, the variables
+                 listed in (c) must be set.
+
+            (g)  Check ACK field, ESTABLISHED state, p. 72: The ACK is a
+                 duplicate if SEG.ACK =< SND.UNA (the = was omitted).
+                 Similarly, the window should be updated if: SND.UNA =<
+                 SEG.ACK =< SND.NXT.
+
+            (h)  USER TIMEOUT, p. 77:
+
+                 It would be better to notify the application of the
+                 timeout rather than letting TCP force the connection
+                 closed.  However, see also Section 4.2.3.5.
+
+
+         4.2.2.21  Acknowledging Queued Segments: RFC-793 Section 3.9
+
+            A TCP MAY send an ACK segment acknowledging RCV.NXT when a
+            valid segment arrives that is in the window but not at the
+            left window edge.
+
+
+
+
+Internet Engineering Task Force                                [Page 94]
+
+
+
+
+RFC1122                  TRANSPORT LAYER -- TCP             October 1989
+
+
+            DISCUSSION:
+                 RFC-793 (see page 74) was ambiguous about whether or
+                 not an ACK segment should be sent when an out-of-order
+                 segment was received, i.e., when SEG.SEQ was unequal to
+                 RCV.NXT.
+
+                 One reason for ACKing out-of-order segments might be to
+                 support an experimental algorithm known as "fast
+                 retransmit".   With this algorithm, the sender uses the
+                 "redundant" ACK's to deduce that a segment has been
+                 lost before the retransmission timer has expired.  It
+                 counts the number of times an ACK has been received
+                 with the same value of SEG.ACK and with the same right
+                 window edge.  If more than a threshold number of such
+                 ACK's is received, then the segment containing the
+                 octets starting at SEG.ACK is assumed to have been lost
+                 and is retransmitted, without awaiting a timeout.  The
+                 threshold is chosen to compensate for the maximum
+                 likely segment reordering in the Internet.  There is
+                 not yet enough experience with the fast retransmit
+                 algorithm to determine how useful it is.
+
+      4.2.3  SPECIFIC ISSUES
+
+         4.2.3.1  Retransmission Timeout Calculation
+
+            A host TCP MUST implement Karn's algorithm and Jacobson's
+            algorithm for computing the retransmission timeout ("RTO").
+
+            o    Jacobson's algorithm for computing the smoothed round-
+                 trip ("RTT") time incorporates a simple measure of the
+                 variance [TCP:7].
+
+            o    Karn's algorithm for selecting RTT measurements ensures
+                 that ambiguous round-trip times will not corrupt the
+                 calculation of the smoothed round-trip time [TCP:6].
+
+            This implementation also MUST include "exponential backoff"
+            for successive RTO values for the same segment.
+            Retransmission of SYN segments SHOULD use the same algorithm
+            as data segments.
+
+            DISCUSSION:
+                 There were two known problems with the RTO calculations
+                 specified in RFC-793.  First, the accurate measurement
+                 of RTTs is difficult when there are retransmissions.
+                 Second, the algorithm to compute the smoothed round-
+                 trip time is inadequate [TCP:7], because it incorrectly
+
+
+
+Internet Engineering Task Force                                [Page 95]
+
+
+
+
+RFC1122                  TRANSPORT LAYER -- TCP             October 1989
+
+
+                 assumed that the variance in RTT values would be small
+                 and constant.  These problems were solved by Karn's and
+                 Jacobson's algorithm, respectively.
+
+                 The performance increase resulting from the use of
+                 these improvements varies from noticeable to dramatic.
+                 Jacobson's algorithm for incorporating the measured RTT
+                 variance is especially important on a low-speed link,
+                 where the natural variation of packet sizes causes a
+                 large variation in RTT.  One vendor found link
+                 utilization on a 9.6kb line went from 10% to 90% as a
+                 result of implementing Jacobson's variance algorithm in
+                 TCP.
+
+            The following values SHOULD be used to initialize the
+            estimation parameters for a new connection:
+
+            (a)  RTT = 0 seconds.
+
+            (b)  RTO = 3 seconds.  (The smoothed variance is to be
+                 initialized to the value that will result in this RTO).
+
+            The recommended upper and lower bounds on the RTO are known
+            to be inadequate on large internets.  The lower bound SHOULD
+            be measured in fractions of a second (to accommodate high
+            speed LANs) and the upper bound should be 2*MSL, i.e., 240
+            seconds.
+
+            DISCUSSION:
+                 Experience has shown that these initialization values
+                 are reasonable, and that in any case the Karn and
+                 Jacobson algorithms make TCP behavior reasonably
+                 insensitive to the initial parameter choices.
+
+         4.2.3.2  When to Send an ACK Segment
+
+            A host that is receiving a stream of TCP data segments can
+            increase efficiency in both the Internet and the hosts by
+            sending fewer than one ACK (acknowledgment) segment per data
+            segment received; this is known as a "delayed ACK" [TCP:5].
+
+            A TCP SHOULD implement a delayed ACK, but an ACK should not
+            be excessively delayed; in particular, the delay MUST be
+            less than 0.5 seconds, and in a stream of full-sized
+            segments there SHOULD be an ACK for at least every second
+            segment.
+
+            DISCUSSION:
+
+
+
+Internet Engineering Task Force                                [Page 96]
+
+
+
+
+RFC1122                  TRANSPORT LAYER -- TCP             October 1989
+
+
+                 A delayed ACK gives the application an opportunity to
+                 update the window and perhaps to send an immediate
+                 response.  In particular, in the case of character-mode
+                 remote login, a delayed ACK can reduce the number of
+                 segments sent by the server by a factor of 3 (ACK,
+                 window update, and echo character all combined in one
+                 segment).
+
+                 In addition, on some large multi-user hosts, a delayed
+                 ACK can substantially reduce protocol processing
+                 overhead by reducing the total number of packets to be
+                 processed [TCP:5].  However, excessive delays on ACK's
+                 can disturb the round-trip timing and packet "clocking"
+                 algorithms [TCP:7].
+
+         4.2.3.3  When to Send a Window Update
+
+            A TCP MUST include a SWS avoidance algorithm in the receiver
+            [TCP:5].
+
+            IMPLEMENTATION:
+                 The receiver's SWS avoidance algorithm determines when
+                 the right window edge may be advanced; this is
+                 customarily known as "updating the window".  This
+                 algorithm combines with the delayed ACK algorithm (see
+                 Section 4.2.3.2) to determine when an ACK segment
+                 containing the current window will really be sent to
+                 the receiver.  We use the notation of RFC-793; see
+                 Figures 4 and 5 in that document.
+
+                 The solution to receiver SWS is to avoid advancing the
+                 right window edge RCV.NXT+RCV.WND in small increments,
+                 even if data is received from the network in small
+                 segments.
+
+                 Suppose the total receive buffer space is RCV.BUFF.  At
+                 any given moment, RCV.USER octets of this total may be
+                 tied up with data that has been received and
+                 acknowledged but which the user process has not yet
+                 consumed.  When the connection is quiescent, RCV.WND =
+                 RCV.BUFF and RCV.USER = 0.
+
+                 Keeping the right window edge fixed as data arrives and
+                 is acknowledged requires that the receiver offer less
+                 than its full buffer space, i.e., the receiver must
+                 specify a RCV.WND that keeps RCV.NXT+RCV.WND constant
+                 as RCV.NXT increases.  Thus, the total buffer space
+                 RCV.BUFF is generally divided into three parts:
+
+
+
+Internet Engineering Task Force                                [Page 97]
+
+
+
+
+RFC1122                  TRANSPORT LAYER -- TCP             October 1989
+
+
+
+                 |<------- RCV.BUFF ---------------->|
+                      1             2            3
+             ----|---------|------------------|------|----
+                        RCV.NXT               ^
+                                           (Fixed)
+
+             1 - RCV.USER =  data received but not yet consumed;
+             2 - RCV.WND =   space advertised to sender;
+             3 - Reduction = space available but not yet
+                             advertised.
+
+
+                 The suggested SWS avoidance algorithm for the receiver
+                 is to keep RCV.NXT+RCV.WND fixed until the reduction
+                 satisfies:
+
+                      RCV.BUFF - RCV.USER - RCV.WND  >=
+
+                             min( Fr * RCV.BUFF, Eff.snd.MSS )
+
+                 where Fr is a fraction whose recommended value is 1/2,
+                 and Eff.snd.MSS is the effective send MSS for the
+                 connection (see Section 4.2.2.6).  When the inequality
+                 is satisfied, RCV.WND is set to RCV.BUFF-RCV.USER.
+
+                 Note that the general effect of this algorithm is to
+                 advance RCV.WND in increments of Eff.snd.MSS (for
+                 realistic receive buffers:  Eff.snd.MSS < RCV.BUFF/2).
+                 Note also that the receiver must use its own
+                 Eff.snd.MSS, assuming it is the same as the sender's.
+
+         4.2.3.4  When to Send Data
+
+            A TCP MUST include a SWS avoidance algorithm in the sender.
+
+            A TCP SHOULD implement the Nagle Algorithm [TCP:9] to
+            coalesce short segments.  However, there MUST be a way for
+            an application to disable the Nagle algorithm on an
+            individual connection.  In all cases, sending data is also
+            subject to the limitation imposed by the Slow Start
+            algorithm (Section 4.2.2.15).
+
+            DISCUSSION:
+                 The Nagle algorithm is generally as follows:
+
+                      If there is unacknowledged data (i.e., SND.NXT >
+                      SND.UNA), then the sending TCP buffers all user
+
+
+
+Internet Engineering Task Force                                [Page 98]
+
+
+
+
+RFC1122                  TRANSPORT LAYER -- TCP             October 1989
+
+
+                      data (regardless of the PSH bit), until the
+                      outstanding data has been acknowledged or until
+                      the TCP can send a full-sized segment (Eff.snd.MSS
+                      bytes; see Section 4.2.2.6).
+
+                 Some applications (e.g., real-time display window
+                 updates) require that the Nagle algorithm be turned
+                 off, so small data segments can be streamed out at the
+                 maximum rate.
+
+            IMPLEMENTATION:
+                 The sender's SWS avoidance algorithm is more difficult
+                 than the receivers's, because the sender does not know
+                 (directly) the receiver's total buffer space RCV.BUFF.
+                 An approach which has been found to work well is for
+                 the sender to calculate Max(SND.WND), the maximum send
+                 window it has seen so far on the connection, and to use
+                 this value as an estimate of RCV.BUFF.  Unfortunately,
+                 this can only be an estimate; the receiver may at any
+                 time reduce the size of RCV.BUFF.  To avoid a resulting
+                 deadlock, it is necessary to have a timeout to force
+                 transmission of data, overriding the SWS avoidance
+                 algorithm.  In practice, this timeout should seldom
+                 occur.
+
+                 The "useable window" [TCP:5] is:
+
+                      U = SND.UNA + SND.WND - SND.NXT
+
+                 i.e., the offered window less the amount of data sent
+                 but not acknowledged.  If D is the amount of data
+                 queued in the sending TCP but not yet sent, then the
+                 following set of rules is recommended.
+
+                 Send data:
+
+                 (1)  if a maximum-sized segment can be sent, i.e, if:
+
+                           min(D,U) >= Eff.snd.MSS;
+
+
+                 (2)  or if the data is pushed and all queued data can
+                      be sent now, i.e., if:
+
+                          [SND.NXT = SND.UNA and] PUSHED and D <= U
+
+                      (the bracketed condition is imposed by the Nagle
+                      algorithm);
+
+
+
+Internet Engineering Task Force                                [Page 99]
+
+
+
+
+RFC1122                  TRANSPORT LAYER -- TCP             October 1989
+
+
+                 (3)  or if at least a fraction Fs of the maximum window
+                      can be sent, i.e., if:
+
+                          [SND.NXT = SND.UNA and]
+
+                                  min(D.U) >= Fs * Max(SND.WND);
+
+
+                 (4)  or if data is PUSHed and the override timeout
+                      occurs.
+
+                 Here Fs is a fraction whose recommended value is 1/2.
+                 The override timeout should be in the range 0.1 - 1.0
+                 seconds.  It may be convenient to combine this timer
+                 with the timer used to probe zero windows (Section
+                 4.2.2.17).
+
+                 Finally, note that the SWS avoidance algorithm just
+                 specified is to be used instead of the sender-side
+                 algorithm contained in [TCP:5].
+
+         4.2.3.5  TCP Connection Failures
+
+            Excessive retransmission of the same segment by TCP
+            indicates some failure of the remote host or the Internet
+            path.  This failure may be of short or long duration.  The
+            following procedure MUST be used to handle excessive
+            retransmissions of data segments [IP:11]:
+
+            (a)  There are two thresholds R1 and R2 measuring the amount
+                 of retransmission that has occurred for the same
+                 segment.  R1 and R2 might be measured in time units or
+                 as a count of retransmissions.
+
+            (b)  When the number of transmissions of the same segment
+                 reaches or exceeds threshold R1, pass negative advice
+                 (see Section 3.3.1.4) to the IP layer, to trigger
+                 dead-gateway diagnosis.
+
+            (c)  When the number of transmissions of the same segment
+                 reaches a threshold R2 greater than R1, close the
+                 connection.
+
+            (d)  An application MUST be able to set the value for R2 for
+                 a particular connection.  For example, an interactive
+                 application might set R2 to "infinity," giving the user
+                 control over when to disconnect.
+
+
+
+
+Internet Engineering Task Force                               [Page 100]
+
+
+
+
+RFC1122                  TRANSPORT LAYER -- TCP             October 1989
+
+
+            (d)  TCP SHOULD inform the application of the delivery
+                 problem (unless such information has been disabled by
+                 the application; see Section 4.2.4.1), when R1 is
+                 reached and before R2.  This will allow a remote login
+                 (User Telnet) application program to inform the user,
+                 for example.
+
+            The value of R1 SHOULD correspond to at least 3
+            retransmissions, at the current RTO.  The value of R2 SHOULD
+            correspond to at least 100 seconds.
+
+            An attempt to open a TCP connection could fail with
+            excessive retransmissions of the SYN segment or by receipt
+            of a RST segment or an ICMP Port Unreachable.  SYN
+            retransmissions MUST be handled in the general way just
+            described for data retransmissions, including notification
+            of the application layer.
+
+            However, the values of R1 and R2 may be different for SYN
+            and data segments.  In particular, R2 for a SYN segment MUST
+            be set large enough to provide retransmission of the segment
+            for at least 3 minutes.  The application can close the
+            connection (i.e., give up on the open attempt) sooner, of
+            course.
+
+            DISCUSSION:
+                 Some Internet paths have significant setup times, and
+                 the number of such paths is likely to increase in the
+                 future.
+
+         4.2.3.6  TCP Keep-Alives
+
+            Implementors MAY include "keep-alives" in their TCP
+            implementations, although this practice is not universally
+            accepted.  If keep-alives are included, the application MUST
+            be able to turn them on or off for each TCP connection, and
+            they MUST default to off.
+
+            Keep-alive packets MUST only be sent when no data or
+            acknowledgement packets have been received for the
+            connection within an interval.  This interval MUST be
+            configurable and MUST default to no less than two hours.
+
+            It is extremely important to remember that ACK segments that
+            contain no data are not reliably transmitted by TCP.
+            Consequently, if a keep-alive mechanism is implemented it
+            MUST NOT interpret failure to respond to any specific probe
+            as a dead connection.
+
+
+
+Internet Engineering Task Force                               [Page 101]
+
+
+
+
+RFC1122                  TRANSPORT LAYER -- TCP             October 1989
+
+
+            An implementation SHOULD send a keep-alive segment with no
+            data; however, it MAY be configurable to send a keep-alive
+            segment containing one garbage octet, for compatibility with
+            erroneous TCP implementations.
+
+            DISCUSSION:
+                 A "keep-alive" mechanism periodically probes the other
+                 end of a connection when the connection is otherwise
+                 idle, even when there is no data to be sent.  The TCP
+                 specification does not include a keep-alive mechanism
+                 because it could:  (1) cause perfectly good connections
+                 to break during transient Internet failures; (2)
+                 consume unnecessary bandwidth ("if no one is using the
+                 connection, who cares if it is still good?"); and (3)
+                 cost money for an Internet path that charges for
+                 packets.
+
+                 Some TCP implementations, however, have included a
+                 keep-alive mechanism.  To confirm that an idle
+                 connection is still active, these implementations send
+                 a probe segment designed to elicit a response from the
+                 peer TCP.  Such a segment generally contains SEG.SEQ =
+                 SND.NXT-1 and may or may not contain one garbage octet
+                 of data.  Note that on a quiet connection SND.NXT =
+                 RCV.NXT, so that this SEG.SEQ will be outside the
+                 window.  Therefore, the probe causes the receiver to
+                 return an acknowledgment segment, confirming that the
+                 connection is still live.  If the peer has dropped the
+                 connection due to a network partition or a crash, it
+                 will respond with a RST instead of an acknowledgment
+                 segment.
+
+                 Unfortunately, some misbehaved TCP implementations fail
+                 to respond to a segment with SEG.SEQ = SND.NXT-1 unless
+                 the segment contains data.  Alternatively, an
+                 implementation could determine whether a peer responded
+                 correctly to keep-alive packets with no garbage data
+                 octet.
+
+                 A TCP keep-alive mechanism should only be invoked in
+                 server applications that might otherwise hang
+                 indefinitely and consume resources unnecessarily if a
+                 client crashes or aborts a connection during a network
+                 failure.
+
+
+
+
+
+
+
+Internet Engineering Task Force                               [Page 102]
+
+
+
+
+RFC1122                  TRANSPORT LAYER -- TCP             October 1989
+
+
+         4.2.3.7  TCP Multihoming
+
+            If an application on a multihomed host does not specify the
+            local IP address when actively opening a TCP connection,
+            then the TCP MUST ask the IP layer to select a local IP
+            address before sending the (first) SYN.  See the function
+            GET_SRCADDR() in Section 3.4.
+
+            At all other times, a previous segment has either been sent
+            or received on this connection, and TCP MUST use the same
+            local address is used that was used in those previous
+            segments.
+
+         4.2.3.8  IP Options
+
+            When received options are passed up to TCP from the IP
+            layer, TCP MUST ignore options that it does not understand.
+
+            A TCP MAY support the Time Stamp and Record Route options.
+
+            An application MUST be able to specify a source route when
+            it actively opens a TCP connection, and this MUST take
+            precedence over a source route received in a datagram.
+
+            When a TCP connection is OPENed passively and a packet
+            arrives with a completed IP Source Route option (containing
+            a return route), TCP MUST save the return route and use it
+            for all segments sent on this connection.  If a different
+            source route arrives in a later segment, the later
+            definition SHOULD override the earlier one.
+
+         4.2.3.9  ICMP Messages
+
+            TCP MUST act on an ICMP error message passed up from the IP
+            layer, directing it to the connection that created the
+            error.  The necessary demultiplexing information can be
+            found in the IP header contained within the ICMP message.
+
+            o    Source Quench
+
+                 TCP MUST react to a Source Quench by slowing
+                 transmission on the connection.  The RECOMMENDED
+                 procedure is for a Source Quench to trigger a "slow
+                 start," as if a retransmission timeout had occurred.
+
+            o    Destination Unreachable -- codes 0, 1, 5
+
+                 Since these Unreachable messages indicate soft error
+
+
+
+Internet Engineering Task Force                               [Page 103]
+
+
+
+
+RFC1122                  TRANSPORT LAYER -- TCP             October 1989
+
+
+                 conditions, TCP MUST NOT abort the connection, and it
+                 SHOULD make the information available to the
+                 application.
+
+                 DISCUSSION:
+                      TCP could report the soft error condition directly
+                      to the application layer with an upcall to the
+                      ERROR_REPORT routine, or it could merely note the
+                      message and report it to the application only when
+                      and if the TCP connection times out.
+
+            o    Destination Unreachable -- codes 2-4
+
+                 These are hard error conditions, so TCP SHOULD abort
+                 the connection.
+
+            o    Time Exceeded -- codes 0, 1
+
+                 This should be handled the same way as Destination
+                 Unreachable codes 0, 1, 5 (see above).
+
+            o    Parameter Problem
+
+                 This should be handled the same way as Destination
+                 Unreachable codes 0, 1, 5 (see above).
+
+
+         4.2.3.10  Remote Address Validation
+
+            A TCP implementation MUST reject as an error a local OPEN
+            call for an invalid remote IP address (e.g., a broadcast or
+            multicast address).
+
+            An incoming SYN with an invalid source address must be
+            ignored either by TCP or by the IP layer (see Section
+            3.2.1.3).
+
+            A TCP implementation MUST silently discard an incoming SYN
+            segment that is addressed to a broadcast or multicast
+            address.
+
+         4.2.3.11  TCP Traffic Patterns
+
+            IMPLEMENTATION:
+                 The TCP protocol specification [TCP:1] gives the
+                 implementor much freedom in designing the algorithms
+                 that control the message flow over the connection --
+                 packetizing, managing the window, sending
+
+
+
+Internet Engineering Task Force                               [Page 104]
+
+
+
+
+RFC1122                  TRANSPORT LAYER -- TCP             October 1989
+
+
+                 acknowledgments, etc.  These design decisions are
+                 difficult because a TCP must adapt to a wide range of
+                 traffic patterns.  Experience has shown that a TCP
+                 implementor needs to verify the design on two extreme
+                 traffic patterns:
+
+                 o    Single-character Segments
+
+                      Even if the sender is using the Nagle Algorithm,
+                      when a TCP connection carries remote login traffic
+                      across a low-delay LAN the receiver will generally
+                      get a stream of single-character segments.  If
+                      remote terminal echo mode is in effect, the
+                      receiver's system will generally echo each
+                      character as it is received.
+
+                 o    Bulk Transfer
+
+                      When TCP is used for bulk transfer, the data
+                      stream should be made up (almost) entirely of
+                      segments of the size of the effective MSS.
+                      Although TCP uses a sequence number space with
+                      byte (octet) granularity, in bulk-transfer mode
+                      its operation should be as if TCP used a sequence
+                      space that counted only segments.
+
+                 Experience has furthermore shown that a single TCP can
+                 effectively and efficiently handle these two extremes.
+
+                 The most important tool for verifying a new TCP
+                 implementation is a packet trace program.  There is a
+                 large volume of experience showing the importance of
+                 tracing a variety of traffic patterns with other TCP
+                 implementations and studying the results carefully.
+
+
+         4.2.3.12  Efficiency
+
+            IMPLEMENTATION:
+                 Extensive experience has led to the following
+                 suggestions for efficient implementation of TCP:
+
+                 (a)  Don't Copy Data
+
+                      In bulk data transfer, the primary CPU-intensive
+                      tasks are copying data from one place to another
+                      and checksumming the data.  It is vital to
+                      minimize the number of copies of TCP data.  Since
+
+
+
+Internet Engineering Task Force                               [Page 105]
+
+
+
+
+RFC1122                  TRANSPORT LAYER -- TCP             October 1989
+
+
+                      the ultimate speed limitation may be fetching data
+                      across the memory bus, it may be useful to combine
+                      the copy with checksumming, doing both with a
+                      single memory fetch.
+
+                 (b)  Hand-Craft the Checksum Routine
+
+                      A good TCP checksumming routine is typically two
+                      to five times faster than a simple and direct
+                      implementation of the definition.  Great care and
+                      clever coding are often required and advisable to
+                      make the checksumming code "blazing fast".  See
+                      [TCP:10].
+
+                 (c)  Code for the Common Case
+
+                      TCP protocol processing can be complicated, but
+                      for most segments there are only a few simple
+                      decisions to be made.  Per-segment processing will
+                      be greatly speeded up by coding the main line to
+                      minimize the number of decisions in the most
+                      common case.
+
+
+      4.2.4  TCP/APPLICATION LAYER INTERFACE
+
+         4.2.4.1  Asynchronous Reports
+
+            There MUST be a mechanism for reporting soft TCP error
+            conditions to the application.  Generically, we assume this
+            takes the form of an application-supplied ERROR_REPORT
+            routine that may be upcalled [INTRO:7] asynchronously from
+            the transport layer:
+
+               ERROR_REPORT(local connection name, reason, subreason)
+
+            The precise encoding of the reason and subreason parameters
+            is not specified here.  However, the conditions that are
+            reported asynchronously to the application MUST include:
+
+            *    ICMP error message arrived (see 4.2.3.9)
+
+            *    Excessive retransmissions (see 4.2.3.5)
+
+            *    Urgent pointer advance (see 4.2.2.4).
+
+            However, an application program that does not want to
+            receive such ERROR_REPORT calls SHOULD be able to
+
+
+
+Internet Engineering Task Force                               [Page 106]
+
+
+
+
+RFC1122                  TRANSPORT LAYER -- TCP             October 1989
+
+
+            effectively disable these calls.
+
+            DISCUSSION:
+                 These error reports generally reflect soft errors that
+                 can be ignored without harm by many applications.  It
+                 has been suggested that these error report calls should
+                 default to "disabled," but this is not required.
+
+         4.2.4.2  Type-of-Service
+
+            The application layer MUST be able to specify the Type-of-
+            Service (TOS) for segments that are sent on a connection.
+            It not required, but the application SHOULD be able to
+            change the TOS during the connection lifetime.  TCP SHOULD
+            pass the current TOS value without change to the IP layer,
+            when it sends segments on the connection.
+
+            The TOS will be specified independently in each direction on
+            the connection, so that the receiver application will
+            specify the TOS used for ACK segments.
+
+            TCP MAY pass the most recently received TOS up to the
+            application.
+
+            DISCUSSION
+                 Some applications (e.g., SMTP) change the nature of
+                 their communication during the lifetime of a
+                 connection, and therefore would like to change the TOS
+                 specification.
+
+                 Note also that the OPEN call specified in RFC-793
+                 includes a parameter ("options") in which the caller
+                 can specify IP options such as source route, record
+                 route, or timestamp.
+
+         4.2.4.3  Flush Call
+
+            Some TCP implementations have included a FLUSH call, which
+            will empty the TCP send queue of any data for which the user
+            has issued SEND calls but which is still to the right of the
+            current send window.  That is, it flushes as much queued
+            send data as possible without losing sequence number
+            synchronization.  This is useful for implementing the "abort
+            output" function of Telnet.
+
+
+
+
+
+
+
+Internet Engineering Task Force                               [Page 107]
+
+
+
+
+RFC1122                  TRANSPORT LAYER -- TCP             October 1989
+
+
+         4.2.4.4  Multihoming
+
+            The user interface outlined in sections 2.7 and 3.8 of RFC-
+            793 needs to be extended for multihoming.  The OPEN call
+            MUST have an optional parameter:
+
+                OPEN( ... [local IP address,] ... )
+
+            to allow the specification of the local IP address.
+
+            DISCUSSION:
+                 Some TCP-based applications need to specify the local
+                 IP address to be used to open a particular connection;
+                 FTP is an example.
+
+            IMPLEMENTATION:
+                 A passive OPEN call with a specified "local IP address"
+                 parameter will await an incoming connection request to
+                 that address.  If the parameter is unspecified, a
+                 passive OPEN will await an incoming connection request
+                 to any local IP address, and then bind the local IP
+                 address of the connection to the particular address
+                 that is used.
+
+                 For an active OPEN call, a specified "local IP address"
+                 parameter will be used for opening the connection.  If
+                 the parameter is unspecified, the networking software
+                 will choose an appropriate local IP address (see
+                 Section 3.3.4.2) for the connection
+
+      4.2.5  TCP REQUIREMENT SUMMARY
+
+                                                 |        | | | |S| |
+                                                 |        | | | |H| |F
+                                                 |        | | | |O|M|o
+                                                 |        | |S| |U|U|o
+                                                 |        | |H| |L|S|t
+                                                 |        |M|O| |D|T|n
+                                                 |        |U|U|M| | |o
+                                                 |        |S|L|A|N|N|t
+                                                 |        |T|D|Y|O|O|t
+FEATURE                                          |SECTION | | | |T|T|e
+-------------------------------------------------|--------|-|-|-|-|-|--
+                                                 |        | | | | | |
+Push flag                                        |        | | | | | |
+  Aggregate or queue un-pushed data              |4.2.2.2 | | |x| | |
+  Sender collapse successive PSH flags           |4.2.2.2 | |x| | | |
+  SEND call can specify PUSH                     |4.2.2.2 | | |x| | |
+
+
+
+Internet Engineering Task Force                               [Page 108]
+
+
+
+
+RFC1122                  TRANSPORT LAYER -- TCP             October 1989
+
+
+    If cannot: sender buffer indefinitely        |4.2.2.2 | | | | |x|
+    If cannot: PSH last segment                  |4.2.2.2 |x| | | | |
+  Notify receiving ALP of PSH                    |4.2.2.2 | | |x| | |1
+  Send max size segment when possible            |4.2.2.2 | |x| | | |
+                                                 |        | | | | | |
+Window                                           |        | | | | | |
+  Treat as unsigned number                       |4.2.2.3 |x| | | | |
+  Handle as 32-bit number                        |4.2.2.3 | |x| | | |
+  Shrink window from right                       |4.2.2.16| | | |x| |
+  Robust against shrinking window                |4.2.2.16|x| | | | |
+  Receiver's window closed indefinitely          |4.2.2.17| | |x| | |
+  Sender probe zero window                       |4.2.2.17|x| | | | |
+    First probe after RTO                        |4.2.2.17| |x| | | |
+    Exponential backoff                          |4.2.2.17| |x| | | |
+  Allow window stay zero indefinitely            |4.2.2.17|x| | | | |
+  Sender timeout OK conn with zero wind          |4.2.2.17| | | | |x|
+                                                 |        | | | | | |
+Urgent Data                                      |        | | | | | |
+  Pointer points to last octet                   |4.2.2.4 |x| | | | |
+  Arbitrary length urgent data sequence          |4.2.2.4 |x| | | | |
+  Inform ALP asynchronously of urgent data       |4.2.2.4 |x| | | | |1
+  ALP can learn if/how much urgent data Q'd      |4.2.2.4 |x| | | | |1
+                                                 |        | | | | | |
+TCP Options                                      |        | | | | | |
+  Receive TCP option in any segment              |4.2.2.5 |x| | | | |
+  Ignore unsupported options                     |4.2.2.5 |x| | | | |
+  Cope with illegal option length                |4.2.2.5 |x| | | | |
+  Implement sending & receiving MSS option       |4.2.2.6 |x| | | | |
+  Send MSS option unless 536                     |4.2.2.6 | |x| | | |
+  Send MSS option always                         |4.2.2.6 | | |x| | |
+  Send-MSS default is 536                        |4.2.2.6 |x| | | | |
+  Calculate effective send seg size              |4.2.2.6 |x| | | | |
+                                                 |        | | | | | |
+TCP Checksums                                    |        | | | | | |
+  Sender compute checksum                        |4.2.2.7 |x| | | | |
+  Receiver check checksum                        |4.2.2.7 |x| | | | |
+                                                 |        | | | | | |
+Use clock-driven ISN selection                   |4.2.2.9 |x| | | | |
+                                                 |        | | | | | |
+Opening Connections                              |        | | | | | |
+  Support simultaneous open attempts             |4.2.2.10|x| | | | |
+  SYN-RCVD remembers last state                  |4.2.2.11|x| | | | |
+  Passive Open call interfere with others        |4.2.2.18| | | | |x|
+  Function: simultan. LISTENs for same port      |4.2.2.18|x| | | | |
+  Ask IP for src address for SYN if necc.        |4.2.3.7 |x| | | | |
+    Otherwise, use local addr of conn.           |4.2.3.7 |x| | | | |
+  OPEN to broadcast/multicast IP Address         |4.2.3.14| | | | |x|
+  Silently discard seg to bcast/mcast addr       |4.2.3.14|x| | | | |
+
+
+
+Internet Engineering Task Force                               [Page 109]
+
+
+
+
+RFC1122                  TRANSPORT LAYER -- TCP             October 1989
+
+
+                                                 |        | | | | | |
+Closing Connections                              |        | | | | | |
+  RST can contain data                           |4.2.2.12| |x| | | |
+  Inform application of aborted conn             |4.2.2.13|x| | | | |
+  Half-duplex close connections                  |4.2.2.13| | |x| | |
+    Send RST to indicate data lost               |4.2.2.13| |x| | | |
+  In TIME-WAIT state for 2xMSL seconds           |4.2.2.13|x| | | | |
+    Accept SYN from TIME-WAIT state              |4.2.2.13| | |x| | |
+                                                 |        | | | | | |
+Retransmissions                                  |        | | | | | |
+  Jacobson Slow Start algorithm                  |4.2.2.15|x| | | | |
+  Jacobson Congestion-Avoidance algorithm        |4.2.2.15|x| | | | |
+  Retransmit with same IP ident                  |4.2.2.15| | |x| | |
+  Karn's algorithm                               |4.2.3.1 |x| | | | |
+  Jacobson's RTO estimation alg.                 |4.2.3.1 |x| | | | |
+  Exponential backoff                            |4.2.3.1 |x| | | | |
+  SYN RTO calc same as data                      |4.2.3.1 | |x| | | |
+  Recommended initial values and bounds          |4.2.3.1 | |x| | | |
+                                                 |        | | | | | |
+Generating ACK's:                                |        | | | | | |
+  Queue out-of-order segments                    |4.2.2.20| |x| | | |
+  Process all Q'd before send ACK                |4.2.2.20|x| | | | |
+  Send ACK for out-of-order segment              |4.2.2.21| | |x| | |
+  Delayed ACK's                                  |4.2.3.2 | |x| | | |
+    Delay < 0.5 seconds                          |4.2.3.2 |x| | | | |
+    Every 2nd full-sized segment ACK'd           |4.2.3.2 |x| | | | |
+  Receiver SWS-Avoidance Algorithm               |4.2.3.3 |x| | | | |
+                                                 |        | | | | | |
+Sending data                                     |        | | | | | |
+  Configurable TTL                               |4.2.2.19|x| | | | |
+  Sender SWS-Avoidance Algorithm                 |4.2.3.4 |x| | | | |
+  Nagle algorithm                                |4.2.3.4 | |x| | | |
+    Application can disable Nagle algorithm      |4.2.3.4 |x| | | | |
+                                                 |        | | | | | |
+Connection Failures:                             |        | | | | | |
+  Negative advice to IP on R1 retxs              |4.2.3.5 |x| | | | |
+  Close connection on R2 retxs                   |4.2.3.5 |x| | | | |
+  ALP can set R2                                 |4.2.3.5 |x| | | | |1
+  Inform ALP of  R1<=retxs<R2                    |4.2.3.5 | |x| | | |1
+  Recommended values for R1, R2                  |4.2.3.5 | |x| | | |
+  Same mechanism for SYNs                        |4.2.3.5 |x| | | | |
+    R2 at least 3 minutes for SYN                |4.2.3.5 |x| | | | |
+                                                 |        | | | | | |
+Send Keep-alive Packets:                         |4.2.3.6 | | |x| | |
+  - Application can request                      |4.2.3.6 |x| | | | |
+  - Default is "off"                             |4.2.3.6 |x| | | | |
+  - Only send if idle for interval               |4.2.3.6 |x| | | | |
+  - Interval configurable                        |4.2.3.6 |x| | | | |
+
+
+
+Internet Engineering Task Force                               [Page 110]
+
+
+
+
+RFC1122                  TRANSPORT LAYER -- TCP             October 1989
+
+
+  - Default at least 2 hrs.                      |4.2.3.6 |x| | | | |
+  - Tolerant of lost ACK's                       |4.2.3.6 |x| | | | |
+                                                 |        | | | | | |
+IP Options                                       |        | | | | | |
+  Ignore options TCP doesn't understand          |4.2.3.8 |x| | | | |
+  Time Stamp support                             |4.2.3.8 | | |x| | |
+  Record Route support                           |4.2.3.8 | | |x| | |
+  Source Route:                                  |        | | | | | |
+    ALP can specify                              |4.2.3.8 |x| | | | |1
+      Overrides src rt in datagram               |4.2.3.8 |x| | | | |
+    Build return route from src rt               |4.2.3.8 |x| | | | |
+    Later src route overrides                    |4.2.3.8 | |x| | | |
+                                                 |        | | | | | |
+Receiving ICMP Messages from IP                  |4.2.3.9 |x| | | | |
+  Dest. Unreach (0,1,5) => inform ALP            |4.2.3.9 | |x| | | |
+  Dest. Unreach (0,1,5) => abort conn            |4.2.3.9 | | | | |x|
+  Dest. Unreach (2-4) => abort conn              |4.2.3.9 | |x| | | |
+  Source Quench => slow start                    |4.2.3.9 | |x| | | |
+  Time Exceeded => tell ALP, don't abort         |4.2.3.9 | |x| | | |
+  Param Problem => tell ALP, don't abort         |4.2.3.9 | |x| | | |
+                                                 |        | | | | | |
+Address Validation                               |        | | | | | |
+  Reject OPEN call to invalid IP address         |4.2.3.10|x| | | | |
+  Reject SYN from invalid IP address             |4.2.3.10|x| | | | |
+  Silently discard SYN to bcast/mcast addr       |4.2.3.10|x| | | | |
+                                                 |        | | | | | |
+TCP/ALP Interface Services                       |        | | | | | |
+  Error Report mechanism                         |4.2.4.1 |x| | | | |
+  ALP can disable Error Report Routine           |4.2.4.1 | |x| | | |
+  ALP can specify TOS for sending                |4.2.4.2 |x| | | | |
+    Passed unchanged to IP                       |4.2.4.2 | |x| | | |
+  ALP can change TOS during connection           |4.2.4.2 | |x| | | |
+  Pass received TOS up to ALP                    |4.2.4.2 | | |x| | |
+  FLUSH call                                     |4.2.4.3 | | |x| | |
+  Optional local IP addr parm. in OPEN           |4.2.4.4 |x| | | | |
+-------------------------------------------------|--------|-|-|-|-|-|--
+-------------------------------------------------|--------|-|-|-|-|-|--
+
+FOOTNOTES:
+
+(1)  "ALP" means Application-Layer program.
+
+
+
+
+
+
+
+
+
+
+Internet Engineering Task Force                               [Page 111]
+
+
+
+
+RFC1122                  TRANSPORT LAYER -- TCP             October 1989
+
+
+5.  REFERENCES
+
+INTRODUCTORY REFERENCES
+
+
+[INTRO:1] "Requirements for Internet Hosts -- Application and Support,"
+     IETF Host Requirements Working Group, R. Braden, Ed., RFC-1123,
+     October 1989.
+
+[INTRO:2]  "Requirements for Internet Gateways,"  R. Braden and J.
+     Postel, RFC-1009, June 1987.
+
+[INTRO:3]  "DDN Protocol Handbook," NIC-50004, NIC-50005, NIC-50006,
+     (three volumes), SRI International, December 1985.
+
+[INTRO:4]  "Official Internet Protocols," J. Reynolds and J. Postel,
+     RFC-1011, May 1987.
+
+     This document is republished periodically with new RFC numbers; the
+     latest version must be used.
+
+[INTRO:5]  "Protocol Document Order Information," O. Jacobsen and J.
+     Postel, RFC-980, March 1986.
+
+[INTRO:6]  "Assigned Numbers," J. Reynolds and J. Postel, RFC-1010, May
+     1987.
+
+     This document is republished periodically with new RFC numbers; the
+     latest version must be used.
+
+[INTRO:7] "Modularity and Efficiency in Protocol Implementations," D.
+     Clark, RFC-817, July 1982.
+
+[INTRO:8] "The Structuring of Systems Using Upcalls," D. Clark, 10th ACM
+     SOSP, Orcas Island, Washington, December 1985.
+
+
+Secondary References:
+
+
+[INTRO:9]  "A Protocol for Packet Network Intercommunication," V. Cerf
+     and R. Kahn, IEEE Transactions on Communication, May 1974.
+
+[INTRO:10]  "The ARPA Internet Protocol," J. Postel, C. Sunshine, and D.
+     Cohen, Computer Networks, Vol. 5, No. 4, July 1981.
+
+[INTRO:11]  "The DARPA Internet Protocol Suite," B. Leiner, J. Postel,
+     R. Cole and D. Mills, Proceedings INFOCOM 85, IEEE, Washington DC,
+
+
+
+Internet Engineering Task Force                               [Page 112]
+
+
+
+
+RFC1122                  TRANSPORT LAYER -- TCP             October 1989
+
+
+     March 1985.  Also in: IEEE Communications Magazine, March 1985.
+     Also available as ISI-RS-85-153.
+
+[INTRO:12] "Final Text of DIS8473, Protocol for Providing the
+     Connectionless Mode Network Service," ANSI, published as RFC-994,
+     March 1986.
+
+[INTRO:13] "End System to Intermediate System Routing Exchange
+     Protocol," ANSI X3S3.3, published as RFC-995, April 1986.
+
+
+LINK LAYER REFERENCES
+
+
+[LINK:1] "Trailer Encapsulations," S. Leffler and M. Karels, RFC-893,
+     April 1984.
+
+[LINK:2] "An Ethernet Address Resolution Protocol," D. Plummer, RFC-826,
+     November 1982.
+
+[LINK:3] "A Standard for the Transmission of IP Datagrams over Ethernet
+     Networks," C. Hornig, RFC-894, April 1984.
+
+[LINK:4] "A Standard for the Transmission of IP Datagrams over IEEE 802
+     "Networks," J. Postel and J. Reynolds, RFC-1042, February 1988.
+
+     This RFC contains a great deal of information of importance to
+     Internet implementers planning to use IEEE 802 networks.
+
+
+IP LAYER REFERENCES
+
+
+[IP:1] "Internet Protocol (IP)," J. Postel, RFC-791, September 1981.
+
+[IP:2] "Internet Control Message Protocol (ICMP)," J. Postel, RFC-792,
+     September 1981.
+
+[IP:3] "Internet Standard Subnetting Procedure," J. Mogul and J. Postel,
+     RFC-950, August 1985.
+
+[IP:4]  "Host Extensions for IP Multicasting," S. Deering, RFC-1112,
+     August 1989.
+
+[IP:5] "Military Standard Internet Protocol," MIL-STD-1777, Department
+     of Defense, August 1983.
+
+     This specification, as amended by RFC-963, is intended to describe
+
+
+
+Internet Engineering Task Force                               [Page 113]
+
+
+
+
+RFC1122                  TRANSPORT LAYER -- TCP             October 1989
+
+
+     the Internet Protocol but has some serious omissions (e.g., the
+     mandatory subnet extension [IP:3] and the optional multicasting
+     extension [IP:4]).  It is also out of date.  If there is a
+     conflict, RFC-791, RFC-792, and RFC-950 must be taken as
+     authoritative, while the present document is authoritative over
+     all.
+
+[IP:6] "Some Problems with the Specification of the Military Standard
+     Internet Protocol," D. Sidhu, RFC-963, November 1985.
+
+[IP:7] "The TCP Maximum Segment Size and Related Topics," J. Postel,
+     RFC-879, November 1983.
+
+     Discusses and clarifies the relationship between the TCP Maximum
+     Segment Size option and the IP datagram size.
+
+[IP:8] "Internet Protocol Security Options,"  B. Schofield, RFC-1108,
+     October 1989.
+
+[IP:9] "Fragmentation Considered Harmful," C. Kent and J. Mogul, ACM
+     SIGCOMM-87, August 1987.  Published as ACM Comp Comm Review, Vol.
+     17, no. 5.
+
+     This useful paper discusses the problems created by Internet
+     fragmentation and presents alternative solutions.
+
+[IP:10] "IP Datagram Reassembly Algorithms," D. Clark, RFC-815, July
+     1982.
+
+     This and the following paper should be read by every implementor.
+
+[IP:11] "Fault Isolation and Recovery," D. Clark, RFC-816, July 1982.
+
+SECONDARY IP REFERENCES:
+
+
+[IP:12] "Broadcasting Internet Datagrams in the Presence of Subnets," J.
+     Mogul, RFC-922, October 1984.
+
+[IP:13] "Name, Addresses, Ports, and Routes," D. Clark, RFC-814, July
+     1982.
+
+[IP:14] "Something a Host Could Do with Source Quench: The Source Quench
+     Introduced Delay (SQUID)," W. Prue and J. Postel, RFC-1016, July
+     1987.
+
+     This RFC first described directed broadcast addresses.  However,
+     the bulk of the RFC is concerned with gateways, not hosts.
+
+
+
+Internet Engineering Task Force                               [Page 114]
+
+
+
+
+RFC1122                  TRANSPORT LAYER -- TCP             October 1989
+
+
+UDP REFERENCES:
+
+
+[UDP:1] "User Datagram Protocol," J. Postel, RFC-768, August 1980.
+
+
+TCP REFERENCES:
+
+
+[TCP:1] "Transmission Control Protocol," J. Postel, RFC-793, September
+     1981.
+
+
+[TCP:2] "Transmission Control Protocol," MIL-STD-1778, US Department of
+     Defense, August 1984.
+
+     This specification as amended by RFC-964 is intended to describe
+     the same protocol as RFC-793 [TCP:1].  If there is a conflict,
+     RFC-793 takes precedence, and the present document is authoritative
+     over both.
+
+
+[TCP:3] "Some Problems with the Specification of the Military Standard
+     Transmission Control Protocol," D. Sidhu and T. Blumer, RFC-964,
+     November 1985.
+
+
+[TCP:4] "The TCP Maximum Segment Size and Related Topics," J. Postel,
+     RFC-879, November 1983.
+
+
+[TCP:5] "Window and Acknowledgment Strategy in TCP," D. Clark, RFC-813,
+     July 1982.
+
+
+[TCP:6] "Round Trip Time Estimation," P. Karn & C. Partridge, ACM
+     SIGCOMM-87, August 1987.
+
+
+[TCP:7] "Congestion Avoidance and Control," V. Jacobson, ACM SIGCOMM-88,
+     August 1988.
+
+
+SECONDARY TCP REFERENCES:
+
+
+[TCP:8] "Modularity and Efficiency in Protocol Implementation," D.
+     Clark, RFC-817, July 1982.
+
+
+
+Internet Engineering Task Force                               [Page 115]
+
+
+
+
+RFC1122                  TRANSPORT LAYER -- TCP             October 1989
+
+
+[TCP:9] "Congestion Control in IP/TCP," J. Nagle, RFC-896, January 1984.
+
+
+[TCP:10] "Computing the Internet Checksum," R. Braden, D. Borman, and C.
+     Partridge, RFC-1071, September 1988.
+
+
+[TCP:11] "TCP Extensions for Long-Delay Paths," V. Jacobson & R. Braden,
+     RFC-1072, October 1988.
+
+
+Security Considerations
+
+   There are many security issues in the communication layers of host
+   software, but a full discussion is beyond the scope of this RFC.
+
+   The Internet architecture generally provides little protection
+   against spoofing of IP source addresses, so any security mechanism
+   that is based upon verifying the IP source address of a datagram
+   should be treated with suspicion.  However, in restricted
+   environments some source-address checking may be possible.  For
+   example, there might be a secure LAN whose gateway to the rest of the
+   Internet discarded any incoming datagram with a source address that
+   spoofed the LAN address.  In this case, a host on the LAN could use
+   the source address to test for local vs. remote source.  This problem
+   is complicated by source routing, and some have suggested that
+   source-routed datagram forwarding by hosts (see Section 3.3.5) should
+   be outlawed for security reasons.
+
+   Security-related issues are mentioned in sections concerning the IP
+   Security option (Section 3.2.1.8), the ICMP Parameter Problem message
+   (Section 3.2.2.5), IP options in UDP datagrams (Section 4.1.3.2), and
+   reserved TCP ports (Section 4.2.2.1).
+
+Author's Address
+
+   Robert Braden
+   USC/Information Sciences Institute
+   4676 Admiralty Way
+   Marina del Rey, CA 90292-6695
+
+   Phone: (213) 822 1511
+
+   EMail: Braden@ISI.EDU
+
+
+
+
+
+
+
+Internet Engineering Task Force                               [Page 116]
+
diff --git a/doc/rfc/rfc1123.txt b/doc/rfc/rfc1123.txt
new file mode 100644
index 0000000..51cdf83
--- /dev/null
+++ b/doc/rfc/rfc1123.txt
@@ -0,0 +1,5782 @@
+
+
+
+
+
+
+Network Working Group                    Internet Engineering Task Force
+Request for Comments: 1123                             R. Braden, Editor
+                                                            October 1989
+
+
+       Requirements for Internet Hosts -- Application and Support
+
+Status of This Memo
+
+   This RFC is an official specification for the Internet community.  It
+   incorporates by reference, amends, corrects, and supplements the
+   primary protocol standards documents relating to hosts.  Distribution
+   of this document is unlimited.
+
+Summary
+
+   This RFC is one of a pair that defines and discusses the requirements
+   for Internet host software.  This RFC covers the application and
+   support protocols; its companion RFC-1122 covers the communication
+   protocol layers: link layer, IP layer, and transport layer.
+
+
+
+                           Table of Contents
+
+
+
+
+   1.  INTRODUCTION ...............................................    5
+      1.1  The Internet Architecture ..............................    6
+      1.2  General Considerations .................................    6
+         1.2.1  Continuing Internet Evolution .....................    6
+         1.2.2  Robustness Principle ..............................    7
+         1.2.3  Error Logging .....................................    8
+         1.2.4  Configuration .....................................    8
+      1.3  Reading this Document ..................................   10
+         1.3.1  Organization ......................................   10
+         1.3.2  Requirements ......................................   10
+         1.3.3  Terminology .......................................   11
+      1.4  Acknowledgments ........................................   12
+
+   2.  GENERAL ISSUES .............................................   13
+      2.1  Host Names and Numbers .................................   13
+      2.2  Using Domain Name Service ..............................   13
+      2.3  Applications on Multihomed hosts .......................   14
+      2.4  Type-of-Service ........................................   14
+      2.5  GENERAL APPLICATION REQUIREMENTS SUMMARY ...............   15
+
+
+
+
+Internet Engineering Task Force                                 [Page 1]
+
+
+
+
+RFC1123                       INTRODUCTION                  October 1989
+
+
+   3.  REMOTE LOGIN -- TELNET PROTOCOL ............................   16
+      3.1  INTRODUCTION ...........................................   16
+      3.2  PROTOCOL WALK-THROUGH ..................................   16
+         3.2.1  Option Negotiation ................................   16
+         3.2.2  Telnet Go-Ahead Function ..........................   16
+         3.2.3  Control Functions .................................   17
+         3.2.4  Telnet "Synch" Signal .............................   18
+         3.2.5  NVT Printer and Keyboard ..........................   19
+         3.2.6  Telnet Command Structure ..........................   20
+         3.2.7  Telnet Binary Option ..............................   20
+         3.2.8  Telnet Terminal-Type Option .......................   20
+      3.3  SPECIFIC ISSUES ........................................   21
+         3.3.1  Telnet End-of-Line Convention .....................   21
+         3.3.2  Data Entry Terminals ..............................   23
+         3.3.3  Option Requirements ...............................   24
+         3.3.4  Option Initiation .................................   24
+         3.3.5  Telnet Linemode Option ............................   25
+      3.4  TELNET/USER INTERFACE ..................................   25
+         3.4.1  Character Set Transparency ........................   25
+         3.4.2  Telnet Commands ...................................   26
+         3.4.3  TCP Connection Errors .............................   26
+         3.4.4  Non-Default Telnet Contact Port ...................   26
+         3.4.5  Flushing Output ...................................   26
+      3.5.  TELNET REQUIREMENTS SUMMARY ...........................   27
+
+   4.  FILE TRANSFER ..............................................   29
+      4.1  FILE TRANSFER PROTOCOL -- FTP ..........................   29
+         4.1.1  INTRODUCTION ......................................   29
+         4.1.2.  PROTOCOL WALK-THROUGH ............................   29
+            4.1.2.1  LOCAL Type ...................................   29
+            4.1.2.2  Telnet Format Control ........................   30
+            4.1.2.3  Page Structure ...............................   30
+            4.1.2.4  Data Structure Transformations ...............   30
+            4.1.2.5  Data Connection Management ...................   31
+            4.1.2.6  PASV Command .................................   31
+            4.1.2.7  LIST and NLST Commands .......................   31
+            4.1.2.8  SITE Command .................................   32
+            4.1.2.9  STOU Command .................................   32
+            4.1.2.10  Telnet End-of-line Code .....................   32
+            4.1.2.11  FTP Replies .................................   33
+            4.1.2.12  Connections .................................   34
+            4.1.2.13  Minimum Implementation; RFC-959 Section .....   34
+         4.1.3  SPECIFIC ISSUES ...................................   35
+            4.1.3.1  Non-standard Command Verbs ...................   35
+            4.1.3.2  Idle Timeout .................................   36
+            4.1.3.3  Concurrency of Data and Control ..............   36
+            4.1.3.4  FTP Restart Mechanism ........................   36
+         4.1.4  FTP/USER INTERFACE ................................   39
+
+
+
+Internet Engineering Task Force                                 [Page 2]
+
+
+
+
+RFC1123                       INTRODUCTION                  October 1989
+
+
+            4.1.4.1  Pathname Specification .......................   39
+            4.1.4.2  "QUOTE" Command ..............................   40
+            4.1.4.3  Displaying Replies to User ...................   40
+            4.1.4.4  Maintaining Synchronization ..................   40
+         4.1.5   FTP REQUIREMENTS SUMMARY .........................   41
+      4.2  TRIVIAL FILE TRANSFER PROTOCOL -- TFTP .................   44
+         4.2.1  INTRODUCTION ......................................   44
+         4.2.2  PROTOCOL WALK-THROUGH .............................   44
+            4.2.2.1  Transfer Modes ...............................   44
+            4.2.2.2  UDP Header ...................................   44
+         4.2.3  SPECIFIC ISSUES ...................................   44
+            4.2.3.1  Sorcerer's Apprentice Syndrome ...............   44
+            4.2.3.2  Timeout Algorithms ...........................   46
+            4.2.3.3  Extensions ...................................   46
+            4.2.3.4  Access Control ...............................   46
+            4.2.3.5  Broadcast Request ............................   46
+         4.2.4  TFTP REQUIREMENTS SUMMARY .........................   47
+
+   5.  ELECTRONIC MAIL -- SMTP and RFC-822 ........................   48
+      5.1  INTRODUCTION ...........................................   48
+      5.2  PROTOCOL WALK-THROUGH ..................................   48
+         5.2.1  The SMTP Model ....................................   48
+         5.2.2  Canonicalization ..................................   49
+         5.2.3  VRFY and EXPN Commands ............................   50
+         5.2.4  SEND, SOML, and SAML Commands .....................   50
+         5.2.5  HELO Command ......................................   50
+         5.2.6  Mail Relay ........................................   51
+         5.2.7  RCPT Command ......................................   52
+         5.2.8  DATA Command ......................................   53
+         5.2.9  Command Syntax ....................................   54
+         5.2.10  SMTP Replies .....................................   54
+         5.2.11  Transparency .....................................   55
+         5.2.12  WKS Use in MX Processing .........................   55
+         5.2.13  RFC-822 Message Specification ....................   55
+         5.2.14  RFC-822 Date and Time Specification ..............   55
+         5.2.15  RFC-822 Syntax Change ............................   56
+         5.2.16  RFC-822  Local-part ..............................   56
+         5.2.17  Domain Literals ..................................   57
+         5.2.18  Common Address Formatting Errors .................   58
+         5.2.19  Explicit Source Routes ...........................   58
+      5.3  SPECIFIC ISSUES ........................................   59
+         5.3.1  SMTP Queueing Strategies ..........................   59
+            5.3.1.1 Sending Strategy ..............................   59
+            5.3.1.2  Receiving strategy ...........................   61
+         5.3.2  Timeouts in SMTP ..................................   61
+         5.3.3  Reliable Mail Receipt .............................   63
+         5.3.4  Reliable Mail Transmission ........................   63
+         5.3.5  Domain Name Support ...............................   65
+
+
+
+Internet Engineering Task Force                                 [Page 3]
+
+
+
+
+RFC1123                       INTRODUCTION                  October 1989
+
+
+         5.3.6  Mailing Lists and Aliases .........................   65
+         5.3.7  Mail Gatewaying ...................................   66
+         5.3.8  Maximum Message Size ..............................   68
+      5.4  SMTP REQUIREMENTS SUMMARY ..............................   69
+
+   6. SUPPORT SERVICES ............................................   72
+      6.1 DOMAIN NAME TRANSLATION .................................   72
+         6.1.1 INTRODUCTION .......................................   72
+         6.1.2  PROTOCOL WALK-THROUGH .............................   72
+            6.1.2.1  Resource Records with Zero TTL ...............   73
+            6.1.2.2  QCLASS Values ................................   73
+            6.1.2.3  Unused Fields ................................   73
+            6.1.2.4  Compression ..................................   73
+            6.1.2.5  Misusing Configuration Info ..................   73
+         6.1.3  SPECIFIC ISSUES ...................................   74
+            6.1.3.1  Resolver Implementation ......................   74
+            6.1.3.2  Transport Protocols ..........................   75
+            6.1.3.3  Efficient Resource Usage .....................   77
+            6.1.3.4  Multihomed Hosts .............................   78
+            6.1.3.5  Extensibility ................................   79
+            6.1.3.6  Status of RR Types ...........................   79
+            6.1.3.7  Robustness ...................................   80
+            6.1.3.8  Local Host Table .............................   80
+         6.1.4  DNS USER INTERFACE ................................   81
+            6.1.4.1  DNS Administration ...........................   81
+            6.1.4.2  DNS User Interface ...........................   81
+            6.1.4.3 Interface Abbreviation Facilities .............   82
+         6.1.5  DOMAIN NAME SYSTEM REQUIREMENTS SUMMARY ...........   84
+      6.2  HOST INITIALIZATION ....................................   87
+         6.2.1  INTRODUCTION ......................................   87
+         6.2.2  REQUIREMENTS ......................................   87
+            6.2.2.1  Dynamic Configuration ........................   87
+            6.2.2.2  Loading Phase ................................   89
+      6.3  REMOTE MANAGEMENT ......................................   90
+         6.3.1  INTRODUCTION ......................................   90
+         6.3.2  PROTOCOL WALK-THROUGH .............................   90
+         6.3.3  MANAGEMENT REQUIREMENTS SUMMARY ...................   92
+
+   7.  REFERENCES .................................................   93
+
+
+
+
+
+
+
+
+
+
+
+
+Internet Engineering Task Force                                 [Page 4]
+
+
+
+
+RFC1123                       INTRODUCTION                  October 1989
+
+
+1.  INTRODUCTION
+
+   This document is one of a pair that defines and discusses the
+   requirements for host system implementations of the Internet protocol
+   suite.  This RFC covers the applications layer and support protocols.
+   Its companion RFC, "Requirements for Internet Hosts -- Communications
+   Layers" [INTRO:1] covers the lower layer protocols: transport layer,
+   IP layer, and link layer.
+
+   These documents are intended to provide guidance for vendors,
+   implementors, and users of Internet communication software.  They
+   represent the consensus of a large body of technical experience and
+   wisdom, contributed by members of the Internet research and vendor
+   communities.
+
+   This RFC enumerates standard protocols that a host connected to the
+   Internet must use, and it incorporates by reference the RFCs and
+   other documents describing the current specifications for these
+   protocols.  It corrects errors in the referenced documents and adds
+   additional discussion and guidance for an implementor.
+
+   For each protocol, this document also contains an explicit set of
+   requirements, recommendations, and options.  The reader must
+   understand that the list of requirements in this document is
+   incomplete by itself; the complete set of requirements for an
+   Internet host is primarily defined in the standard protocol
+   specification documents, with the corrections, amendments, and
+   supplements contained in this RFC.
+
+   A good-faith implementation of the protocols that was produced after
+   careful reading of the RFC's and with some interaction with the
+   Internet technical community, and that followed good communications
+   software engineering practices, should differ from the requirements
+   of this document in only minor ways.  Thus, in many cases, the
+   "requirements" in this RFC are already stated or implied in the
+   standard protocol documents, so that their inclusion here is, in a
+   sense, redundant.  However, they were included because some past
+   implementation has made the wrong choice, causing problems of
+   interoperability, performance, and/or robustness.
+
+   This document includes discussion and explanation of many of the
+   requirements and recommendations.  A simple list of requirements
+   would be dangerous, because:
+
+   o    Some required features are more important than others, and some
+        features are optional.
+
+   o    There may be valid reasons why particular vendor products that
+
+
+
+Internet Engineering Task Force                                 [Page 5]
+
+
+
+
+RFC1123                       INTRODUCTION                  October 1989
+
+
+        are designed for restricted contexts might choose to use
+        different specifications.
+
+   However, the specifications of this document must be followed to meet
+   the general goal of arbitrary host interoperation across the
+   diversity and complexity of the Internet system.  Although most
+   current implementations fail to meet these requirements in various
+   ways, some minor and some major, this specification is the ideal
+   towards which we need to move.
+
+   These requirements are based on the current level of Internet
+   architecture.  This document will be updated as required to provide
+   additional clarifications or to include additional information in
+   those areas in which specifications are still evolving.
+
+   This introductory section begins with general advice to host software
+   vendors, and then gives some guidance on reading the rest of the
+   document.  Section 2 contains general requirements that may be
+   applicable to all application and support protocols.  Sections 3, 4,
+   and 5 contain the requirements on protocols for the three major
+   applications: Telnet, file transfer, and electronic mail,
+   respectively. Section 6 covers the support applications: the domain
+   name system, system initialization, and management.  Finally, all
+   references will be found in Section 7.
+
+   1.1  The Internet Architecture
+
+      For a brief introduction to the Internet architecture from a host
+      viewpoint, see Section 1.1 of [INTRO:1].  That section also
+      contains recommended references for general background on the
+      Internet architecture.
+
+   1.2  General Considerations
+
+      There are two important lessons that vendors of Internet host
+      software have learned and which a new vendor should consider
+      seriously.
+
+      1.2.1  Continuing Internet Evolution
+
+         The enormous growth of the Internet has revealed problems of
+         management and scaling in a large datagram-based packet
+         communication system.  These problems are being addressed, and
+         as a result there will be continuing evolution of the
+         specifications described in this document.  These changes will
+         be carefully planned and controlled, since there is extensive
+         participation in this planning by the vendors and by the
+         organizations responsible for operations of the networks.
+
+
+
+Internet Engineering Task Force                                 [Page 6]
+
+
+
+
+RFC1123                       INTRODUCTION                  October 1989
+
+
+         Development, evolution, and revision are characteristic of
+         computer network protocols today, and this situation will
+         persist for some years.  A vendor who develops computer
+         communication software for the Internet protocol suite (or any
+         other protocol suite!) and then fails to maintain and update
+         that software for changing specifications is going to leave a
+         trail of unhappy customers.  The Internet is a large
+         communication network, and the users are in constant contact
+         through it.  Experience has shown that knowledge of
+         deficiencies in vendor software propagates quickly through the
+         Internet technical community.
+
+      1.2.2  Robustness Principle
+
+         At every layer of the protocols, there is a general rule whose
+         application can lead to enormous benefits in robustness and
+         interoperability:
+
+                "Be liberal in what you accept, and
+                 conservative in what you send"
+
+         Software should be written to deal with every conceivable
+         error, no matter how unlikely; sooner or later a packet will
+         come in with that particular combination of errors and
+         attributes, and unless the software is prepared, chaos can
+         ensue.  In general, it is best to assume that the network is
+         filled with malevolent entities that will send in packets
+         designed to have the worst possible effect.  This assumption
+         will lead to suitable protective design, although the most
+         serious problems in the Internet have been caused by
+         unenvisaged mechanisms triggered by low-probability events;
+         mere human malice would never have taken so devious a course!
+
+         Adaptability to change must be designed into all levels of
+         Internet host software.  As a simple example, consider a
+         protocol specification that contains an enumeration of values
+         for a particular header field -- e.g., a type field, a port
+         number, or an error code; this enumeration must be assumed to
+         be incomplete.  Thus, if a protocol specification defines four
+         possible error codes, the software must not break when a fifth
+         code shows up.  An undefined code might be logged (see below),
+         but it must not cause a failure.
+
+         The second part of the principle is almost as important:
+         software on other hosts may contain deficiencies that make it
+         unwise to exploit legal but obscure protocol features.  It is
+         unwise to stray far from the obvious and simple, lest untoward
+         effects result elsewhere.  A corollary of this is "watch out
+
+
+
+Internet Engineering Task Force                                 [Page 7]
+
+
+
+
+RFC1123                       INTRODUCTION                  October 1989
+
+
+         for misbehaving hosts"; host software should be prepared, not
+         just to survive other misbehaving hosts, but also to cooperate
+         to limit the amount of disruption such hosts can cause to the
+         shared communication facility.
+
+      1.2.3  Error Logging
+
+         The Internet includes a great variety of host and gateway
+         systems, each implementing many protocols and protocol layers,
+         and some of these contain bugs and mis-features in their
+         Internet protocol software.  As a result of complexity,
+         diversity, and distribution of function, the diagnosis of user
+         problems is often very difficult.
+
+         Problem diagnosis will be aided if host implementations include
+         a carefully designed facility for logging erroneous or
+         "strange" protocol events.  It is important to include as much
+         diagnostic information as possible when an error is logged.  In
+         particular, it is often useful to record the header(s) of a
+         packet that caused an error.  However, care must be taken to
+         ensure that error logging does not consume prohibitive amounts
+         of resources or otherwise interfere with the operation of the
+         host.
+
+         There is a tendency for abnormal but harmless protocol events
+         to overflow error logging files; this can be avoided by using a
+         "circular" log, or by enabling logging only while diagnosing a
+         known failure.  It may be useful to filter and count duplicate
+         successive messages.  One strategy that seems to work well is:
+         (1) always count abnormalities and make such counts accessible
+         through the management protocol (see Section 6.3); and (2)
+         allow the logging of a great variety of events to be
+         selectively enabled.  For example, it might useful to be able
+         to "log everything" or to "log everything for host X".
+
+         Note that different managements may have differing policies
+         about the amount of error logging that they want normally
+         enabled in a host.  Some will say, "if it doesn't hurt me, I
+         don't want to know about it", while others will want to take a
+         more watchful and aggressive attitude about detecting and
+         removing protocol abnormalities.
+
+      1.2.4  Configuration
+
+         It would be ideal if a host implementation of the Internet
+         protocol suite could be entirely self-configuring.  This would
+         allow the whole suite to be implemented in ROM or cast into
+         silicon, it would simplify diskless workstations, and it would
+
+
+
+Internet Engineering Task Force                                 [Page 8]
+
+
+
+
+RFC1123                       INTRODUCTION                  October 1989
+
+
+         be an immense boon to harried LAN administrators as well as
+         system vendors.  We have not reached this ideal; in fact, we
+         are not even close.
+
+         At many points in this document, you will find a requirement
+         that a parameter be a configurable option.  There are several
+         different reasons behind such requirements.  In a few cases,
+         there is current uncertainty or disagreement about the best
+         value, and it may be necessary to update the recommended value
+         in the future.  In other cases, the value really depends on
+         external factors -- e.g., the size of the host and the
+         distribution of its communication load, or the speeds and
+         topology of nearby networks -- and self-tuning algorithms are
+         unavailable and may be insufficient.  In some cases,
+         configurability is needed because of administrative
+         requirements.
+
+         Finally, some configuration options are required to communicate
+         with obsolete or incorrect implementations of the protocols,
+         distributed without sources, that unfortunately persist in many
+         parts of the Internet.  To make correct systems coexist with
+         these faulty systems, administrators often have to "mis-
+         configure" the correct systems.  This problem will correct
+         itself gradually as the faulty systems are retired, but it
+         cannot be ignored by vendors.
+
+         When we say that a parameter must be configurable, we do not
+         intend to require that its value be explicitly read from a
+         configuration file at every boot time.  We recommend that
+         implementors set up a default for each parameter, so a
+         configuration file is only necessary to override those defaults
+         that are inappropriate in a particular installation.  Thus, the
+         configurability requirement is an assurance that it will be
+         POSSIBLE to override the default when necessary, even in a
+         binary-only or ROM-based product.
+
+         This document requires a particular value for such defaults in
+         some cases.  The choice of default is a sensitive issue when
+         the configuration item controls the accommodation to existing
+         faulty systems.  If the Internet is to converge successfully to
+         complete interoperability, the default values built into
+         implementations must implement the official protocol, not
+         "mis-configurations" to accommodate faulty implementations.
+         Although marketing considerations have led some vendors to
+         choose mis-configuration defaults, we urge vendors to choose
+         defaults that will conform to the standard.
+
+         Finally, we note that a vendor needs to provide adequate
+
+
+
+Internet Engineering Task Force                                 [Page 9]
+
+
+
+
+RFC1123                       INTRODUCTION                  October 1989
+
+
+         documentation on all configuration parameters, their limits and
+         effects.
+
+
+   1.3  Reading this Document
+
+      1.3.1  Organization
+
+         In general, each major section is organized into the following
+         subsections:
+
+         (1)  Introduction
+
+         (2)  Protocol Walk-Through -- considers the protocol
+              specification documents section-by-section, correcting
+              errors, stating requirements that may be ambiguous or
+              ill-defined, and providing further clarification or
+              explanation.
+
+         (3)  Specific Issues -- discusses protocol design and
+              implementation issues that were not included in the walk-
+              through.
+
+         (4)  Interfaces -- discusses the service interface to the next
+              higher layer.
+
+         (5)  Summary -- contains a summary of the requirements of the
+              section.
+
+         Under many of the individual topics in this document, there is
+         parenthetical material labeled "DISCUSSION" or
+         "IMPLEMENTATION".  This material is intended to give
+         clarification and explanation of the preceding requirements
+         text.  It also includes some suggestions on possible future
+         directions or developments.  The implementation material
+         contains suggested approaches that an implementor may want to
+         consider.
+
+         The summary sections are intended to be guides and indexes to
+         the text, but are necessarily cryptic and incomplete.  The
+         summaries should never be used or referenced separately from
+         the complete RFC.
+
+      1.3.2  Requirements
+
+         In this document, the words that are used to define the
+         significance of each particular requirement are capitalized.
+         These words are:
+
+
+
+Internet Engineering Task Force                                [Page 10]
+
+
+
+
+RFC1123                       INTRODUCTION                  October 1989
+
+
+         *    "MUST"
+
+              This word or the adjective "REQUIRED" means that the item
+              is an absolute requirement of the specification.
+
+         *    "SHOULD"
+
+              This word or the adjective "RECOMMENDED" means that there
+              may exist valid reasons in particular circumstances to
+              ignore this item, but the full implications should be
+              understood and the case carefully weighed before choosing
+              a different course.
+
+         *    "MAY"
+
+              This word or the adjective "OPTIONAL" means that this item
+              is truly optional.  One vendor may choose to include the
+              item because a particular marketplace requires it or
+              because it enhances the product, for example; another
+              vendor may omit the same item.
+
+
+         An implementation is not compliant if it fails to satisfy one
+         or more of the MUST requirements for the protocols it
+         implements.  An implementation that satisfies all the MUST and
+         all the SHOULD requirements for its protocols is said to be
+         "unconditionally compliant"; one that satisfies all the MUST
+         requirements but not all the SHOULD requirements for its
+         protocols is said to be "conditionally compliant".
+
+      1.3.3  Terminology
+
+         This document uses the following technical terms:
+
+         Segment
+              A segment is the unit of end-to-end transmission in the
+              TCP protocol.  A segment consists of a TCP header followed
+              by application data.  A segment is transmitted by
+              encapsulation in an IP datagram.
+
+         Message
+              This term is used by some application layer protocols
+              (particularly SMTP) for an application data unit.
+
+         Datagram
+              A [UDP] datagram is the unit of end-to-end transmission in
+              the UDP protocol.
+
+
+
+
+Internet Engineering Task Force                                [Page 11]
+
+
+
+
+RFC1123                       INTRODUCTION                  October 1989
+
+
+         Multihomed
+              A host is said to be multihomed if it has multiple IP
+              addresses to connected networks.
+
+
+
+   1.4  Acknowledgments
+
+      This document incorporates contributions and comments from a large
+      group of Internet protocol experts, including representatives of
+      university and research labs, vendors, and government agencies.
+      It was assembled primarily by the Host Requirements Working Group
+      of the Internet Engineering Task Force (IETF).
+
+      The Editor would especially like to acknowledge the tireless
+      dedication of the following people, who attended many long
+      meetings and generated 3 million bytes of electronic mail over the
+      past 18 months in pursuit of this document: Philip Almquist, Dave
+      Borman (Cray Research), Noel Chiappa, Dave Crocker (DEC), Steve
+      Deering (Stanford), Mike Karels (Berkeley), Phil Karn (Bellcore),
+      John Lekashman (NASA), Charles Lynn (BBN), Keith McCloghrie (TWG),
+      Paul Mockapetris (ISI), Thomas Narten (Purdue), Craig Partridge
+      (BBN), Drew Perkins (CMU), and James Van Bokkelen (FTP Software).
+
+      In addition, the following people made major contributions to the
+      effort: Bill Barns (Mitre), Steve Bellovin (AT&T), Mike Brescia
+      (BBN), Ed Cain (DCA), Annette DeSchon (ISI), Martin Gross (DCA),
+      Phill Gross (NRI), Charles Hedrick (Rutgers), Van Jacobson (LBL),
+      John Klensin (MIT), Mark Lottor (SRI), Milo Medin (NASA), Bill
+      Melohn (Sun Microsystems), Greg Minshall (Kinetics), Jeff Mogul
+      (DEC), John Mullen (CMC), Jon Postel (ISI), John Romkey (Epilogue
+      Technology), and Mike StJohns (DCA).  The following also made
+      significant contributions to particular areas: Eric Allman
+      (Berkeley), Rob Austein (MIT), Art Berggreen (ACC), Keith Bostic
+      (Berkeley), Vint Cerf (NRI), Wayne Hathaway (NASA), Matt Korn
+      (IBM), Erik Naggum (Naggum Software, Norway), Robert Ullmann
+      (Prime Computer), David Waitzman (BBN), Frank Wancho (USA), Arun
+      Welch (Ohio State), Bill Westfield (Cisco), and Rayan Zachariassen
+      (Toronto).
+
+      We are grateful to all, including any contributors who may have
+      been inadvertently omitted from this list.
+
+
+
+
+
+
+
+
+
+Internet Engineering Task Force                                [Page 12]
+
+
+
+
+RFC1123              APPLICATIONS LAYER -- GENERAL          October 1989
+
+
+2.  GENERAL ISSUES
+
+   This section contains general requirements that may be applicable to
+   all application-layer protocols.
+
+   2.1  Host Names and Numbers
+
+      The syntax of a legal Internet host name was specified in RFC-952
+      [DNS:4].  One aspect of host name syntax is hereby changed: the
+      restriction on the first character is relaxed to allow either a
+      letter or a digit.  Host software MUST support this more liberal
+      syntax.
+
+      Host software MUST handle host names of up to 63 characters and
+      SHOULD handle host names of up to 255 characters.
+
+      Whenever a user inputs the identity of an Internet host, it SHOULD
+      be possible to enter either (1) a host domain name or (2) an IP
+      address in dotted-decimal ("#.#.#.#") form.  The host SHOULD check
+      the string syntactically for a dotted-decimal number before
+      looking it up in the Domain Name System.
+
+      DISCUSSION:
+           This last requirement is not intended to specify the complete
+           syntactic form for entering a dotted-decimal host number;
+           that is considered to be a user-interface issue.  For
+           example, a dotted-decimal number must be enclosed within
+           "[ ]" brackets for SMTP mail (see Section 5.2.17).  This
+           notation could be made universal within a host system,
+           simplifying the syntactic checking for a dotted-decimal
+           number.
+
+           If a dotted-decimal number can be entered without such
+           identifying delimiters, then a full syntactic check must be
+           made, because a segment of a host domain name is now allowed
+           to begin with a digit and could legally be entirely numeric
+           (see Section 6.1.2.4).  However, a valid host name can never
+           have the dotted-decimal form #.#.#.#, since at least the
+           highest-level component label will be alphabetic.
+
+   2.2  Using Domain Name Service
+
+      Host domain names MUST be translated to IP addresses as described
+      in Section 6.1.
+
+      Applications using domain name services MUST be able to cope with
+      soft error conditions.  Applications MUST wait a reasonable
+      interval between successive retries due to a soft error, and MUST
+
+
+
+Internet Engineering Task Force                                [Page 13]
+
+
+
+
+RFC1123              APPLICATIONS LAYER -- GENERAL          October 1989
+
+
+      allow for the possibility that network problems may deny service
+      for hours or even days.
+
+      An application SHOULD NOT rely on the ability to locate a WKS
+      record containing an accurate listing of all services at a
+      particular host address, since the WKS RR type is not often used
+      by Internet sites.  To confirm that a service is present, simply
+      attempt to use it.
+
+   2.3  Applications on Multihomed hosts
+
+      When the remote host is multihomed, the name-to-address
+      translation will return a list of alternative IP addresses.  As
+      specified in Section 6.1.3.4, this list should be in order of
+      decreasing preference.  Application protocol implementations
+      SHOULD be prepared to try multiple addresses from the list until
+      success is obtained.  More specific requirements for SMTP are
+      given in Section 5.3.4.
+
+      When the local host is multihomed, a UDP-based request/response
+      application SHOULD send the response with an IP source address
+      that is the same as the specific destination address of the UDP
+      request datagram.  The "specific destination address" is defined
+      in the "IP Addressing" section of the companion RFC [INTRO:1].
+
+      Similarly, a server application that opens multiple TCP
+      connections to the same client SHOULD use the same local IP
+      address for all.
+
+   2.4  Type-of-Service
+
+      Applications MUST select appropriate TOS values when they invoke
+      transport layer services, and these values MUST be configurable.
+      Note that a TOS value contains 5 bits, of which only the most-
+      significant 3 bits are currently defined; the other two bits MUST
+      be zero.
+
+      DISCUSSION:
+           As gateway algorithms are developed to implement Type-of-
+           Service, the recommended values for various application
+           protocols may change.  In addition, it is likely that
+           particular combinations of users and Internet paths will want
+           non-standard TOS values.  For these reasons, the TOS values
+           must be configurable.
+
+           See the latest version of the "Assigned Numbers" RFC
+           [INTRO:5] for the recommended TOS values for the major
+           application protocols.
+
+
+
+Internet Engineering Task Force                                [Page 14]
+
+
+
+
+RFC1123              APPLICATIONS LAYER -- GENERAL          October 1989
+
+
+   2.5  GENERAL APPLICATION REQUIREMENTS SUMMARY
+
+                                               |          | | | |S| |
+                                               |          | | | |H| |F
+                                               |          | | | |O|M|o
+                                               |          | |S| |U|U|o
+                                               |          | |H| |L|S|t
+                                               |          |M|O| |D|T|n
+                                               |          |U|U|M| | |o
+                                               |          |S|L|A|N|N|t
+                                               |          |T|D|Y|O|O|t
+FEATURE                                        |SECTION   | | | |T|T|e
+-----------------------------------------------|----------|-|-|-|-|-|--
+                                               |          | | | | | |
+User interfaces:                               |          | | | | | |
+  Allow host name to begin with digit          |2.1       |x| | | | |
+  Host names of up to 635 characters           |2.1       |x| | | | |
+  Host names of up to 255 characters           |2.1       | |x| | | |
+  Support dotted-decimal host numbers          |2.1       | |x| | | |
+  Check syntactically for dotted-dec first     |2.1       | |x| | | |
+                                               |          | | | | | |
+Map domain names per Section 6.1               |2.2       |x| | | | |
+Cope with soft DNS errors                      |2.2       |x| | | | |
+   Reasonable interval between retries         |2.2       |x| | | | |
+   Allow for long outages                      |2.2       |x| | | | |
+Expect WKS records to be available             |2.2       | | | |x| |
+                                               |          | | | | | |
+Try multiple addr's for remote multihomed host |2.3       | |x| | | |
+UDP reply src addr is specific dest of request |2.3       | |x| | | |
+Use same IP addr for related TCP connections   |2.3       | |x| | | |
+Specify appropriate TOS values                 |2.4       |x| | | | |
+  TOS values configurable                      |2.4       |x| | | | |
+  Unused TOS bits zero                         |2.4       |x| | | | |
+                                               |          | | | | | |
+                                               |          | | | | | |
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Internet Engineering Task Force                                [Page 15]
+
+
+
+
+RFC1123                  REMOTE LOGIN -- TELNET             October 1989
+
+
+3.  REMOTE LOGIN -- TELNET PROTOCOL
+
+   3.1  INTRODUCTION
+
+      Telnet is the standard Internet application protocol for remote
+      login.  It provides the encoding rules to link a user's
+      keyboard/display on a client ("user") system with a command
+      interpreter on a remote server system.  A subset of the Telnet
+      protocol is also incorporated within other application protocols,
+      e.g., FTP and SMTP.
+
+      Telnet uses a single TCP connection, and its normal data stream
+      ("Network Virtual Terminal" or "NVT" mode) is 7-bit ASCII with
+      escape sequences to embed control functions.  Telnet also allows
+      the negotiation of many optional modes and functions.
+
+      The primary Telnet specification is to be found in RFC-854
+      [TELNET:1], while the options are defined in many other RFCs; see
+      Section 7 for references.
+
+   3.2  PROTOCOL WALK-THROUGH
+
+      3.2.1  Option Negotiation: RFC-854, pp. 2-3
+
+         Every Telnet implementation MUST include option negotiation and
+         subnegotiation machinery [TELNET:2].
+
+         A host MUST carefully follow the rules of RFC-854 to avoid
+         option-negotiation loops.  A host MUST refuse (i.e, reply
+         WONT/DONT to a DO/WILL) an unsupported option.  Option
+         negotiation SHOULD continue to function (even if all requests
+         are refused) throughout the lifetime of a Telnet connection.
+
+         If all option negotiations fail, a Telnet implementation MUST
+         default to, and support, an NVT.
+
+         DISCUSSION:
+              Even though more sophisticated "terminals" and supporting
+              option negotiations are becoming the norm, all
+              implementations must be prepared to support an NVT for any
+              user-server communication.
+
+      3.2.2  Telnet Go-Ahead Function: RFC-854, p. 5, and RFC-858
+
+         On a host that never sends the Telnet command Go Ahead (GA),
+         the Telnet Server MUST attempt to negotiate the Suppress Go
+         Ahead option (i.e., send "WILL Suppress Go Ahead").  A User or
+         Server Telnet MUST always accept negotiation of the Suppress Go
+
+
+
+Internet Engineering Task Force                                [Page 16]
+
+
+
+
+RFC1123                  REMOTE LOGIN -- TELNET             October 1989
+
+
+         Ahead option.
+
+         When it is driving a full-duplex terminal for which GA has no
+         meaning, a User Telnet implementation MAY ignore GA commands.
+
+         DISCUSSION:
+              Half-duplex ("locked-keyboard") line-at-a-time terminals
+              for which the Go-Ahead mechanism was designed have largely
+              disappeared from the scene.  It turned out to be difficult
+              to implement sending the Go-Ahead signal in many operating
+              systems, even some systems that support native half-duplex
+              terminals.  The difficulty is typically that the Telnet
+              server code does not have access to information about
+              whether the user process is blocked awaiting input from
+              the Telnet connection, i.e., it cannot reliably determine
+              when to send a GA command.  Therefore, most Telnet Server
+              hosts do not send GA commands.
+
+              The effect of the rules in this section is to allow either
+              end of a Telnet connection to veto the use of GA commands.
+
+              There is a class of half-duplex terminals that is still
+              commercially important: "data entry terminals," which
+              interact in a full-screen manner.  However, supporting
+              data entry terminals using the Telnet protocol does not
+              require the Go Ahead signal; see Section 3.3.2.
+
+      3.2.3  Control Functions: RFC-854, pp. 7-8
+
+         The list of Telnet commands has been extended to include EOR
+         (End-of-Record), with code 239 [TELNET:9].
+
+         Both User and Server Telnets MAY support the control functions
+         EOR, EC, EL, and Break, and MUST support AO, AYT, DM, IP, NOP,
+         SB, and SE.
+
+         A host MUST be able to receive and ignore any Telnet control
+         functions that it does not support.
+
+         DISCUSSION:
+              Note that a Server Telnet is required to support the
+              Telnet IP (Interrupt Process) function, even if the server
+              host has an equivalent in-stream function (e.g., Control-C
+              in many systems).  The Telnet IP function may be stronger
+              than an in-stream interrupt command, because of the out-
+              of-band effect of TCP urgent data.
+
+              The EOR control function may be used to delimit the
+
+
+
+Internet Engineering Task Force                                [Page 17]
+
+
+
+
+RFC1123                  REMOTE LOGIN -- TELNET             October 1989
+
+
+              stream.  An important application is data entry terminal
+              support (see Section 3.3.2).  There was concern that since
+              EOR had not been defined in RFC-854, a host that was not
+              prepared to correctly ignore unknown Telnet commands might
+              crash if it received an EOR.  To protect such hosts, the
+              End-of-Record option [TELNET:9] was introduced; however, a
+              properly implemented Telnet program will not require this
+              protection.
+
+      3.2.4  Telnet "Synch" Signal: RFC-854, pp. 8-10
+
+         When it receives "urgent" TCP data, a User or Server Telnet
+         MUST discard all data except Telnet commands until the DM (and
+         end of urgent) is reached.
+
+         When it sends Telnet IP (Interrupt Process), a User Telnet
+         SHOULD follow it by the Telnet "Synch" sequence, i.e., send as
+         TCP urgent data the sequence "IAC IP IAC DM".  The TCP urgent
+         pointer points to the DM octet.
+
+         When it receives a Telnet IP command, a Server Telnet MAY send
+         a Telnet "Synch" sequence back to the user, to flush the output
+         stream.  The choice ought to be consistent with the way the
+         server operating system behaves when a local user interrupts a
+         process.
+
+         When it receives a Telnet AO command, a Server Telnet MUST send
+         a Telnet "Synch" sequence back to the user, to flush the output
+         stream.
+
+         A User Telnet SHOULD have the capability of flushing output
+         when it sends a Telnet IP; see also Section 3.4.5.
+
+         DISCUSSION:
+              There are three possible ways for a User Telnet to flush
+              the stream of server output data:
+
+              (1)  Send AO after IP.
+
+                   This will cause the server host to send a "flush-
+                   buffered-output" signal to its operating system.
+                   However, the AO may not take effect locally, i.e.,
+                   stop terminal output at the User Telnet end, until
+                   the Server Telnet has received and processed the AO
+                   and has sent back a "Synch".
+
+              (2)  Send DO TIMING-MARK [TELNET:7] after IP, and discard
+                   all output locally until a WILL/WONT TIMING-MARK is
+
+
+
+Internet Engineering Task Force                                [Page 18]
+
+
+
+
+RFC1123                  REMOTE LOGIN -- TELNET             October 1989
+
+
+                   received from the Server Telnet.
+
+                   Since the DO TIMING-MARK will be processed after the
+                   IP at the server, the reply to it should be in the
+                   right place in the output data stream.  However, the
+                   TIMING-MARK will not send a "flush buffered output"
+                   signal to the server operating system.  Whether or
+                   not this is needed is dependent upon the server
+                   system.
+
+              (3)  Do both.
+
+              The best method is not entirely clear, since it must
+              accommodate a number of existing server hosts that do not
+              follow the Telnet standards in various ways.  The safest
+              approach is probably to provide a user-controllable option
+              to select (1), (2), or (3).
+
+      3.2.5  NVT Printer and Keyboard: RFC-854, p. 11
+
+         In NVT mode, a Telnet SHOULD NOT send characters with the
+         high-order bit 1, and MUST NOT send it as a parity bit.
+         Implementations that pass the high-order bit to applications
+         SHOULD negotiate binary mode (see Section 3.2.6).
+
+
+         DISCUSSION:
+              Implementors should be aware that a strict reading of
+              RFC-854 allows a client or server expecting NVT ASCII to
+              ignore characters with the high-order bit set.  In
+              general, binary mode is expected to be used for
+              transmission of an extended (beyond 7-bit) character set
+              with Telnet.
+
+              However, there exist applications that really need an 8-
+              bit NVT mode, which is currently not defined, and these
+              existing applications do set the high-order bit during
+              part or all of the life of a Telnet connection.  Note that
+              binary mode is not the same as 8-bit NVT mode, since
+              binary mode turns off end-of-line processing.  For this
+              reason, the requirements on the high-order bit are stated
+              as SHOULD, not MUST.
+
+              RFC-854 defines a minimal set of properties of a "network
+              virtual terminal" or NVT; this is not meant to preclude
+              additional features in a real terminal.  A Telnet
+              connection is fully transparent to all 7-bit ASCII
+              characters, including arbitrary ASCII control characters.
+
+
+
+Internet Engineering Task Force                                [Page 19]
+
+
+
+
+RFC1123                  REMOTE LOGIN -- TELNET             October 1989
+
+
+              For example, a terminal might support full-screen commands
+              coded as ASCII escape sequences; a Telnet implementation
+              would pass these sequences as uninterpreted data.  Thus,
+              an NVT should not be conceived as a terminal type of a
+              highly-restricted device.
+
+      3.2.6  Telnet Command Structure: RFC-854, p. 13
+
+         Since options may appear at any point in the data stream, a
+         Telnet escape character (known as IAC, with the value 255) to
+         be sent as data MUST be doubled.
+
+      3.2.7  Telnet Binary Option: RFC-856
+
+         When the Binary option has been successfully negotiated,
+         arbitrary 8-bit characters are allowed.  However, the data
+         stream MUST still be scanned for IAC characters, any embedded
+         Telnet commands MUST be obeyed, and data bytes equal to IAC
+         MUST be doubled.  Other character processing (e.g., replacing
+         CR by CR NUL or by CR LF) MUST NOT be done.  In particular,
+         there is no end-of-line convention (see Section 3.3.1) in
+         binary mode.
+
+         DISCUSSION:
+              The Binary option is normally negotiated in both
+              directions, to change the Telnet connection from NVT mode
+              to "binary mode".
+
+              The sequence IAC EOR can be used to delimit blocks of data
+              within a binary-mode Telnet stream.
+
+      3.2.8  Telnet Terminal-Type Option: RFC-1091
+
+         The Terminal-Type option MUST use the terminal type names
+         officially defined in the Assigned Numbers RFC [INTRO:5], when
+         they are available for the particular terminal.  However, the
+         receiver of a Terminal-Type option MUST accept any name.
+
+         DISCUSSION:
+              RFC-1091 [TELNET:10] updates an earlier version of the
+              Terminal-Type option defined in RFC-930.  The earlier
+              version allowed a server host capable of supporting
+              multiple terminal types to learn the type of a particular
+              client's terminal, assuming that each physical terminal
+              had an intrinsic type.  However, today a "terminal" is
+              often really a terminal emulator program running in a PC,
+              perhaps capable of emulating a range of terminal types.
+              Therefore, RFC-1091 extends the specification to allow a
+
+
+
+Internet Engineering Task Force                                [Page 20]
+
+
+
+
+RFC1123                  REMOTE LOGIN -- TELNET             October 1989
+
+
+              more general terminal-type negotiation between User and
+              Server Telnets.
+
+   3.3  SPECIFIC ISSUES
+
+      3.3.1  Telnet End-of-Line Convention
+
+         The Telnet protocol defines the sequence CR LF to mean "end-
+         of-line".  For terminal input, this corresponds to a command-
+         completion or "end-of-line" key being pressed on a user
+         terminal; on an ASCII terminal, this is the CR key, but it may
+         also be labelled "Return" or "Enter".
+
+         When a Server Telnet receives the Telnet end-of-line sequence
+         CR LF as input from a remote terminal, the effect MUST be the
+         same as if the user had pressed the "end-of-line" key on a
+         local terminal.  On server hosts that use ASCII, in particular,
+         receipt of the Telnet sequence CR LF must cause the same effect
+         as a local user pressing the CR key on a local terminal.  Thus,
+         CR LF and CR NUL MUST have the same effect on an ASCII server
+         host when received as input over a Telnet connection.
+
+         A User Telnet MUST be able to send any of the forms: CR LF, CR
+         NUL, and LF.  A User Telnet on an ASCII host SHOULD have a
+         user-controllable mode to send either CR LF or CR NUL when the
+         user presses the "end-of-line" key, and CR LF SHOULD be the
+         default.
+
+         The Telnet end-of-line sequence CR LF MUST be used to send
+         Telnet data that is not terminal-to-computer (e.g., for Server
+         Telnet sending output, or the Telnet protocol incorporated
+         another application protocol).
+
+         DISCUSSION:
+              To allow interoperability between arbitrary Telnet clients
+              and servers, the Telnet protocol defined a standard
+              representation for a line terminator.  Since the ASCII
+              character set includes no explicit end-of-line character,
+              systems have chosen various representations, e.g., CR, LF,
+              and the sequence CR LF.  The Telnet protocol chose the CR
+              LF sequence as the standard for network transmission.
+
+              Unfortunately, the Telnet protocol specification in RFC-
+              854 [TELNET:1] has turned out to be somewhat ambiguous on
+              what character(s) should be sent from client to server for
+              the "end-of-line" key.  The result has been a massive and
+              continuing interoperability headache, made worse by
+              various faulty implementations of both User and Server
+
+
+
+Internet Engineering Task Force                                [Page 21]
+
+
+
+
+RFC1123                  REMOTE LOGIN -- TELNET             October 1989
+
+
+              Telnets.
+
+              Although the Telnet protocol is based on a perfectly
+              symmetric model, in a remote login session the role of the
+              user at a terminal differs from the role of the server
+              host.  For example, RFC-854 defines the meaning of CR, LF,
+              and CR LF as output from the server, but does not specify
+              what the User Telnet should send when the user presses the
+              "end-of-line" key on the terminal; this turns out to be
+              the point at issue.
+
+              When a user presses the "end-of-line" key, some User
+              Telnet implementations send CR LF, while others send CR
+              NUL (based on a different interpretation of the same
+              sentence in RFC-854).  These will be equivalent for a
+              correctly-implemented ASCII server host, as discussed
+              above.  For other servers, a mode in the User Telnet is
+              needed.
+
+              The existence of User Telnets that send only CR NUL when
+              CR is pressed creates a dilemma for non-ASCII hosts: they
+              can either treat CR NUL as equivalent to CR LF in input,
+              thus precluding the possibility of entering a "bare" CR,
+              or else lose complete interworking.
+
+              Suppose a user on host A uses Telnet to log into a server
+              host B, and then execute B's User Telnet program to log
+              into server host C.  It is desirable for the Server/User
+              Telnet combination on B to be as transparent as possible,
+              i.e., to appear as if A were connected directly to C.  In
+              particular, correct implementation will make B transparent
+              to Telnet end-of-line sequences, except that CR LF may be
+              translated to CR NUL or vice versa.
+
+         IMPLEMENTATION:
+              To understand Telnet end-of-line issues, one must have at
+              least a general model of the relationship of Telnet to the
+              local operating system.  The Server Telnet process is
+              typically coupled into the terminal driver software of the
+              operating system as a pseudo-terminal.  A Telnet end-of-
+              line sequence received by the Server Telnet must have the
+              same effect as pressing the end-of-line key on a real
+              locally-connected terminal.
+
+              Operating systems that support interactive character-at-
+              a-time applications (e.g., editors) typically have two
+              internal modes for their terminal I/O: a formatted mode,
+              in which local conventions for end-of-line and other
+
+
+
+Internet Engineering Task Force                                [Page 22]
+
+
+
+
+RFC1123                  REMOTE LOGIN -- TELNET             October 1989
+
+
+              formatting rules have been applied to the data stream, and
+              a "raw" mode, in which the application has direct access
+              to every character as it was entered.  A Server Telnet
+              must be implemented in such a way that these modes have
+              the same effect for remote as for local terminals.  For
+              example, suppose a CR LF or CR NUL is received by the
+              Server Telnet on an ASCII host.  In raw mode, a CR
+              character is passed to the application; in formatted mode,
+              the local system's end-of-line convention is used.
+
+      3.3.2  Data Entry Terminals
+
+         DISCUSSION:
+              In addition to the line-oriented and character-oriented
+              ASCII terminals for which Telnet was designed, there are
+              several families of video display terminals that are
+              sometimes known as "data entry terminals" or DETs.  The
+              IBM 3270 family is a well-known example.
+
+              Two Internet protocols have been designed to support
+              generic DETs: SUPDUP [TELNET:16, TELNET:17], and the DET
+              option [TELNET:18, TELNET:19].  The DET option drives a
+              data entry terminal over a Telnet connection using (sub-)
+              negotiation.  SUPDUP is a completely separate terminal
+              protocol, which can be entered from Telnet by negotiation.
+              Although both SUPDUP and the DET option have been used
+              successfully in particular environments, neither has
+              gained general acceptance or wide implementation.
+
+              A different approach to DET interaction has been developed
+              for supporting the IBM 3270 family through Telnet,
+              although the same approach would be applicable to any DET.
+              The idea is to enter a "native DET" mode, in which the
+              native DET input/output stream is sent as binary data.
+              The Telnet EOR command is used to delimit logical records
+              (e.g., "screens") within this binary stream.
+
+         IMPLEMENTATION:
+              The rules for entering and leaving native DET mode are as
+              follows:
+
+              o    The Server uses the Terminal-Type option [TELNET:10]
+                   to learn that the client is a DET.
+
+              o    It is conventional, but not required, that both ends
+                   negotiate the EOR option [TELNET:9].
+
+              o    Both ends negotiate the Binary option [TELNET:3] to
+
+
+
+Internet Engineering Task Force                                [Page 23]
+
+
+
+
+RFC1123                  REMOTE LOGIN -- TELNET             October 1989
+
+
+                   enter native DET mode.
+
+              o    When either end negotiates out of binary mode, the
+                   other end does too, and the mode then reverts to
+                   normal NVT.
+
+
+      3.3.3  Option Requirements
+
+         Every Telnet implementation MUST support the Binary option
+         [TELNET:3] and the Suppress Go Ahead option [TELNET:5], and
+         SHOULD support the Echo [TELNET:4], Status [TELNET:6], End-of-
+         Record [TELNET:9], and Extended Options List [TELNET:8]
+         options.
+
+         A User or Server Telnet SHOULD support the Window Size Option
+         [TELNET:12] if the local operating system provides the
+         corresponding capability.
+
+         DISCUSSION:
+              Note that the End-of-Record option only signifies that a
+              Telnet can receive a Telnet EOR without crashing;
+              therefore, every Telnet ought to be willing to accept
+              negotiation of the End-of-Record option.  See also the
+              discussion in Section 3.2.3.
+
+      3.3.4  Option Initiation
+
+         When the Telnet protocol is used in a client/server situation,
+         the server SHOULD initiate negotiation of the terminal
+         interaction mode it expects.
+
+         DISCUSSION:
+              The Telnet protocol was defined to be perfectly
+              symmetrical, but its application is generally asymmetric.
+              Remote login has been known to fail because NEITHER side
+              initiated negotiation of the required non-default terminal
+              modes.  It is generally the server that determines the
+              preferred mode, so the server needs to initiate the
+              negotiation; since the negotiation is symmetric, the user
+              can also initiate it.
+
+         A client (User Telnet) SHOULD provide a means for users to
+         enable and disable the initiation of option negotiation.
+
+         DISCUSSION:
+              A user sometimes needs to connect to an application
+              service (e.g., FTP or SMTP) that uses Telnet for its
+
+
+
+Internet Engineering Task Force                                [Page 24]
+
+
+
+
+RFC1123                  REMOTE LOGIN -- TELNET             October 1989
+
+
+              control stream but does not support Telnet options.  User
+              Telnet may be used for this purpose if initiation of
+              option negotiation is  disabled.
+
+      3.3.5  Telnet Linemode Option
+
+         DISCUSSION:
+              An important new Telnet option, LINEMODE [TELNET:12], has
+              been proposed.  The LINEMODE option provides a standard
+              way for a User Telnet and a Server Telnet to agree that
+              the client rather than the server will perform terminal
+              character processing.  When the client has prepared a
+              complete line of text, it will send it to the server in
+              (usually) one TCP packet.  This option will greatly
+              decrease the packet cost of Telnet sessions and will also
+              give much better user response over congested or long-
+              delay networks.
+
+              The LINEMODE option allows dynamic switching between local
+              and remote character processing.  For example, the Telnet
+              connection will automatically negotiate into single-
+              character mode while a full screen editor is running, and
+              then return to linemode when the editor is finished.
+
+              We expect that when this RFC is released, hosts should
+              implement the client side of this option, and may
+              implement the server side of this option.  To properly
+              implement the server side, the server needs to be able to
+              tell the local system not to do any input character
+              processing, but to remember its current terminal state and
+              notify the Server Telnet process whenever the state
+              changes.  This will allow password echoing and full screen
+              editors to be handled properly, for example.
+
+   3.4  TELNET/USER INTERFACE
+
+      3.4.1  Character Set Transparency
+
+         User Telnet implementations SHOULD be able to send or receive
+         any 7-bit ASCII character.  Where possible, any special
+         character interpretations by the user host's operating system
+         SHOULD be bypassed so that these characters can conveniently be
+         sent and received on the connection.
+
+         Some character value MUST be reserved as "escape to command
+         mode"; conventionally, doubling this character allows it to be
+         entered as data.  The specific character used SHOULD be user
+         selectable.
+
+
+
+Internet Engineering Task Force                                [Page 25]
+
+
+
+
+RFC1123                  REMOTE LOGIN -- TELNET             October 1989
+
+
+         On binary-mode connections, a User Telnet program MAY provide
+         an escape mechanism for entering arbitrary 8-bit values, if the
+         host operating system doesn't allow them to be entered directly
+         from the keyboard.
+
+         IMPLEMENTATION:
+              The transparency issues are less pressing on servers, but
+              implementors should take care in dealing with issues like:
+              masking off parity bits (sent by an older, non-conforming
+              client) before they reach programs that expect only NVT
+              ASCII, and properly handling programs that request 8-bit
+              data streams.
+
+      3.4.2  Telnet Commands
+
+         A User Telnet program MUST provide a user the capability of
+         entering any of the Telnet control functions IP, AO, or AYT,
+         and SHOULD provide the capability of entering EC, EL, and
+         Break.
+
+      3.4.3  TCP Connection Errors
+
+         A User Telnet program SHOULD report to the user any TCP errors
+         that are reported by the transport layer (see "TCP/Application
+         Layer Interface" section in [INTRO:1]).
+
+      3.4.4  Non-Default Telnet Contact Port
+
+         A User Telnet program SHOULD allow the user to optionally
+         specify a non-standard contact port number at the Server Telnet
+         host.
+
+      3.4.5  Flushing Output
+
+         A User Telnet program SHOULD provide the user the ability to
+         specify whether or not output should be flushed when an IP is
+         sent; see Section 3.2.4.
+
+         For any output flushing scheme that causes the User Telnet to
+         flush output locally until a Telnet signal is received from the
+         Server, there SHOULD be a way for the user to manually restore
+         normal output, in case the Server fails to send the expected
+         signal.
+
+
+
+
+
+
+
+
+Internet Engineering Task Force                                [Page 26]
+
+
+
+
+RFC1123                  REMOTE LOGIN -- TELNET             October 1989
+
+
+   3.5.  TELNET REQUIREMENTS SUMMARY
+
+
+                                                 |        | | | |S| |
+                                                 |        | | | |H| |F
+                                                 |        | | | |O|M|o
+                                                 |        | |S| |U|U|o
+                                                 |        | |H| |L|S|t
+                                                 |        |M|O| |D|T|n
+                                                 |        |U|U|M| | |o
+                                                 |        |S|L|A|N|N|t
+                                                 |        |T|D|Y|O|O|t
+FEATURE                                          |SECTION | | | |T|T|e
+-------------------------------------------------|--------|-|-|-|-|-|--
+                                                 |        | | | | | |
+Option Negotiation                               |3.2.1   |x| | | | |
+  Avoid negotiation loops                        |3.2.1   |x| | | | |
+  Refuse unsupported options                     |3.2.1   |x| | | | |
+  Negotiation OK anytime on connection           |3.2.1   | |x| | | |
+  Default to NVT                                 |3.2.1   |x| | | | |
+  Send official name in Term-Type option         |3.2.8   |x| | | | |
+  Accept any name in Term-Type option            |3.2.8   |x| | | | |
+  Implement Binary, Suppress-GA options          |3.3.3   |x| | | | |
+  Echo, Status, EOL, Ext-Opt-List options        |3.3.3   | |x| | | |
+  Implement Window-Size option if appropriate    |3.3.3   | |x| | | |
+  Server initiate mode negotiations              |3.3.4   | |x| | | |
+  User can enable/disable init negotiations      |3.3.4   | |x| | | |
+                                                 |        | | | | | |
+Go-Aheads                                        |        | | | | | |
+  Non-GA server negotiate SUPPRESS-GA option     |3.2.2   |x| | | | |
+  User or Server accept SUPPRESS-GA option       |3.2.2   |x| | | | |
+  User Telnet ignore GA's                        |3.2.2   | | |x| | |
+                                                 |        | | | | | |
+Control Functions                                |        | | | | | |
+  Support SE NOP DM IP AO AYT SB                 |3.2.3   |x| | | | |
+  Support EOR EC EL Break                        |3.2.3   | | |x| | |
+  Ignore unsupported control functions           |3.2.3   |x| | | | |
+  User, Server discard urgent data up to DM      |3.2.4   |x| | | | |
+  User Telnet send "Synch" after IP, AO, AYT     |3.2.4   | |x| | | |
+  Server Telnet reply Synch to IP                |3.2.4   | | |x| | |
+  Server Telnet reply Synch to AO                |3.2.4   |x| | | | |
+  User Telnet can flush output when send IP      |3.2.4   | |x| | | |
+                                                 |        | | | | | |
+Encoding                                         |        | | | | | |
+  Send high-order bit in NVT mode                |3.2.5   | | | |x| |
+  Send high-order bit as parity bit              |3.2.5   | | | | |x|
+  Negot. BINARY if pass high-ord. bit to applic  |3.2.5   | |x| | | |
+  Always double IAC data byte                    |3.2.6   |x| | | | |
+
+
+
+Internet Engineering Task Force                                [Page 27]
+
+
+
+
+RFC1123                  REMOTE LOGIN -- TELNET             October 1989
+
+
+  Double IAC data byte in binary mode            |3.2.7   |x| | | | |
+  Obey Telnet cmds in binary mode                |3.2.7   |x| | | | |
+  End-of-line, CR NUL in binary mode             |3.2.7   | | | | |x|
+                                                 |        | | | | | |
+End-of-Line                                      |        | | | | | |
+  EOL at Server same as local end-of-line        |3.3.1   |x| | | | |
+  ASCII Server accept CR LF or CR NUL for EOL    |3.3.1   |x| | | | |
+  User Telnet able to send CR LF, CR NUL, or LF  |3.3.1   |x| | | | |
+    ASCII user able to select CR LF/CR NUL       |3.3.1   | |x| | | |
+    User Telnet default mode is CR LF            |3.3.1   | |x| | | |
+  Non-interactive uses CR LF for EOL             |3.3.1   |x| | | | |
+                                                 |        | | | | | |
+User Telnet interface                            |        | | | | | |
+  Input & output all 7-bit characters            |3.4.1   | |x| | | |
+  Bypass local op sys interpretation             |3.4.1   | |x| | | |
+  Escape character                               |3.4.1   |x| | | | |
+     User-settable escape character              |3.4.1   | |x| | | |
+  Escape to enter 8-bit values                   |3.4.1   | | |x| | |
+  Can input IP, AO, AYT                          |3.4.2   |x| | | | |
+  Can input EC, EL, Break                        |3.4.2   | |x| | | |
+  Report TCP connection errors to user           |3.4.3   | |x| | | |
+  Optional non-default contact port              |3.4.4   | |x| | | |
+  Can spec: output flushed when IP sent          |3.4.5   | |x| | | |
+  Can manually restore output mode               |3.4.5   | |x| | | |
+                                                 |        | | | | | |
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Internet Engineering Task Force                                [Page 28]
+
+
+
+
+RFC1123                   FILE TRANSFER -- FTP              October 1989
+
+
+4.  FILE TRANSFER
+
+   4.1  FILE TRANSFER PROTOCOL -- FTP
+
+      4.1.1  INTRODUCTION
+
+         The File Transfer Protocol FTP is the primary Internet standard
+         for file transfer.  The current specification is contained in
+         RFC-959 [FTP:1].
+
+         FTP uses separate simultaneous TCP connections for control and
+         for data transfer.  The FTP protocol includes many features,
+         some of which are not commonly implemented.  However, for every
+         feature in FTP, there exists at least one implementation.  The
+         minimum implementation defined in RFC-959 was too small, so a
+         somewhat larger minimum implementation is defined here.
+
+         Internet users have been unnecessarily burdened for years by
+         deficient FTP implementations.  Protocol implementors have
+         suffered from the erroneous opinion that implementing FTP ought
+         to be a small and trivial task.  This is wrong, because FTP has
+         a user interface, because it has to deal (correctly) with the
+         whole variety of communication and operating system errors that
+         may occur, and because it has to handle the great diversity of
+         real file systems in the world.
+
+      4.1.2.  PROTOCOL WALK-THROUGH
+
+         4.1.2.1  LOCAL Type: RFC-959 Section 3.1.1.4
+
+            An FTP program MUST support TYPE I ("IMAGE" or binary type)
+            as well as TYPE L 8 ("LOCAL" type with logical byte size 8).
+            A machine whose memory is organized into m-bit words, where
+            m is not a multiple of 8, MAY also support TYPE L m.
+
+            DISCUSSION:
+                 The command "TYPE L 8" is often required to transfer
+                 binary data between a machine whose memory is organized
+                 into (e.g.) 36-bit words and a machine with an 8-bit
+                 byte organization.  For an 8-bit byte machine, TYPE L 8
+                 is equivalent to IMAGE.
+
+                 "TYPE L m" is sometimes specified to the FTP programs
+                 on two m-bit word machines to ensure the correct
+                 transfer of a native-mode binary file from one machine
+                 to the other.  However, this command should have the
+                 same effect on these machines as "TYPE I".
+
+
+
+
+Internet Engineering Task Force                                [Page 29]
+
+
+
+
+RFC1123                   FILE TRANSFER -- FTP              October 1989
+
+
+         4.1.2.2  Telnet Format Control: RFC-959 Section 3.1.1.5.2
+
+            A host that makes no distinction between TYPE N and TYPE T
+            SHOULD implement TYPE T to be identical to TYPE N.
+
+            DISCUSSION:
+                 This provision should ease interoperation with hosts
+                 that do make this distinction.
+
+                 Many hosts represent text files internally as strings
+                 of ASCII characters, using the embedded ASCII format
+                 effector characters (LF, BS, FF, ...) to control the
+                 format when a file is printed.  For such hosts, there
+                 is no distinction between "print" files and other
+                 files.  However, systems that use record structured
+                 files typically need a special format for printable
+                 files (e.g., ASA carriage control).   For the latter
+                 hosts, FTP allows a choice of TYPE N or TYPE T.
+
+         4.1.2.3  Page Structure: RFC-959 Section 3.1.2.3 and Appendix I
+
+            Implementation of page structure is NOT RECOMMENDED in
+            general. However, if a host system does need to implement
+            FTP for "random access" or "holey" files, it MUST use the
+            defined page structure format rather than define a new
+            private FTP format.
+
+         4.1.2.4  Data Structure Transformations: RFC-959 Section 3.1.2
+
+            An FTP transformation between record-structure and file-
+            structure SHOULD be invertible, to the extent possible while
+            making the result useful on the target host.
+
+            DISCUSSION:
+                 RFC-959 required strict invertibility between record-
+                 structure and file-structure, but in practice,
+                 efficiency and convenience often preclude it.
+                 Therefore, the requirement is being relaxed.  There are
+                 two different objectives for transferring a file:
+                 processing it on the target host, or just storage.  For
+                 storage, strict invertibility is important.  For
+                 processing, the file created on the target host needs
+                 to be in the format expected by application programs on
+                 that host.
+
+                 As an example of the conflict, imagine a record-
+                 oriented operating system that requires some data files
+                 to have exactly 80 bytes in each record.  While STORing
+
+
+
+Internet Engineering Task Force                                [Page 30]
+
+
+
+
+RFC1123                   FILE TRANSFER -- FTP              October 1989
+
+
+                 a file on such a host, an FTP Server must be able to
+                 pad each line or record to 80 bytes; a later retrieval
+                 of such a file cannot be strictly invertible.
+
+         4.1.2.5  Data Connection Management: RFC-959 Section 3.3
+
+            A User-FTP that uses STREAM mode SHOULD send a PORT command
+            to assign a non-default data port before each transfer
+            command is issued.
+
+            DISCUSSION:
+                 This is required because of the long delay after a TCP
+                 connection is closed until its socket pair can be
+                 reused, to allow multiple transfers during a single FTP
+                 session.  Sending a port command can avoided if a
+                 transfer mode other than stream is used, by leaving the
+                 data transfer connection open between transfers.
+
+         4.1.2.6  PASV Command: RFC-959 Section 4.1.2
+
+            A server-FTP MUST implement the PASV command.
+
+            If multiple third-party transfers are to be executed during
+            the same session, a new PASV command MUST be issued before
+            each transfer command, to obtain a unique port pair.
+
+            IMPLEMENTATION:
+                 The format of the 227 reply to a PASV command is not
+                 well standardized.  In particular, an FTP client cannot
+                 assume that the parentheses shown on page 40 of RFC-959
+                 will be present (and in fact, Figure 3 on page 43 omits
+                 them).  Therefore, a User-FTP program that interprets
+                 the PASV reply must scan the reply for the first digit
+                 of the host and port numbers.
+
+                 Note that the host number h1,h2,h3,h4 is the IP address
+                 of the server host that is sending the reply, and that
+                 p1,p2 is a non-default data transfer port that PASV has
+                 assigned.
+
+         4.1.2.7  LIST and NLST Commands: RFC-959 Section 4.1.3
+
+            The data returned by an NLST command MUST contain only a
+            simple list of legal pathnames, such that the server can use
+            them directly as the arguments of subsequent data transfer
+            commands for the individual files.
+
+            The data returned by a LIST or NLST command SHOULD use an
+
+
+
+Internet Engineering Task Force                                [Page 31]
+
+
+
+
+RFC1123                   FILE TRANSFER -- FTP              October 1989
+
+
+            implied TYPE AN, unless the current type is EBCDIC, in which
+            case an implied TYPE EN SHOULD be used.
+
+            DISCUSSION:
+                 Many FTP clients support macro-commands that will get
+                 or put files matching a wildcard specification, using
+                 NLST to obtain a list of pathnames.  The expansion of
+                 "multiple-put" is local to the client, but "multiple-
+                 get" requires cooperation by the server.
+
+                 The implied type for LIST and NLST is designed to
+                 provide compatibility with existing User-FTPs, and in
+                 particular with multiple-get commands.
+
+         4.1.2.8  SITE Command: RFC-959 Section 4.1.3
+
+            A Server-FTP SHOULD use the SITE command for non-standard
+            features, rather than invent new private commands or
+            unstandardized extensions to existing commands.
+
+         4.1.2.9  STOU Command: RFC-959 Section 4.1.3
+
+            The STOU command stores into a uniquely named file.  When it
+            receives an STOU command, a Server-FTP MUST return the
+            actual file name in the "125 Transfer Starting" or the "150
+            Opening Data Connection" message that precedes the transfer
+            (the 250 reply code mentioned in RFC-959 is incorrect).  The
+            exact format of these messages is hereby defined to be as
+            follows:
+
+                125 FILE: pppp
+                150 FILE: pppp
+
+            where pppp represents the unique pathname of the file that
+            will be written.
+
+         4.1.2.10  Telnet End-of-line Code: RFC-959, Page 34
+
+            Implementors MUST NOT assume any correspondence between READ
+            boundaries on the control connection and the Telnet EOL
+            sequences (CR LF).
+
+            DISCUSSION:
+                 Thus, a server-FTP (or User-FTP) must continue reading
+                 characters from the control connection until a complete
+                 Telnet EOL sequence is encountered, before processing
+                 the command (or response, respectively).  Conversely, a
+                 single READ from the control connection may include
+
+
+
+Internet Engineering Task Force                                [Page 32]
+
+
+
+
+RFC1123                   FILE TRANSFER -- FTP              October 1989
+
+
+                 more than one FTP command.
+
+         4.1.2.11  FTP Replies: RFC-959 Section 4.2, Page 35
+
+            A Server-FTP MUST send only correctly formatted replies on
+            the control connection.  Note that RFC-959 (unlike earlier
+            versions of the FTP spec) contains no provision for a
+            "spontaneous" reply message.
+
+            A Server-FTP SHOULD use the reply codes defined in RFC-959
+            whenever they apply.  However, a server-FTP MAY use a
+            different reply code when needed, as long as the general
+            rules of Section 4.2 are followed. When the implementor has
+            a choice between a 4xx and 5xx reply code, a Server-FTP
+            SHOULD send a 4xx (temporary failure) code when there is any
+            reasonable possibility that a failed FTP will succeed a few
+            hours later.
+
+            A User-FTP SHOULD generally use only the highest-order digit
+            of a 3-digit reply code for making a procedural decision, to
+            prevent difficulties when a Server-FTP uses non-standard
+            reply codes.
+
+            A User-FTP MUST be able to handle multi-line replies.  If
+            the implementation imposes a limit on the number of lines
+            and if this limit is exceeded, the User-FTP MUST recover,
+            e.g., by ignoring the excess lines until the end of the
+            multi-line reply is reached.
+
+            A User-FTP SHOULD NOT interpret a 421 reply code ("Service
+            not available, closing control connection") specially, but
+            SHOULD detect closing of the control connection by the
+            server.
+
+            DISCUSSION:
+                 Server implementations that fail to strictly follow the
+                 reply rules often cause FTP user programs to hang.
+                 Note that RFC-959 resolved ambiguities in the reply
+                 rules found in earlier FTP specifications and must be
+                 followed.
+
+                 It is important to choose FTP reply codes that properly
+                 distinguish between temporary and permanent failures,
+                 to allow the successful use of file transfer client
+                 daemons.  These programs depend on the reply codes to
+                 decide whether or not to retry a failed transfer; using
+                 a permanent failure code (5xx) for a temporary error
+                 will cause these programs to give up unnecessarily.
+
+
+
+Internet Engineering Task Force                                [Page 33]
+
+
+
+
+RFC1123                   FILE TRANSFER -- FTP              October 1989
+
+
+                 When the meaning of a reply matches exactly the text
+                 shown in RFC-959, uniformity will be enhanced by using
+                 the RFC-959 text verbatim.  However, a Server-FTP
+                 implementor is encouraged to choose reply text that
+                 conveys specific system-dependent information, when
+                 appropriate.
+
+         4.1.2.12  Connections: RFC-959 Section 5.2
+
+            The words "and the port used" in the second paragraph of
+            this section of RFC-959 are erroneous (historical), and they
+            should be ignored.
+
+            On a multihomed server host, the default data transfer port
+            (L-1) MUST be associated with the same local IP address as
+            the corresponding control connection to port L.
+
+            A user-FTP MUST NOT send any Telnet controls other than
+            SYNCH and IP on an FTP control connection. In particular, it
+            MUST NOT attempt to negotiate Telnet options on the control
+            connection.  However, a server-FTP MUST be capable of
+            accepting and refusing Telnet negotiations (i.e., sending
+            DONT/WONT).
+
+            DISCUSSION:
+                 Although the RFC says: "Server- and User- processes
+                 should follow the conventions for the Telnet
+                 protocol...[on the control connection]", it is not the
+                 intent that Telnet option negotiation is to be
+                 employed.
+
+         4.1.2.13  Minimum Implementation; RFC-959 Section 5.1
+
+            The following commands and options MUST be supported by
+            every server-FTP and user-FTP, except in cases where the
+            underlying file system or operating system does not allow or
+            support a particular command.
+
+                 Type: ASCII Non-print, IMAGE, LOCAL 8
+                 Mode: Stream
+                 Structure: File, Record*
+                 Commands:
+                    USER, PASS, ACCT,
+                    PORT, PASV,
+                    TYPE, MODE, STRU,
+                    RETR, STOR, APPE,
+                    RNFR, RNTO, DELE,
+                    CWD,  CDUP, RMD,  MKD,  PWD,
+
+
+
+Internet Engineering Task Force                                [Page 34]
+
+
+
+
+RFC1123                   FILE TRANSFER -- FTP              October 1989
+
+
+                    LIST, NLST,
+                    SYST, STAT,
+                    HELP, NOOP, QUIT.
+
+            *Record structure is REQUIRED only for hosts whose file
+            systems support record structure.
+
+            DISCUSSION:
+                 Vendors are encouraged to implement a larger subset of
+                 the protocol.  For example, there are important
+                 robustness features in the protocol (e.g., Restart,
+                 ABOR, block mode) that would be an aid to some Internet
+                 users but are not widely implemented.
+
+                 A host that does not have record structures in its file
+                 system may still accept files with STRU R, recording
+                 the byte stream literally.
+
+      4.1.3  SPECIFIC ISSUES
+
+         4.1.3.1  Non-standard Command Verbs
+
+            FTP allows "experimental" commands, whose names begin with
+            "X".  If these commands are subsequently adopted as
+            standards, there may still be existing implementations using
+            the "X" form.  At present, this is true for the directory
+            commands:
+
+                RFC-959   "Experimental"
+
+                  MKD        XMKD
+                  RMD        XRMD
+                  PWD        XPWD
+                  CDUP       XCUP
+                  CWD        XCWD
+
+            All FTP implementations SHOULD recognize both forms of these
+            commands, by simply equating them with extra entries in the
+            command lookup table.
+
+            IMPLEMENTATION:
+                 A User-FTP can access a server that supports only the
+                 "X" forms by implementing a mode switch, or
+                 automatically using the following procedure: if the
+                 RFC-959 form of one of the above commands is rejected
+                 with a 500 or 502 response code, then try the
+                 experimental form; any other response would be passed
+                 to the user.
+
+
+
+Internet Engineering Task Force                                [Page 35]
+
+
+
+
+RFC1123                   FILE TRANSFER -- FTP              October 1989
+
+
+         4.1.3.2  Idle Timeout
+
+            A Server-FTP process SHOULD have an idle timeout, which will
+            terminate the process and close the control connection if
+            the server is inactive (i.e., no command or data transfer in
+            progress) for a long period of time.  The idle timeout time
+            SHOULD be configurable, and the default should be at least 5
+            minutes.
+
+            A client FTP process ("User-PI" in RFC-959) will need
+            timeouts on responses only if it is invoked from a program.
+
+            DISCUSSION:
+                 Without a timeout, a Server-FTP process may be left
+                 pending indefinitely if the corresponding client
+                 crashes without closing the control connection.
+
+         4.1.3.3  Concurrency of Data and Control
+
+            DISCUSSION:
+                 The intent of the designers of FTP was that a user
+                 should be able to send a STAT command at any time while
+                 data transfer was in progress and that the server-FTP
+                 would reply immediately with status -- e.g., the number
+                 of bytes transferred so far.  Similarly, an ABOR
+                 command should be possible at any time during a data
+                 transfer.
+
+                 Unfortunately, some small-machine operating systems
+                 make such concurrent programming difficult, and some
+                 other implementers seek minimal solutions, so some FTP
+                 implementations do not allow concurrent use of the data
+                 and control connections.  Even such a minimal server
+                 must be prepared to accept and defer a STAT or ABOR
+                 command that arrives during data transfer.
+
+         4.1.3.4  FTP Restart Mechanism
+
+            The description of the 110 reply on pp. 40-41 of RFC-959 is
+            incorrect; the correct description is as follows.  A restart
+            reply message, sent over the control connection from the
+            receiving FTP to the User-FTP, has the format:
+
+                110 MARK ssss = rrrr
+
+            Here:
+
+            *    ssss is a text string that appeared in a Restart Marker
+
+
+
+Internet Engineering Task Force                                [Page 36]
+
+
+
+
+RFC1123                   FILE TRANSFER -- FTP              October 1989
+
+
+                 in the data stream and encodes a position in the
+                 sender's file system;
+
+            *    rrrr encodes the corresponding position in the
+                 receiver's file system.
+
+            The encoding, which is specific to a particular file system
+            and network implementation, is always generated and
+            interpreted by the same system, either sender or receiver.
+
+            When an FTP that implements restart receives a Restart
+            Marker in the data stream, it SHOULD force the data to that
+            point to be written to stable storage before encoding the
+            corresponding position rrrr.  An FTP sending Restart Markers
+            MUST NOT assume that 110 replies will be returned
+            synchronously with the data, i.e., it must not await a 110
+            reply before sending more data.
+
+            Two new reply codes are hereby defined for errors
+            encountered in restarting a transfer:
+
+              554 Requested action not taken: invalid REST parameter.
+
+                 A 554 reply may result from a FTP service command that
+                 follows a REST command.  The reply indicates that the
+                 existing file at the Server-FTP cannot be repositioned
+                 as specified in the REST.
+
+              555 Requested action not taken: type or stru mismatch.
+
+                 A 555 reply may result from an APPE command or from any
+                 FTP service command following a REST command.  The
+                 reply indicates that there is some mismatch between the
+                 current transfer parameters (type and stru) and the
+                 attributes of the existing file.
+
+            DISCUSSION:
+                 Note that the FTP Restart mechanism requires that Block
+                 or Compressed mode be used for data transfer, to allow
+                 the Restart Markers to be included within the data
+                 stream.  The frequency of Restart Markers can be low.
+
+                 Restart Markers mark a place in the data stream, but
+                 the receiver may be performing some transformation on
+                 the data as it is stored into stable storage.  In
+                 general, the receiver's encoding must include any state
+                 information necessary to restart this transformation at
+                 any point of the FTP data stream.  For example, in TYPE
+
+
+
+Internet Engineering Task Force                                [Page 37]
+
+
+
+
+RFC1123                   FILE TRANSFER -- FTP              October 1989
+
+
+                 A transfers, some receiver hosts transform CR LF
+                 sequences into a single LF character on disk.   If a
+                 Restart Marker happens to fall between CR and LF, the
+                 receiver must encode in rrrr that the transfer must be
+                 restarted in a "CR has been seen and discarded" state.
+
+                 Note that the Restart Marker is required to be encoded
+                 as a string of printable ASCII characters, regardless
+                 of the type of the data.
+
+                 RFC-959 says that restart information is to be returned
+                 "to the user".  This should not be taken literally.  In
+                 general, the User-FTP should save the restart
+                 information (ssss,rrrr) in stable storage, e.g., append
+                 it to a restart control file.  An empty restart control
+                 file should be created when the transfer first starts
+                 and deleted automatically when the transfer completes
+                 successfully.  It is suggested that this file have a
+                 name derived in an easily-identifiable manner from the
+                 name of the file being transferred and the remote host
+                 name; this is analogous to the means used by many text
+                 editors for naming "backup" files.
+
+                 There are three cases for FTP restart.
+
+                 (1)  User-to-Server Transfer
+
+                      The User-FTP puts Restart Markers <ssss> at
+                      convenient places in the data stream.  When the
+                      Server-FTP receives a Marker, it writes all prior
+                      data to disk, encodes its file system position and
+                      transformation state as rrrr, and returns a "110
+                      MARK ssss = rrrr" reply over the control
+                      connection.  The User-FTP appends the pair
+                      (ssss,rrrr) to its restart control file.
+
+                      To restart the transfer, the User-FTP fetches the
+                      last (ssss,rrrr) pair from the restart control
+                      file, repositions its local file system and
+                      transformation state using ssss, and sends the
+                      command "REST rrrr" to the Server-FTP.
+
+                 (2)  Server-to-User Transfer
+
+                      The Server-FTP puts Restart Markers <ssss> at
+                      convenient places in the data stream.  When the
+                      User-FTP receives a Marker, it writes all prior
+                      data to disk, encodes its file system position and
+
+
+
+Internet Engineering Task Force                                [Page 38]
+
+
+
+
+RFC1123                   FILE TRANSFER -- FTP              October 1989
+
+
+                      transformation state as rrrr, and appends the pair
+                      (rrrr,ssss) to its restart control file.
+
+                      To restart the transfer, the User-FTP fetches the
+                      last (rrrr,ssss) pair from the restart control
+                      file, repositions its local file system and
+                      transformation state using rrrr, and sends the
+                      command "REST ssss" to the Server-FTP.
+
+                 (3)  Server-to-Server ("Third-Party") Transfer
+
+                      The sending Server-FTP puts Restart Markers <ssss>
+                      at convenient places in the data stream.  When it
+                      receives a Marker, the receiving Server-FTP writes
+                      all prior data to disk, encodes its file system
+                      position and transformation state as rrrr, and
+                      sends a "110 MARK ssss = rrrr" reply over the
+                      control connection to the User.  The User-FTP
+                      appends the pair (ssss,rrrr) to its restart
+                      control file.
+
+                      To restart the transfer, the User-FTP fetches the
+                      last (ssss,rrrr) pair from the restart control
+                      file, sends "REST ssss" to the sending Server-FTP,
+                      and sends "REST rrrr" to the receiving Server-FTP.
+
+
+      4.1.4  FTP/USER INTERFACE
+
+         This section discusses the user interface for a User-FTP
+         program.
+
+         4.1.4.1  Pathname Specification
+
+            Since FTP is intended for use in a heterogeneous
+            environment, User-FTP implementations MUST support remote
+            pathnames as arbitrary character strings, so that their form
+            and content are not limited by the conventions of the local
+            operating system.
+
+            DISCUSSION:
+                 In particular, remote pathnames can be of arbitrary
+                 length, and all the printing ASCII characters as well
+                 as space (0x20) must be allowed.  RFC-959 allows a
+                 pathname to contain any 7-bit ASCII character except CR
+                 or LF.
+
+
+
+
+
+Internet Engineering Task Force                                [Page 39]
+
+
+
+
+RFC1123                   FILE TRANSFER -- FTP              October 1989
+
+
+         4.1.4.2  "QUOTE" Command
+
+            A User-FTP program MUST implement a "QUOTE" command that
+            will pass an arbitrary character string to the server and
+            display all resulting response messages to the user.
+
+            To make the "QUOTE" command useful, a User-FTP SHOULD send
+            transfer control commands to the server as the user enters
+            them, rather than saving all the commands and sending them
+            to the server only when a data transfer is started.
+
+            DISCUSSION:
+                 The "QUOTE" command is essential to allow the user to
+                 access servers that require system-specific commands
+                 (e.g., SITE or ALLO), or to invoke new or optional
+                 features that are not implemented by the User-FTP.  For
+                 example, "QUOTE" may be used to specify "TYPE A T" to
+                 send a print file to hosts that require the
+                 distinction, even if the User-FTP does not recognize
+                 that TYPE.
+
+         4.1.4.3  Displaying Replies to User
+
+            A User-FTP SHOULD display to the user the full text of all
+            error reply messages it receives.  It SHOULD have a
+            "verbose" mode in which all commands it sends and the full
+            text and reply codes it receives are displayed, for
+            diagnosis of problems.
+
+         4.1.4.4  Maintaining Synchronization
+
+            The state machine in a User-FTP SHOULD be forgiving of
+            missing and unexpected reply messages, in order to maintain
+            command synchronization with the server.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Internet Engineering Task Force                                [Page 40]
+
+
+
+
+RFC1123                   FILE TRANSFER -- FTP              October 1989
+
+
+      4.1.5   FTP REQUIREMENTS SUMMARY
+
+                                           |               | | | |S| |
+                                           |               | | | |H| |F
+                                           |               | | | |O|M|o
+                                           |               | |S| |U|U|o
+                                           |               | |H| |L|S|t
+                                           |               |M|O| |D|T|n
+                                           |               |U|U|M| | |o
+                                           |               |S|L|A|N|N|t
+                                           |               |T|D|Y|O|O|t
+FEATURE                                    |SECTION        | | | |T|T|e
+-------------------------------------------|---------------|-|-|-|-|-|--
+Implement TYPE T if same as TYPE N         |4.1.2.2        | |x| | | |
+File/Record transform invertible if poss.  |4.1.2.4        | |x| | | |
+User-FTP send PORT cmd for stream mode     |4.1.2.5        | |x| | | |
+Server-FTP implement PASV                  |4.1.2.6        |x| | | | |
+  PASV is per-transfer                     |4.1.2.6        |x| | | | |
+NLST reply usable in RETR cmds             |4.1.2.7        |x| | | | |
+Implied type for LIST and NLST             |4.1.2.7        | |x| | | |
+SITE cmd for non-standard features         |4.1.2.8        | |x| | | |
+STOU cmd return pathname as specified      |4.1.2.9        |x| | | | |
+Use TCP READ boundaries on control conn.   |4.1.2.10       | | | | |x|
+                                           |               | | | | | |
+Server-FTP send only correct reply format  |4.1.2.11       |x| | | | |
+Server-FTP use defined reply code if poss. |4.1.2.11       | |x| | | |
+  New reply code following Section 4.2     |4.1.2.11       | | |x| | |
+User-FTP use only high digit of reply      |4.1.2.11       | |x| | | |
+User-FTP handle multi-line reply lines     |4.1.2.11       |x| | | | |
+User-FTP handle 421 reply specially        |4.1.2.11       | | | |x| |
+                                           |               | | | | | |
+Default data port same IP addr as ctl conn |4.1.2.12       |x| | | | |
+User-FTP send Telnet cmds exc. SYNCH, IP   |4.1.2.12       | | | | |x|
+User-FTP negotiate Telnet options          |4.1.2.12       | | | | |x|
+Server-FTP handle Telnet options           |4.1.2.12       |x| | | | |
+Handle "Experimental" directory cmds       |4.1.3.1        | |x| | | |
+Idle timeout in server-FTP                 |4.1.3.2        | |x| | | |
+    Configurable idle timeout              |4.1.3.2        | |x| | | |
+Receiver checkpoint data at Restart Marker |4.1.3.4        | |x| | | |
+Sender assume 110 replies are synchronous  |4.1.3.4        | | | | |x|
+                                           |               | | | | | |
+Support TYPE:                              |               | | | | | |
+  ASCII - Non-Print (AN)                   |4.1.2.13       |x| | | | |
+  ASCII - Telnet (AT) -- if same as AN     |4.1.2.2        | |x| | | |
+  ASCII - Carriage Control (AC)            |959 3.1.1.5.2  | | |x| | |
+  EBCDIC - (any form)                      |959 3.1.1.2    | | |x| | |
+  IMAGE                                    |4.1.2.1        |x| | | | |
+  LOCAL 8                                  |4.1.2.1        |x| | | | |
+
+
+
+Internet Engineering Task Force                                [Page 41]
+
+
+
+
+RFC1123                   FILE TRANSFER -- FTP              October 1989
+
+
+  LOCAL m                                  |4.1.2.1        | | |x| | |2
+                                           |               | | | | | |
+Support MODE:                              |               | | | | | |
+  Stream                                   |4.1.2.13       |x| | | | |
+  Block                                    |959 3.4.2      | | |x| | |
+                                           |               | | | | | |
+Support STRUCTURE:                         |               | | | | | |
+  File                                     |4.1.2.13       |x| | | | |
+  Record                                   |4.1.2.13       |x| | | | |3
+  Page                                     |4.1.2.3        | | | |x| |
+                                           |               | | | | | |
+Support commands:                          |               | | | | | |
+  USER                                     |4.1.2.13       |x| | | | |
+  PASS                                     |4.1.2.13       |x| | | | |
+  ACCT                                     |4.1.2.13       |x| | | | |
+  CWD                                      |4.1.2.13       |x| | | | |
+  CDUP                                     |4.1.2.13       |x| | | | |
+  SMNT                                     |959 5.3.1      | | |x| | |
+  REIN                                     |959 5.3.1      | | |x| | |
+  QUIT                                     |4.1.2.13       |x| | | | |
+                                           |               | | | | | |
+  PORT                                     |4.1.2.13       |x| | | | |
+  PASV                                     |4.1.2.6        |x| | | | |
+  TYPE                                     |4.1.2.13       |x| | | | |1
+  STRU                                     |4.1.2.13       |x| | | | |1
+  MODE                                     |4.1.2.13       |x| | | | |1
+                                           |               | | | | | |
+  RETR                                     |4.1.2.13       |x| | | | |
+  STOR                                     |4.1.2.13       |x| | | | |
+  STOU                                     |959 5.3.1      | | |x| | |
+  APPE                                     |4.1.2.13       |x| | | | |
+  ALLO                                     |959 5.3.1      | | |x| | |
+  REST                                     |959 5.3.1      | | |x| | |
+  RNFR                                     |4.1.2.13       |x| | | | |
+  RNTO                                     |4.1.2.13       |x| | | | |
+  ABOR                                     |959 5.3.1      | | |x| | |
+  DELE                                     |4.1.2.13       |x| | | | |
+  RMD                                      |4.1.2.13       |x| | | | |
+  MKD                                      |4.1.2.13       |x| | | | |
+  PWD                                      |4.1.2.13       |x| | | | |
+  LIST                                     |4.1.2.13       |x| | | | |
+  NLST                                     |4.1.2.13       |x| | | | |
+  SITE                                     |4.1.2.8        | | |x| | |
+  STAT                                     |4.1.2.13       |x| | | | |
+  SYST                                     |4.1.2.13       |x| | | | |
+  HELP                                     |4.1.2.13       |x| | | | |
+  NOOP                                     |4.1.2.13       |x| | | | |
+                                           |               | | | | | |
+
+
+
+Internet Engineering Task Force                                [Page 42]
+
+
+
+
+RFC1123                   FILE TRANSFER -- FTP              October 1989
+
+
+User Interface:                            |               | | | | | |
+  Arbitrary pathnames                      |4.1.4.1        |x| | | | |
+  Implement "QUOTE" command                |4.1.4.2        |x| | | | |
+  Transfer control commands immediately    |4.1.4.2        | |x| | | |
+  Display error messages to user           |4.1.4.3        | |x| | | |
+    Verbose mode                           |4.1.4.3        | |x| | | |
+  Maintain synchronization with server     |4.1.4.4        | |x| | | |
+
+Footnotes:
+
+(1)  For the values shown earlier.
+
+(2)  Here m is number of bits in a memory word.
+
+(3)  Required for host with record-structured file system, optional
+     otherwise.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Internet Engineering Task Force                                [Page 43]
+
+
+
+
+RFC1123                  FILE TRANSFER -- TFTP              October 1989
+
+
+   4.2  TRIVIAL FILE TRANSFER PROTOCOL -- TFTP
+
+      4.2.1  INTRODUCTION
+
+         The Trivial File Transfer Protocol TFTP is defined in RFC-783
+         [TFTP:1].
+
+         TFTP provides its own reliable delivery with UDP as its
+         transport protocol, using a simple stop-and-wait acknowledgment
+         system.  Since TFTP has an effective window of only one 512
+         octet segment, it can provide good performance only over paths
+         that have a small delay*bandwidth product.  The TFTP file
+         interface is very simple, providing no access control or
+         security.
+
+         TFTP's most important application is bootstrapping a host over
+         a local network, since it is simple and small enough to be
+         easily implemented in EPROM [BOOT:1, BOOT:2].  Vendors are
+         urged to support TFTP for booting.
+
+      4.2.2  PROTOCOL WALK-THROUGH
+
+         The TFTP specification [TFTP:1] is written in an open style,
+         and does not fully specify many parts of the protocol.
+
+         4.2.2.1  Transfer Modes: RFC-783, Page 3
+
+            The transfer mode "mail" SHOULD NOT be supported.
+
+         4.2.2.2  UDP Header: RFC-783, Page 17
+
+            The Length field of a UDP header is incorrectly defined; it
+            includes the UDP header length (8).
+
+      4.2.3  SPECIFIC ISSUES
+
+         4.2.3.1  Sorcerer's Apprentice Syndrome
+
+            There is a serious bug, known as the "Sorcerer's Apprentice
+            Syndrome," in the protocol specification.  While it does not
+            cause incorrect operation of the transfer (the file will
+            always be transferred correctly if the transfer completes),
+            this bug may cause excessive retransmission, which may cause
+            the transfer to time out.
+
+            Implementations MUST contain the fix for this problem: the
+            sender (i.e., the side originating the DATA packets) must
+            never resend the current DATA packet on receipt of a
+
+
+
+Internet Engineering Task Force                                [Page 44]
+
+
+
+
+RFC1123                  FILE TRANSFER -- TFTP              October 1989
+
+
+            duplicate ACK.
+
+            DISCUSSION:
+                 The bug is caused by the protocol rule that either
+                 side, on receiving an old duplicate datagram, may
+                 resend the current datagram.  If a packet is delayed in
+                 the network but later successfully delivered after
+                 either side has timed out and retransmitted a packet, a
+                 duplicate copy of the response may be generated.  If
+                 the other side responds to this duplicate with a
+                 duplicate of its own, then every datagram will be sent
+                 in duplicate for the remainder of the transfer (unless
+                 a datagram is lost, breaking the repetition).  Worse
+                 yet, since the delay is often caused by congestion,
+                 this duplicate transmission will usually causes more
+                 congestion, leading to more delayed packets, etc.
+
+                 The following example may help to clarify this problem.
+
+                     TFTP A                  TFTP B
+
+                 (1)  Receive ACK X-1
+                      Send DATA X
+                 (2)                          Receive DATA X
+                                              Send ACK X
+                        (ACK X is delayed in network,
+                         and  A times out):
+                 (3)  Retransmit DATA X
+
+                 (4)                          Receive DATA X again
+                                              Send ACK X again
+                 (5)  Receive (delayed) ACK X
+                      Send DATA X+1
+                 (6)                          Receive DATA X+1
+                                              Send ACK X+1
+                 (7)  Receive ACK X again
+                      Send DATA X+1 again
+                 (8)                          Receive DATA X+1 again
+                                              Send ACK X+1 again
+                 (9)  Receive ACK X+1
+                      Send DATA X+2
+                 (10)                         Receive DATA X+2
+                                              Send ACK X+3
+                 (11) Receive ACK X+1 again
+                      Send DATA X+2 again
+                 (12)                         Receive DATA X+2 again
+                                              Send ACK X+3 again
+
+
+
+
+Internet Engineering Task Force                                [Page 45]
+
+
+
+
+RFC1123                  FILE TRANSFER -- TFTP              October 1989
+
+
+                 Notice that once the delayed ACK arrives, the protocol
+                 settles down to duplicate all further packets
+                 (sequences 5-8 and 9-12).  The problem is caused not by
+                 either side timing out, but by both sides
+                 retransmitting the current packet when they receive a
+                 duplicate.
+
+                 The fix is to break the retransmission loop, as
+                 indicated above.  This is analogous to the behavior of
+                 TCP.  It is then possible to remove the retransmission
+                 timer on the receiver, since the resent ACK will never
+                 cause any action; this is a useful simplification where
+                 TFTP is used in a bootstrap program.  It is OK to allow
+                 the timer to remain, and it may be helpful if the
+                 retransmitted ACK replaces one that was genuinely lost
+                 in the network.  The sender still requires a retransmit
+                 timer, of course.
+
+         4.2.3.2  Timeout Algorithms
+
+            A TFTP implementation MUST use an adaptive timeout.
+
+            IMPLEMENTATION:
+                 TCP retransmission algorithms provide a useful base to
+                 work from.  At least an exponential backoff of
+                 retransmission timeout is necessary.
+
+         4.2.3.3  Extensions
+
+            A variety of non-standard extensions have been made to TFTP,
+            including additional transfer modes and a secure operation
+            mode (with passwords).  None of these have been
+            standardized.
+
+         4.2.3.4  Access Control
+
+            A server TFTP implementation SHOULD include some
+            configurable access control over what pathnames are allowed
+            in TFTP operations.
+
+         4.2.3.5  Broadcast Request
+
+            A TFTP request directed to a broadcast address SHOULD be
+            silently ignored.
+
+            DISCUSSION:
+                 Due to the weak access control capability of TFTP,
+                 directed broadcasts of TFTP requests to random networks
+
+
+
+Internet Engineering Task Force                                [Page 46]
+
+
+
+
+RFC1123                  FILE TRANSFER -- TFTP              October 1989
+
+
+                 could create a significant security hole.
+
+      4.2.4  TFTP REQUIREMENTS SUMMARY
+
+                                                 |        | | | |S| |
+                                                 |        | | | |H| |F
+                                                 |        | | | |O|M|o
+                                                 |        | |S| |U|U|o
+                                                 |        | |H| |L|S|t
+                                                 |        |M|O| |D|T|n
+                                                 |        |U|U|M| | |o
+                                                 |        |S|L|A|N|N|t
+                                                 |        |T|D|Y|O|O|t
+FEATURE                                          |SECTION | | | |T|T|e
+-------------------------------------------------|--------|-|-|-|-|-|--
+Fix Sorcerer's Apprentice Syndrome               |4.2.3.1 |x| | | | |
+Transfer modes:                                  |        | | | | | |
+  netascii                                       |RFC-783 |x| | | | |
+  octet                                          |RFC-783 |x| | | | |
+  mail                                           |4.2.2.1 | | | |x| |
+  extensions                                     |4.2.3.3 | | |x| | |
+Use adaptive timeout                             |4.2.3.2 |x| | | | |
+Configurable access control                      |4.2.3.4 | |x| | | |
+Silently ignore broadcast request                |4.2.3.5 | |x| | | |
+-------------------------------------------------|--------|-|-|-|-|-|--
+-------------------------------------------------|--------|-|-|-|-|-|--
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Internet Engineering Task Force                                [Page 47]
+
+
+
+
+RFC1123                  MAIL -- SMTP & RFC-822             October 1989
+
+
+5.  ELECTRONIC MAIL -- SMTP and RFC-822
+
+   5.1  INTRODUCTION
+
+      In the TCP/IP protocol suite, electronic mail in a format
+      specified in RFC-822 [SMTP:2] is transmitted using the Simple Mail
+      Transfer Protocol (SMTP) defined in RFC-821 [SMTP:1].
+
+      While SMTP has remained unchanged over the years, the Internet
+      community has made several changes in the way SMTP is used.  In
+      particular, the conversion to the Domain Name System (DNS) has
+      caused changes in address formats and in mail routing.  In this
+      section, we assume familiarity with the concepts and terminology
+      of the DNS, whose requirements are given in Section 6.1.
+
+      RFC-822 specifies the Internet standard format for electronic mail
+      messages.  RFC-822 supercedes an older standard, RFC-733, that may
+      still be in use in a few places, although it is obsolete.  The two
+      formats are sometimes referred to simply by number ("822" and
+      "733").
+
+      RFC-822 is used in some non-Internet mail environments with
+      different mail transfer protocols than SMTP, and SMTP has also
+      been adapted for use in some non-Internet environments.  Note that
+      this document presents the rules for the use of SMTP and RFC-822
+      for the Internet environment only; other mail environments that
+      use these protocols may be expected to have their own rules.
+
+   5.2  PROTOCOL WALK-THROUGH
+
+      This section covers both RFC-821 and RFC-822.
+
+      The SMTP specification in RFC-821 is clear and contains numerous
+      examples, so implementors should not find it difficult to
+      understand.  This section simply updates or annotates portions of
+      RFC-821 to conform with current usage.
+
+      RFC-822 is a long and dense document, defining a rich syntax.
+      Unfortunately, incomplete or defective implementations of RFC-822
+      are common.  In fact, nearly all of the many formats of RFC-822
+      are actually used, so an implementation generally needs to
+      recognize and correctly interpret all of the RFC-822 syntax.
+
+      5.2.1  The SMTP Model: RFC-821 Section 2
+
+         DISCUSSION:
+              Mail is sent by a series of request/response transactions
+              between a client, the "sender-SMTP," and a server, the
+
+
+
+Internet Engineering Task Force                                [Page 48]
+
+
+
+
+RFC1123                  MAIL -- SMTP & RFC-822             October 1989
+
+
+              "receiver-SMTP".  These transactions pass (1) the message
+              proper, which is composed of header and body, and (2) SMTP
+              source and destination addresses, referred to as the
+              "envelope".
+
+              The SMTP programs are analogous to Message Transfer Agents
+              (MTAs) of X.400.  There will be another level of protocol
+              software, closer to the end user, that is responsible for
+              composing and analyzing RFC-822 message headers; this
+              component is known as the "User Agent" in X.400, and we
+              use that term in this document.  There is a clear logical
+              distinction between the User Agent and the SMTP
+              implementation, since they operate on different levels of
+              protocol.  Note, however, that this distinction is may not
+              be exactly reflected the structure of typical
+              implementations of Internet mail.  Often there is a
+              program known as the "mailer" that implements SMTP and
+              also some of the User Agent functions; the rest of the
+              User Agent functions are included in a user interface used
+              for entering and reading mail.
+
+              The SMTP envelope is constructed at the originating site,
+              typically by the User Agent when the message is first
+              queued for the Sender-SMTP program.  The envelope
+              addresses may be derived from information in the message
+              header, supplied by the user interface (e.g., to implement
+              a bcc: request), or derived from local configuration
+              information (e.g., expansion of a mailing list).  The SMTP
+              envelope cannot in general be re-derived from the header
+              at a later stage in message delivery, so the envelope is
+              transmitted separately from the message itself using the
+              MAIL and RCPT commands of SMTP.
+
+              The text of RFC-821 suggests that mail is to be delivered
+              to an individual user at a host.  With the advent of the
+              domain system and of mail routing using mail-exchange (MX)
+              resource records, implementors should now think of
+              delivering mail to a user at a domain, which may or may
+              not be a particular host.  This DOES NOT change the fact
+              that SMTP is a host-to-host mail exchange protocol.
+
+      5.2.2  Canonicalization: RFC-821 Section 3.1
+
+         The domain names that a Sender-SMTP sends in MAIL and RCPT
+         commands MUST have been  "canonicalized," i.e., they must be
+         fully-qualified principal names or domain literals, not
+         nicknames or domain abbreviations.  A canonicalized name either
+         identifies a host directly or is an MX name; it cannot be a
+
+
+
+Internet Engineering Task Force                                [Page 49]
+
+
+
+
+RFC1123                  MAIL -- SMTP & RFC-822             October 1989
+
+
+         CNAME.
+
+      5.2.3  VRFY and EXPN Commands: RFC-821 Section 3.3
+
+         A receiver-SMTP MUST implement VRFY and SHOULD implement EXPN
+         (this requirement overrides RFC-821).  However, there MAY be
+         configuration information to disable VRFY and EXPN in a
+         particular installation; this might even allow EXPN to be
+         disabled for selected lists.
+
+         A new reply code is defined for the VRFY command:
+
+              252 Cannot VRFY user (e.g., info is not local), but will
+                  take message for this user and attempt delivery.
+
+         DISCUSSION:
+              SMTP users and administrators make regular use of these
+              commands for diagnosing mail delivery problems.  With the
+              increasing use of multi-level mailing list expansion
+              (sometimes more than two levels), EXPN has been
+              increasingly important for diagnosing inadvertent mail
+              loops.  On the other hand,  some feel that EXPN represents
+              a significant privacy, and perhaps even a security,
+              exposure.
+
+      5.2.4  SEND, SOML, and SAML Commands: RFC-821 Section 3.4
+
+         An SMTP MAY implement the commands to send a message to a
+         user's terminal: SEND, SOML, and SAML.
+
+         DISCUSSION:
+              It has been suggested that the use of mail relaying
+              through an MX record is inconsistent with the intent of
+              SEND to deliver a message immediately and directly to a
+              user's terminal.  However, an SMTP receiver that is unable
+              to write directly to the user terminal can return a "251
+              User Not Local" reply to the RCPT following a SEND, to
+              inform the originator of possibly deferred delivery.
+
+      5.2.5  HELO Command: RFC-821 Section 3.5
+
+         The sender-SMTP MUST ensure that the <domain> parameter in a
+         HELO command is a valid principal host domain name for the
+         client host.  As a result, the receiver-SMTP will not have to
+         perform MX resolution on this name in order to validate the
+         HELO parameter.
+
+         The HELO receiver MAY verify that the HELO parameter really
+
+
+
+Internet Engineering Task Force                                [Page 50]
+
+
+
+
+RFC1123                  MAIL -- SMTP & RFC-822             October 1989
+
+
+         corresponds to the IP address of the sender.  However, the
+         receiver MUST NOT refuse to accept a message, even if the
+         sender's HELO command fails verification.
+
+         DISCUSSION:
+              Verifying the HELO parameter requires a domain name lookup
+              and may therefore take considerable time.  An alternative
+              tool for tracking bogus mail sources is suggested below
+              (see "DATA Command").
+
+              Note also that the HELO argument is still required to have
+              valid <domain> syntax, since it will appear in a Received:
+              line; otherwise, a 501 error is to be sent.
+
+         IMPLEMENTATION:
+              When HELO parameter validation fails, a suggested
+              procedure is to insert a note about the unknown
+              authenticity of the sender into the message header (e.g.,
+              in the "Received:"  line).
+
+      5.2.6  Mail Relay: RFC-821 Section 3.6
+
+         We distinguish three types of mail (store-and-) forwarding:
+
+         (1)  A simple forwarder or "mail exchanger" forwards a message
+              using private knowledge about the recipient; see section
+              3.2 of RFC-821.
+
+         (2)  An SMTP mail "relay" forwards a message within an SMTP
+              mail environment as the result of an explicit source route
+              (as defined in section 3.6 of RFC-821).  The SMTP relay
+              function uses the "@...:" form of source route from RFC-
+              822 (see Section 5.2.19 below).
+
+         (3)  A mail "gateway" passes a message between different
+              environments.  The rules for mail gateways are discussed
+              below in Section 5.3.7.
+
+         An Internet host that is forwarding a message but is not a
+         gateway to a different mail environment (i.e., it falls under
+         (1) or (2)) SHOULD NOT alter any existing header fields,
+         although the host will add an appropriate Received: line as
+         required in Section 5.2.8.
+
+         A Sender-SMTP SHOULD NOT send a RCPT TO: command containing an
+         explicit source route using the "@...:" address form.  Thus,
+         the relay function defined in section  3.6 of RFC-821 should
+         not be used.
+
+
+
+Internet Engineering Task Force                                [Page 51]
+
+
+
+
+RFC1123                  MAIL -- SMTP & RFC-822             October 1989
+
+
+         DISCUSSION:
+              The intent is to discourage all source routing and to
+              abolish explicit source routing for mail delivery within
+              the Internet environment.  Source-routing is unnecessary;
+              the simple target address "user@domain" should always
+              suffice.  This is the result of an explicit architectural
+              decision to use universal naming rather than source
+              routing for mail.  Thus, SMTP provides end-to-end
+              connectivity, and the DNS provides globally-unique,
+              location-independent names.  MX records handle the major
+              case where source routing might otherwise be needed.
+
+         A receiver-SMTP MUST accept the explicit source route syntax in
+         the envelope, but it MAY implement the relay function as
+         defined in section 3.6 of RFC-821.  If it does not implement
+         the relay function, it SHOULD attempt to deliver the message
+         directly to the host to the right of the right-most "@" sign.
+
+         DISCUSSION:
+              For example, suppose a host that does not implement the
+              relay function receives a message with the SMTP command:
+              "RCPT TO:<@ALPHA,@BETA:joe@GAMMA>", where ALPHA, BETA, and
+              GAMMA represent domain names.  Rather than immediately
+              refusing the message with a 550 error reply as suggested
+              on page 20 of RFC-821, the host should try to forward the
+              message to GAMMA directly, using: "RCPT TO:<joe@GAMMA>".
+              Since this host does not support relaying, it is not
+              required to update the reverse path.
+
+              Some have suggested that source routing may be needed
+              occasionally for manually routing mail around failures;
+              however, the reality and importance of this need is
+              controversial.  The use of explicit SMTP mail relaying for
+              this purpose is discouraged, and in fact it may not be
+              successful, as many host systems do not support it.  Some
+              have used the "%-hack" (see Section 5.2.16) for this
+              purpose.
+
+      5.2.7  RCPT Command: RFC-821 Section 4.1.1
+
+         A host that supports a receiver-SMTP MUST support the reserved
+         mailbox "Postmaster".
+
+         The receiver-SMTP MAY verify RCPT parameters as they arrive;
+         however, RCPT responses MUST NOT be delayed beyond a reasonable
+         time (see Section 5.3.2).
+
+         Therefore, a "250 OK" response to a RCPT does not necessarily
+
+
+
+Internet Engineering Task Force                                [Page 52]
+
+
+
+
+RFC1123                  MAIL -- SMTP & RFC-822             October 1989
+
+
+         imply that the delivery address(es) are valid.  Errors found
+         after message acceptance will be reported by mailing a
+         notification message to an appropriate address (see Section
+         5.3.3).
+
+         DISCUSSION:
+              The set of conditions under which a RCPT parameter can be
+              validated immediately is an engineering design choice.
+              Reporting destination mailbox errors to the Sender-SMTP
+              before mail is transferred is generally desirable to save
+              time and network bandwidth, but this advantage is lost if
+              RCPT verification is lengthy.
+
+              For example, the receiver can verify immediately any
+              simple local reference, such as a single locally-
+              registered mailbox.  On the other hand, the "reasonable
+              time" limitation generally implies deferring verification
+              of a mailing list until after the message has been
+              transferred and accepted, since verifying a large mailing
+              list can take a very long time.  An implementation might
+              or might not choose to defer validation of addresses that
+              are non-local and therefore require a DNS lookup.  If a
+              DNS lookup is performed but a soft domain system error
+              (e.g., timeout) occurs, validity must be assumed.
+
+      5.2.8  DATA Command: RFC-821 Section 4.1.1
+
+         Every receiver-SMTP (not just one that "accepts a message for
+         relaying or for final delivery" [SMTP:1]) MUST insert a
+         "Received:" line at the beginning of a message.  In this line,
+         called a "time stamp line" in RFC-821:
+
+         *    The FROM field SHOULD contain both (1) the name of the
+              source host as presented in the HELO command and (2) a
+              domain literal containing the IP address of the source,
+              determined from the TCP connection.
+
+         *    The ID field MAY contain an "@" as suggested in RFC-822,
+              but this is not required.
+
+         *    The FOR field MAY contain a list of <path> entries when
+              multiple RCPT commands have been given.
+
+
+         An Internet mail program MUST NOT change a Received: line that
+         was previously added to the message header.
+
+
+
+
+
+Internet Engineering Task Force                                [Page 53]
+
+
+
+
+RFC1123                  MAIL -- SMTP & RFC-822             October 1989
+
+
+         DISCUSSION:
+              Including both the source host and the IP source address
+              in the Received: line may provide enough information for
+              tracking illicit mail sources and eliminate a need to
+              explicitly verify the HELO parameter.
+
+              Received: lines are primarily intended for humans tracing
+              mail routes, primarily of diagnosis of faults.  See also
+              the discussion under 5.3.7.
+
+         When the receiver-SMTP makes "final delivery" of a message,
+         then it MUST pass the MAIL FROM: address from the SMTP envelope
+         with the message, for use if an error notification message must
+         be sent later (see Section 5.3.3).  There is an analogous
+         requirement when gatewaying from the Internet into a different
+         mail environment; see Section 5.3.7.
+
+         DISCUSSION:
+              Note that the final reply to the DATA command depends only
+              upon the successful transfer and storage of the message.
+              Any problem with the destination address(es) must either
+              (1) have been reported in an SMTP error reply to the RCPT
+              command(s), or (2) be reported in a later error message
+              mailed to the originator.
+
+         IMPLEMENTATION:
+              The MAIL FROM: information may be passed as a parameter or
+              in a Return-Path: line inserted at the beginning of the
+              message.
+
+      5.2.9  Command Syntax: RFC-821 Section 4.1.2
+
+         The syntax shown in RFC-821 for the MAIL FROM: command omits
+         the case of an empty path:  "MAIL FROM: <>" (see RFC-821 Page
+         15).  An empty reverse path MUST be supported.
+
+      5.2.10  SMTP Replies:  RFC-821 Section 4.2
+
+         A receiver-SMTP SHOULD send only the reply codes listed in
+         section 4.2.2 of RFC-821 or in this document.  A receiver-SMTP
+         SHOULD use the text shown in examples in RFC-821 whenever
+         appropriate.
+
+         A sender-SMTP MUST determine its actions only by the reply
+         code, not by the text (except for 251 and 551 replies); any
+         text, including no text at all, must be acceptable.  The space
+         (blank) following the reply code is considered part of the
+         text.  Whenever possible, a sender-SMTP SHOULD test only the
+
+
+
+Internet Engineering Task Force                                [Page 54]
+
+
+
+
+RFC1123                  MAIL -- SMTP & RFC-822             October 1989
+
+
+         first digit of the reply code, as specified in Appendix E of
+         RFC-821.
+
+         DISCUSSION:
+              Interoperability problems have arisen with SMTP systems
+              using reply codes that are not listed explicitly in RFC-
+              821 Section 4.3 but are legal according to the theory of
+              reply codes explained in Appendix E.
+
+      5.2.11  Transparency: RFC-821 Section 4.5.2
+
+         Implementors MUST be sure that their mail systems always add
+         and delete periods to ensure message transparency.
+
+      5.2.12  WKS Use in MX Processing: RFC-974, p. 5
+
+         RFC-974 [SMTP:3] recommended that the domain system be queried
+         for WKS ("Well-Known Service") records, to verify that each
+         proposed mail target does support SMTP.  Later experience has
+         shown that WKS is not widely supported, so the WKS step in MX
+         processing SHOULD NOT be used.
+
+      The following are notes on RFC-822, organized by section of that
+      document.
+
+      5.2.13  RFC-822 Message Specification: RFC-822 Section 4
+
+         The syntax shown for the Return-path line omits the possibility
+         of a null return path, which is used to prevent looping of
+         error notifications (see Section 5.3.3).  The complete syntax
+         is:
+
+             return = "Return-path"  ":" route-addr
+                    / "Return-path"  ":" "<" ">"
+
+         The set of optional header fields is hereby expanded to include
+         the Content-Type field defined in RFC-1049 [SMTP:7].  This
+         field "allows mail reading systems to automatically identify
+         the type of a structured message body and to process it for
+         display accordingly".  [SMTP:7]  A User Agent MAY support this
+         field.
+
+      5.2.14  RFC-822 Date and Time Specification: RFC-822 Section 5
+
+         The syntax for the date is hereby changed to:
+
+            date = 1*2DIGIT month 2*4DIGIT
+
+
+
+
+Internet Engineering Task Force                                [Page 55]
+
+
+
+
+RFC1123                  MAIL -- SMTP & RFC-822             October 1989
+
+
+         All mail software SHOULD use 4-digit years in dates, to ease
+         the transition to the next century.
+
+         There is a strong trend towards the use of numeric timezone
+         indicators, and implementations SHOULD use numeric timezones
+         instead of timezone names.  However, all implementations MUST
+         accept either notation.  If timezone names are used, they MUST
+         be exactly as defined in RFC-822.
+
+         The military time zones are specified incorrectly in RFC-822:
+         they count the wrong way from UT (the signs are reversed).  As
+         a result, military time zones in RFC-822 headers carry no
+         information.
+
+         Finally, note that there is a typo in the definition of "zone"
+         in the syntax summary of appendix D; the correct definition
+         occurs in Section 3 of RFC-822.
+
+      5.2.15  RFC-822 Syntax Change: RFC-822 Section 6.1
+
+         The syntactic definition of "mailbox" in RFC-822 is hereby
+         changed to:
+
+            mailbox =  addr-spec            ; simple address
+                    / [phrase] route-addr   ; name & addr-spec
+
+         That is, the phrase preceding a route address is now OPTIONAL.
+         This change makes the following header field legal, for
+         example:
+
+             From: <craig@nnsc.nsf.net>
+
+      5.2.16  RFC-822  Local-part: RFC-822 Section 6.2
+
+         The basic mailbox address specification has the form: "local-
+         part@domain".  Here "local-part", sometimes called the "left-
+         hand side" of the address, is domain-dependent.
+
+         A host that is forwarding the message but is not the
+         destination host implied by the right-hand side "domain" MUST
+         NOT interpret or modify the "local-part" of the address.
+
+         When mail is to be gatewayed from the Internet mail environment
+         into a foreign mail environment (see Section 5.3.7), routing
+         information for that foreign environment MAY be embedded within
+         the "local-part" of the address.  The gateway will then
+         interpret this local part appropriately for the foreign mail
+         environment.
+
+
+
+Internet Engineering Task Force                                [Page 56]
+
+
+
+
+RFC1123                  MAIL -- SMTP & RFC-822             October 1989
+
+
+         DISCUSSION:
+              Although source routes are discouraged within the Internet
+              (see Section 5.2.6), there are non-Internet mail
+              environments whose delivery mechanisms do depend upon
+              source routes.  Source routes for extra-Internet
+              environments can generally be buried in the "local-part"
+              of the address (see Section 5.2.16) while mail traverses
+              the Internet.  When the mail reaches the appropriate
+              Internet mail gateway, the gateway will interpret the
+              local-part and build the necessary address or route for
+              the target mail environment.
+
+              For example, an Internet host might send mail to:
+              "a!b!c!user@gateway-domain".  The complex local part
+              "a!b!c!user" would be uninterpreted within the Internet
+              domain, but could be parsed and understood by the
+              specified mail gateway.
+
+              An embedded source route is sometimes encoded in the
+              "local-part" using "%" as a right-binding routing
+              operator.  For example, in:
+
+                 user%domain%relay3%relay2@relay1
+
+              the "%" convention implies that the mail is to be routed
+              from "relay1" through "relay2", "relay3", and finally to
+              "user" at "domain".  This is commonly known as the "%-
+              hack".  It is suggested that "%" have lower precedence
+              than any other routing operator (e.g., "!") hidden in the
+              local-part; for example, "a!b%c" would be interpreted as
+              "(a!b)%c".
+
+              Only the target host (in this case, "relay1") is permitted
+              to analyze the local-part "user%domain%relay3%relay2".
+
+      5.2.17  Domain Literals: RFC-822 Section 6.2.3
+
+         A mailer MUST be able to accept and parse an Internet domain
+         literal whose content ("dtext"; see RFC-822) is a dotted-
+         decimal host address.  This satisfies the requirement of
+         Section 2.1 for the case of mail.
+
+         An SMTP MUST accept and recognize a domain literal for any of
+         its own IP addresses.
+
+
+
+
+
+
+
+Internet Engineering Task Force                                [Page 57]
+
+
+
+
+RFC1123                  MAIL -- SMTP & RFC-822             October 1989
+
+
+      5.2.18  Common Address Formatting Errors: RFC-822 Section 6.1
+
+         Errors in formatting or parsing 822 addresses are unfortunately
+         common.  This section mentions only the most common errors.  A
+         User Agent MUST accept all valid RFC-822 address formats, and
+         MUST NOT generate illegal address syntax.
+
+         o    A common error is to leave out the semicolon after a group
+              identifier.
+
+         o    Some systems fail to fully-qualify domain names in
+              messages they generate.  The right-hand side of an "@"
+              sign in a header address field MUST be a fully-qualified
+              domain name.
+
+              For example, some systems fail to fully-qualify the From:
+              address; this prevents a "reply" command in the user
+              interface from automatically constructing a return
+              address.
+
+              DISCUSSION:
+                   Although RFC-822 allows the local use of abbreviated
+                   domain names within a domain, the application of
+                   RFC-822 in Internet mail does not allow this.  The
+                   intent is that an Internet host must not send an SMTP
+                   message header containing an abbreviated domain name
+                   in an address field.  This allows the address fields
+                   of the header to be passed without alteration across
+                   the Internet, as required in Section 5.2.6.
+
+         o    Some systems mis-parse multiple-hop explicit source routes
+              such as:
+
+                  @relay1,@relay2,@relay3:user@domain.
+
+
+         o    Some systems over-qualify domain names by adding a
+              trailing dot to some or all domain names in addresses or
+              message-ids.  This violates RFC-822 syntax.
+
+
+      5.2.19  Explicit Source Routes: RFC-822 Section 6.2.7
+
+         Internet host software SHOULD NOT create an RFC-822 header
+         containing an address with an explicit source route, but MUST
+         accept such headers for compatibility with earlier systems.
+
+         DISCUSSION:
+
+
+
+Internet Engineering Task Force                                [Page 58]
+
+
+
+
+RFC1123                  MAIL -- SMTP & RFC-822             October 1989
+
+
+              In an understatement, RFC-822 says "The use of explicit
+              source routing is discouraged".  Many hosts implemented
+              RFC-822 source routes incorrectly, so the syntax cannot be
+              used unambiguously in practice.  Many users feel the
+              syntax is ugly.  Explicit source routes are not needed in
+              the mail envelope for delivery; see Section 5.2.6.  For
+              all these reasons, explicit source routes using the RFC-
+              822 notations are not to be used in Internet mail headers.
+
+              As stated in Section 5.2.16, it is necessary to allow an
+              explicit source route to be buried in the local-part of an
+              address, e.g., using the "%-hack", in order to allow mail
+              to be gatewayed into another environment in which explicit
+              source routing is necessary.  The vigilant will observe
+              that there is no way for a User Agent to detect and
+              prevent the use of such implicit source routing when the
+              destination is within the Internet.  We can only
+              discourage source routing of any kind within the Internet,
+              as unnecessary and undesirable.
+
+   5.3  SPECIFIC ISSUES
+
+      5.3.1  SMTP Queueing Strategies
+
+         The common structure of a host SMTP implementation includes
+         user mailboxes, one or more areas for queueing messages in
+         transit, and one or more daemon processes for sending and
+         receiving mail.  The exact structure will vary depending on the
+         needs of the users on the host and the number and size of
+         mailing lists supported by the host.  We describe several
+         optimizations that have proved helpful, particularly for
+         mailers supporting high traffic levels.
+
+         Any queueing strategy MUST include:
+
+         o    Timeouts on all activities.  See Section 5.3.2.
+
+         o    Never sending error messages in response to error
+              messages.
+
+
+         5.3.1.1 Sending Strategy
+
+            The general model of a sender-SMTP is one or more processes
+            that periodically attempt to transmit outgoing mail.  In a
+            typical system, the program that composes a message has some
+            method for requesting immediate attention for a new piece of
+            outgoing mail, while mail that cannot be transmitted
+
+
+
+Internet Engineering Task Force                                [Page 59]
+
+
+
+
+RFC1123                  MAIL -- SMTP & RFC-822             October 1989
+
+
+            immediately MUST be queued and periodically retried by the
+            sender.  A mail queue entry will include not only the
+            message itself but also the envelope information.
+
+            The sender MUST delay retrying a particular destination
+            after one attempt has failed.  In general, the retry
+            interval SHOULD be at least 30 minutes; however, more
+            sophisticated and variable strategies will be beneficial
+            when the sender-SMTP can determine the reason for non-
+            delivery.
+
+            Retries continue until the message is transmitted or the
+            sender gives up; the give-up time generally needs to be at
+            least 4-5 days.  The parameters to the retry algorithm MUST
+            be configurable.
+
+            A sender SHOULD keep a list of hosts it cannot reach and
+            corresponding timeouts, rather than just retrying queued
+            mail items.
+
+            DISCUSSION:
+                 Experience suggests that failures are typically
+                 transient (the target system has crashed), favoring a
+                 policy of two connection attempts in the first hour the
+                 message is in the queue, and then backing off to once
+                 every two or three hours.
+
+                 The sender-SMTP can shorten the queueing delay by
+                 cooperation with the receiver-SMTP.  In particular, if
+                 mail is received from a particular address, it is good
+                 evidence that any mail queued for that host can now be
+                 sent.
+
+                 The strategy may be further modified as a result of
+                 multiple addresses per host (see Section 5.3.4), to
+                 optimize delivery time vs. resource usage.
+
+                 A sender-SMTP may have a large queue of messages for
+                 each unavailable destination host, and if it retried
+                 all these messages in every retry cycle, there would be
+                 excessive Internet overhead and the daemon would be
+                 blocked for a long period.  Note that an SMTP can
+                 generally determine that a delivery attempt has failed
+                 only after a timeout of a minute or more; a one minute
+                 timeout per connection will result in a very large
+                 delay if it is repeated for dozens or even hundreds of
+                 queued messages.
+
+
+
+
+Internet Engineering Task Force                                [Page 60]
+
+
+
+
+RFC1123                  MAIL -- SMTP & RFC-822             October 1989
+
+
+            When the same message is to be delivered to several users on
+            the same host, only one copy of the message SHOULD be
+            transmitted.  That is, the sender-SMTP should use the
+            command sequence: RCPT, RCPT,... RCPT, DATA instead of the
+            sequence: RCPT, DATA, RCPT, DATA,... RCPT, DATA.
+            Implementation of this efficiency feature is strongly urged.
+
+            Similarly, the sender-SMTP MAY support multiple concurrent
+            outgoing mail transactions to achieve timely delivery.
+            However, some limit SHOULD be imposed to protect the host
+            from devoting all its resources to mail.
+
+            The use of the different addresses of a multihomed host is
+            discussed below.
+
+         5.3.1.2  Receiving strategy
+
+            The receiver-SMTP SHOULD attempt to keep a pending listen on
+            the SMTP port at all times.  This will require the support
+            of multiple incoming TCP connections for SMTP.  Some limit
+            MAY be imposed.
+
+            IMPLEMENTATION:
+                 When the receiver-SMTP receives mail from a particular
+                 host address, it could notify the sender-SMTP to retry
+                 any mail pending for that host address.
+
+      5.3.2  Timeouts in SMTP
+
+         There are two approaches to timeouts in the sender-SMTP:  (a)
+         limit the time for each SMTP command separately, or (b) limit
+         the time for the entire SMTP dialogue for a single mail
+         message.  A sender-SMTP SHOULD use option (a), per-command
+         timeouts.  Timeouts SHOULD be easily reconfigurable, preferably
+         without recompiling the SMTP code.
+
+         DISCUSSION:
+              Timeouts are an essential feature of an SMTP
+              implementation.  If the timeouts are too long (or worse,
+              there are no timeouts), Internet communication failures or
+              software bugs in receiver-SMTP programs can tie up SMTP
+              processes indefinitely.  If the timeouts are too short,
+              resources will be wasted with attempts that time out part
+              way through message delivery.
+
+              If option (b) is used, the timeout has to be very large,
+              e.g., an hour, to allow time to expand very large mailing
+              lists.  The timeout may also need to increase linearly
+
+
+
+Internet Engineering Task Force                                [Page 61]
+
+
+
+
+RFC1123                  MAIL -- SMTP & RFC-822             October 1989
+
+
+              with the size of the message, to account for the time to
+              transmit a very large message.  A large fixed timeout
+              leads to two problems:  a failure can still tie up the
+              sender for a very long time, and very large messages may
+              still spuriously time out (which is a wasteful failure!).
+
+              Using the recommended option (a), a timer is set for each
+              SMTP command and for each buffer of the data transfer.
+              The latter means that the overall timeout is inherently
+              proportional to the size of the message.
+
+         Based on extensive experience with busy mail-relay hosts, the
+         minimum per-command timeout values SHOULD be as follows:
+
+         o    Initial 220 Message: 5 minutes
+
+              A Sender-SMTP process needs to distinguish between a
+              failed TCP connection and a delay in receiving the initial
+              220 greeting message.  Many receiver-SMTPs will accept a
+              TCP connection but delay delivery of the 220 message until
+              their system load will permit more mail to be processed.
+
+         o    MAIL Command: 5 minutes
+
+
+         o    RCPT Command: 5 minutes
+
+              A longer timeout would be required if processing of
+              mailing lists and aliases were not deferred until after
+              the message was accepted.
+
+         o    DATA Initiation: 2 minutes
+
+              This is while awaiting the "354 Start Input" reply to a
+              DATA command.
+
+         o    Data Block: 3 minutes
+
+              This is while awaiting the completion of each TCP SEND
+              call transmitting a chunk of data.
+
+         o    DATA Termination: 10 minutes.
+
+              This is while awaiting the "250 OK" reply. When the
+              receiver gets the final period terminating the message
+              data, it typically performs processing to deliver the
+              message to a user mailbox.  A spurious timeout at this
+              point would be very wasteful, since the message has been
+
+
+
+Internet Engineering Task Force                                [Page 62]
+
+
+
+
+RFC1123                  MAIL -- SMTP & RFC-822             October 1989
+
+
+              successfully sent.
+
+         A receiver-SMTP SHOULD have a timeout of at least 5 minutes
+         while it is awaiting the next command from the sender.
+
+      5.3.3  Reliable Mail Receipt
+
+         When the receiver-SMTP accepts a piece of mail (by sending a
+         "250 OK" message in response to DATA), it is accepting
+         responsibility for delivering or relaying the message.  It must
+         take this responsibility seriously, i.e., it MUST NOT lose the
+         message for frivolous reasons, e.g., because the host later
+         crashes or because of a predictable resource shortage.
+
+         If there is a delivery failure after acceptance of a message,
+         the receiver-SMTP MUST formulate and mail a notification
+         message.  This notification MUST be sent using a null ("<>")
+         reverse path in the envelope; see Section 3.6 of RFC-821.  The
+         recipient of this notification SHOULD be the address from the
+         envelope return path (or the Return-Path: line).  However, if
+         this address is null ("<>"),  the receiver-SMTP MUST NOT send a
+         notification.  If the address is an explicit source route, it
+         SHOULD be stripped down to its final hop.
+
+         DISCUSSION:
+              For example, suppose that an error notification must be
+              sent for a message that arrived with:
+              "MAIL FROM:<@a,@b:user@d>".  The notification message
+              should be sent to: "RCPT TO:<user@d>".
+
+              Some delivery failures after the message is accepted by
+              SMTP will be unavoidable.  For example, it may be
+              impossible for the receiver-SMTP to validate all the
+              delivery addresses in RCPT command(s) due to a "soft"
+              domain system error or because the target is a mailing
+              list (see earlier discussion of RCPT).
+
+         To avoid receiving duplicate messages as the result of
+         timeouts, a receiver-SMTP MUST seek to minimize the time
+         required to respond to the final "." that ends a message
+         transfer.  See RFC-1047 [SMTP:4] for a discussion of this
+         problem.
+
+      5.3.4  Reliable Mail Transmission
+
+         To transmit a message, a sender-SMTP determines the IP address
+         of the target host from the destination address in the
+         envelope.  Specifically, it maps the string to the right of the
+
+
+
+Internet Engineering Task Force                                [Page 63]
+
+
+
+
+RFC1123                  MAIL -- SMTP & RFC-822             October 1989
+
+
+         "@" sign into an IP address.  This mapping or the transfer
+         itself may fail with a soft error, in which case the sender-
+         SMTP will requeue the outgoing mail for a later retry, as
+         required in Section 5.3.1.1.
+
+         When it succeeds, the mapping can result in a list of
+         alternative delivery addresses rather than a single address,
+         because of (a) multiple MX records, (b) multihoming, or both.
+         To provide reliable mail transmission, the sender-SMTP MUST be
+         able to try (and retry) each of the addresses in this list in
+         order, until a delivery attempt succeeds.  However, there MAY
+         also be a configurable limit on the number of alternate
+         addresses that can be tried.  In any case, a host SHOULD try at
+         least two addresses.
+
+         The following information is to be used to rank the host
+         addresses:
+
+         (1)  Multiple MX Records -- these contain a preference
+              indication that should be used in sorting.  If there are
+              multiple destinations with the same preference and there
+              is no clear reason to favor one (e.g., by address
+              preference), then the sender-SMTP SHOULD pick one at
+              random to spread the load across multiple mail exchanges
+              for a specific organization; note that this is a
+              refinement of the procedure in [DNS:3].
+
+         (2)  Multihomed host -- The destination host (perhaps taken
+              from the preferred MX record) may be multihomed, in which
+              case the domain name resolver will return a list of
+              alternative IP addresses.  It is the responsibility of the
+              domain name resolver interface (see Section 6.1.3.4 below)
+              to have ordered this list by decreasing preference, and
+              SMTP MUST try them in the order presented.
+
+         DISCUSSION:
+              Although the capability to try multiple alternative
+              addresses is required, there may be circumstances where
+              specific installations want to limit or disable the use of
+              alternative addresses.  The question of whether a sender
+              should attempt retries using the different addresses of a
+              multihomed host has been controversial.  The main argument
+              for using the multiple addresses is that it maximizes the
+              probability of timely delivery, and indeed sometimes the
+              probability of any delivery; the counter argument is that
+              it may result in unnecessary resource use.
+
+              Note that resource use is also strongly determined by the
+
+
+
+Internet Engineering Task Force                                [Page 64]
+
+
+
+
+RFC1123                  MAIL -- SMTP & RFC-822             October 1989
+
+
+              sending strategy discussed in Section 5.3.1.
+
+      5.3.5  Domain Name Support
+
+         SMTP implementations MUST use the mechanism defined in Section
+         6.1 for mapping between domain names and IP addresses.  This
+         means that every Internet SMTP MUST include support for the
+         Internet DNS.
+
+         In particular, a sender-SMTP MUST support the MX record scheme
+         [SMTP:3].  See also Section 7.4 of [DNS:2] for information on
+         domain name support for SMTP.
+
+      5.3.6  Mailing Lists and Aliases
+
+         An SMTP-capable host SHOULD support both the alias and the list
+         form of address expansion for multiple delivery.  When a
+         message is delivered or forwarded to each address of an
+         expanded list form, the return address in the envelope
+         ("MAIL FROM:") MUST be changed to be the address of a person
+         who administers the list, but the message header MUST be left
+         unchanged; in particular, the "From" field of the message is
+         unaffected.
+
+         DISCUSSION:
+              An important mail facility is a mechanism for multi-
+              destination delivery of a single message, by transforming
+              or "expanding" a pseudo-mailbox address into a list of
+              destination mailbox addresses.  When a message is sent to
+              such a pseudo-mailbox (sometimes called an "exploder"),
+              copies are forwarded or redistributed to each mailbox in
+              the expanded list.  We classify such a pseudo-mailbox as
+              an "alias" or a "list", depending upon the expansion
+              rules:
+
+              (a)  Alias
+
+                   To expand an alias, the recipient mailer simply
+                   replaces the pseudo-mailbox address in the envelope
+                   with each of the expanded addresses in turn; the rest
+                   of the envelope and the message body are left
+                   unchanged.  The message is then delivered or
+                   forwarded to each expanded address.
+
+              (b)  List
+
+                   A mailing list may be said to operate by
+                   "redistribution" rather than by "forwarding".  To
+
+
+
+Internet Engineering Task Force                                [Page 65]
+
+
+
+
+RFC1123                  MAIL -- SMTP & RFC-822             October 1989
+
+
+                   expand a list, the recipient mailer replaces the
+                   pseudo-mailbox address in the envelope with each of
+                   the expanded addresses in turn. The return address in
+                   the envelope is changed so that all error messages
+                   generated by the final deliveries will be returned to
+                   a list administrator, not to the message originator,
+                   who generally has no control over the contents of the
+                   list and will typically find error messages annoying.
+
+
+      5.3.7  Mail Gatewaying
+
+         Gatewaying mail between different mail environments, i.e.,
+         different mail formats and protocols, is complex and does not
+         easily yield to standardization.  See for example [SMTP:5a],
+         [SMTP:5b].  However, some general requirements may be given for
+         a gateway between the Internet and another mail environment.
+
+         (A)  Header fields MAY be rewritten when necessary as messages
+              are gatewayed across mail environment boundaries.
+
+              DISCUSSION:
+                   This may involve interpreting the local-part of the
+                   destination address, as suggested in Section 5.2.16.
+
+                   The other mail systems gatewayed to the Internet
+                   generally use a subset of RFC-822 headers, but some
+                   of them do not have an equivalent to the SMTP
+                   envelope.  Therefore, when a message leaves the
+                   Internet environment, it may be necessary to fold the
+                   SMTP envelope information into the message header.  A
+                   possible solution would be to create new header
+                   fields to carry the envelope information (e.g., "X-
+                   SMTP-MAIL:" and "X-SMTP-RCPT:"); however, this would
+                   require changes in mail programs in the foreign
+                   environment.
+
+         (B)  When forwarding a message into or out of the Internet
+              environment, a gateway MUST prepend a Received: line, but
+              it MUST NOT alter in any way a Received: line that is
+              already in the header.
+
+              DISCUSSION:
+                   This requirement is a subset of the general
+                   "Received:" line requirement of Section 5.2.8; it is
+                   restated here for emphasis.
+
+                   Received: fields of messages originating from other
+
+
+
+Internet Engineering Task Force                                [Page 66]
+
+
+
+
+RFC1123                  MAIL -- SMTP & RFC-822             October 1989
+
+
+                   environments may not conform exactly to RFC822.
+                   However, the most important use of Received: lines is
+                   for debugging mail faults, and this debugging can be
+                   severely hampered by well-meaning gateways that try
+                   to "fix" a Received: line.
+
+                   The gateway is strongly encouraged to indicate the
+                   environment and protocol in the "via" clauses of
+                   Received field(s) that it supplies.
+
+         (C)  From the Internet side, the gateway SHOULD accept all
+              valid address formats in SMTP commands and in RFC-822
+              headers, and all valid RFC-822 messages.  Although a
+              gateway must accept an RFC-822 explicit source route
+              ("@...:" format) in either the RFC-822 header or in the
+              envelope, it MAY or may not act on the source route; see
+              Sections 5.2.6 and 5.2.19.
+
+              DISCUSSION:
+                   It is often tempting to restrict the range of
+                   addresses accepted at the mail gateway to simplify
+                   the translation into addresses for the remote
+                   environment.  This practice is based on the
+                   assumption that mail users have control over the
+                   addresses their mailers send to the mail gateway.  In
+                   practice, however, users have little control over the
+                   addresses that are finally sent; their mailers are
+                   free to change addresses into any legal RFC-822
+                   format.
+
+         (D)  The gateway MUST ensure that all header fields of a
+              message that it forwards into the Internet meet the
+              requirements for Internet mail.  In particular, all
+              addresses in "From:", "To:", "Cc:", etc., fields must be
+              transformed (if necessary) to satisfy RFC-822 syntax, and
+              they must be effective and useful for sending replies.
+
+
+         (E)  The translation algorithm used to convert mail from the
+              Internet protocols to another environment's protocol
+              SHOULD try to ensure that error messages from the foreign
+              mail environment are delivered to the return path from the
+              SMTP envelope, not to the sender listed in the "From:"
+              field of the RFC-822 message.
+
+              DISCUSSION:
+                   Internet mail lists usually place the address of the
+                   mail list maintainer in the envelope but leave the
+
+
+
+Internet Engineering Task Force                                [Page 67]
+
+
+
+
+RFC1123                  MAIL -- SMTP & RFC-822             October 1989
+
+
+                   original message header intact (with the "From:"
+                   field containing the original sender).  This yields
+                   the behavior the average recipient expects: a reply
+                   to the header gets sent to the original sender, not
+                   to a mail list maintainer; however, errors get sent
+                   to the maintainer (who can fix the problem) and not
+                   the sender (who probably cannot).
+
+         (F)  Similarly, when forwarding a message from another
+              environment into the Internet, the gateway SHOULD set the
+              envelope return path in accordance with an error message
+              return address, if any, supplied by the foreign
+              environment.
+
+
+      5.3.8  Maximum Message Size
+
+         Mailer software MUST be able to send and receive messages of at
+         least 64K bytes in length (including header), and a much larger
+         maximum size is highly desirable.
+
+         DISCUSSION:
+              Although SMTP does not define the maximum size of a
+              message, many systems impose implementation limits.
+
+              The current de facto minimum limit in the Internet is 64K
+              bytes.  However, electronic mail is used for a variety of
+              purposes that create much larger messages.  For example,
+              mail is often used instead of FTP for transmitting ASCII
+              files, and in particular to transmit entire documents.  As
+              a result, messages can be 1 megabyte or even larger.  We
+              note that the present document together with its lower-
+              layer companion contains 0.5 megabytes.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Internet Engineering Task Force                                [Page 68]
+
+
+
+
+RFC1123                  MAIL -- SMTP & RFC-822             October 1989
+
+
+   5.4  SMTP REQUIREMENTS SUMMARY
+
+                                               |          | | | |S| |
+                                               |          | | | |H| |F
+                                               |          | | | |O|M|o
+                                               |          | |S| |U|U|o
+                                               |          | |H| |L|S|t
+                                               |          |M|O| |D|T|n
+                                               |          |U|U|M| | |o
+                                               |          |S|L|A|N|N|t
+                                               |          |T|D|Y|O|O|t
+FEATURE                                        |SECTION   | | | |T|T|e
+-----------------------------------------------|----------|-|-|-|-|-|--
+                                               |          | | | | | |
+RECEIVER-SMTP:                                 |          | | | | | |
+  Implement VRFY                               |5.2.3     |x| | | | |
+  Implement EXPN                               |5.2.3     | |x| | | |
+    EXPN, VRFY configurable                    |5.2.3     | | |x| | |
+  Implement SEND, SOML, SAML                   |5.2.4     | | |x| | |
+  Verify HELO parameter                        |5.2.5     | | |x| | |
+    Refuse message with bad HELO               |5.2.5     | | | | |x|
+  Accept explicit src-route syntax in env.     |5.2.6     |x| | | | |
+  Support "postmaster"                         |5.2.7     |x| | | | |
+  Process RCPT when received (except lists)    |5.2.7     | | |x| | |
+      Long delay of RCPT responses             |5.2.7     | | | | |x|
+                                               |          | | | | | |
+  Add Received: line                           |5.2.8     |x| | | | |
+      Received: line include domain literal    |5.2.8     | |x| | | |
+  Change previous Received: line               |5.2.8     | | | | |x|
+  Pass Return-Path info (final deliv/gwy)      |5.2.8     |x| | | | |
+  Support empty reverse path                   |5.2.9     |x| | | | |
+  Send only official reply codes               |5.2.10    | |x| | | |
+  Send text from RFC-821 when appropriate      |5.2.10    | |x| | | |
+  Delete "." for transparency                  |5.2.11    |x| | | | |
+  Accept and recognize self domain literal(s)  |5.2.17    |x| | | | |
+                                               |          | | | | | |
+  Error message about error message            |5.3.1     | | | | |x|
+  Keep pending listen on SMTP port             |5.3.1.2   | |x| | | |
+  Provide limit on recv concurrency            |5.3.1.2   | | |x| | |
+  Wait at least 5 mins for next sender cmd     |5.3.2     | |x| | | |
+  Avoidable delivery failure after "250 OK"    |5.3.3     | | | | |x|
+  Send error notification msg after accept     |5.3.3     |x| | | | |
+    Send using null return path                |5.3.3     |x| | | | |
+    Send to envelope return path               |5.3.3     | |x| | | |
+    Send to null address                       |5.3.3     | | | | |x|
+    Strip off explicit src route               |5.3.3     | |x| | | |
+  Minimize acceptance delay (RFC-1047)         |5.3.3     |x| | | | |
+-----------------------------------------------|----------|-|-|-|-|-|--
+
+
+
+Internet Engineering Task Force                                [Page 69]
+
+
+
+
+RFC1123                  MAIL -- SMTP & RFC-822             October 1989
+
+
+                                               |          | | | | | |
+SENDER-SMTP:                                   |          | | | | | |
+  Canonicalized domain names in MAIL, RCPT     |5.2.2     |x| | | | |
+  Implement SEND, SOML, SAML                   |5.2.4     | | |x| | |
+  Send valid principal host name in HELO       |5.2.5     |x| | | | |
+  Send explicit source route in RCPT TO:       |5.2.6     | | | |x| |
+  Use only reply code to determine action      |5.2.10    |x| | | | |
+  Use only high digit of reply code when poss. |5.2.10    | |x| | | |
+  Add "." for transparency                     |5.2.11    |x| | | | |
+                                               |          | | | | | |
+  Retry messages after soft failure            |5.3.1.1   |x| | | | |
+    Delay before retry                         |5.3.1.1   |x| | | | |
+    Configurable retry parameters              |5.3.1.1   |x| | | | |
+    Retry once per each queued dest host       |5.3.1.1   | |x| | | |
+  Multiple RCPT's for same DATA                |5.3.1.1   | |x| | | |
+  Support multiple concurrent transactions     |5.3.1.1   | | |x| | |
+    Provide limit on concurrency               |5.3.1.1   | |x| | | |
+                                               |          | | | | | |
+  Timeouts on all activities                   |5.3.1     |x| | | | |
+    Per-command timeouts                       |5.3.2     | |x| | | |
+    Timeouts easily reconfigurable             |5.3.2     | |x| | | |
+    Recommended times                          |5.3.2     | |x| | | |
+  Try alternate addr's in order                |5.3.4     |x| | | | |
+    Configurable limit on alternate tries      |5.3.4     | | |x| | |
+    Try at least two alternates                |5.3.4     | |x| | | |
+  Load-split across equal MX alternates        |5.3.4     | |x| | | |
+  Use the Domain Name System                   |5.3.5     |x| | | | |
+    Support MX records                         |5.3.5     |x| | | | |
+    Use WKS records in MX processing           |5.2.12    | | | |x| |
+-----------------------------------------------|----------|-|-|-|-|-|--
+                                               |          | | | | | |
+MAIL FORWARDING:                               |          | | | | | |
+  Alter existing header field(s)               |5.2.6     | | | |x| |
+  Implement relay function: 821/section 3.6    |5.2.6     | | |x| | |
+    If not, deliver to RHS domain              |5.2.6     | |x| | | |
+  Interpret 'local-part' of addr               |5.2.16    | | | | |x|
+                                               |          | | | | | |
+MAILING LISTS AND ALIASES                      |          | | | | | |
+  Support both                                 |5.3.6     | |x| | | |
+  Report mail list error to local admin.       |5.3.6     |x| | | | |
+                                               |          | | | | | |
+MAIL GATEWAYS:                                 |          | | | | | |
+  Embed foreign mail route in local-part       |5.2.16    | | |x| | |
+  Rewrite header fields when necessary         |5.3.7     | | |x| | |
+  Prepend Received: line                       |5.3.7     |x| | | | |
+  Change existing Received: line               |5.3.7     | | | | |x|
+  Accept full RFC-822 on Internet side         |5.3.7     | |x| | | |
+  Act on RFC-822 explicit source route         |5.3.7     | | |x| | |
+
+
+
+Internet Engineering Task Force                                [Page 70]
+
+
+
+
+RFC1123                  MAIL -- SMTP & RFC-822             October 1989
+
+
+  Send only valid RFC-822 on Internet side     |5.3.7     |x| | | | |
+  Deliver error msgs to envelope addr          |5.3.7     | |x| | | |
+  Set env return path from err return addr     |5.3.7     | |x| | | |
+                                               |          | | | | | |
+USER AGENT -- RFC-822                          |          | | | | | |
+  Allow user to enter <route> address          |5.2.6     | | | |x| |
+  Support RFC-1049 Content Type field          |5.2.13    | | |x| | |
+  Use 4-digit years                            |5.2.14    | |x| | | |
+  Generate numeric timezones                   |5.2.14    | |x| | | |
+  Accept all timezones                         |5.2.14    |x| | | | |
+  Use non-num timezones from RFC-822           |5.2.14    |x| | | | |
+  Omit phrase before route-addr                |5.2.15    | | |x| | |
+  Accept and parse dot.dec. domain literals    |5.2.17    |x| | | | |
+  Accept all RFC-822 address formats           |5.2.18    |x| | | | |
+  Generate invalid RFC-822 address format      |5.2.18    | | | | |x|
+  Fully-qualified domain names in header       |5.2.18    |x| | | | |
+  Create explicit src route in header          |5.2.19    | | | |x| |
+  Accept explicit src route in header          |5.2.19    |x| | | | |
+                                               |          | | | | | |
+Send/recv at least 64KB messages               |5.3.8     |x| | | | |
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Internet Engineering Task Force                                [Page 71]
+
+
+
+
+RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989
+
+
+6. SUPPORT SERVICES
+
+   6.1 DOMAIN NAME TRANSLATION
+
+      6.1.1 INTRODUCTION
+
+         Every host MUST implement a resolver for the Domain Name System
+         (DNS), and it MUST implement a mechanism using this DNS
+         resolver to convert host names to IP addresses and vice-versa
+         [DNS:1, DNS:2].
+
+         In addition to the DNS, a host MAY also implement a host name
+         translation mechanism that searches a local Internet host
+         table.  See Section 6.1.3.8 for more information on this
+         option.
+
+         DISCUSSION:
+              Internet host name translation was originally performed by
+              searching local copies of a table of all hosts.  This
+              table became too large to update and distribute in a
+              timely manner and too large to fit into many hosts, so the
+              DNS was invented.
+
+              The DNS creates a distributed database used primarily for
+              the translation between host names and host addresses.
+              Implementation of DNS software is required.  The DNS
+              consists of two logically distinct parts: name servers and
+              resolvers (although implementations often combine these
+              two logical parts in the interest of efficiency) [DNS:2].
+
+              Domain name servers store authoritative data about certain
+              sections of the database and answer queries about the
+              data.  Domain resolvers query domain name servers for data
+              on behalf of user processes.  Every host therefore needs a
+              DNS resolver; some host machines will also need to run
+              domain name servers.  Since no name server has complete
+              information, in general it is necessary to obtain
+              information from more than one name server to resolve a
+              query.
+
+      6.1.2  PROTOCOL WALK-THROUGH
+
+         An implementor must study references [DNS:1] and [DNS:2]
+         carefully.  They provide a thorough description of the theory,
+         protocol, and implementation of the domain name system, and
+         reflect several years of experience.
+
+
+
+
+
+Internet Engineering Task Force                                [Page 72]
+
+
+
+
+RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989
+
+
+         6.1.2.1  Resource Records with Zero TTL: RFC-1035 Section 3.2.1
+
+            All DNS name servers and resolvers MUST properly handle RRs
+            with a zero TTL: return the RR to the client but do not
+            cache it.
+
+            DISCUSSION:
+                 Zero TTL values are interpreted to mean that the RR can
+                 only be used for the transaction in progress, and
+                 should not be cached; they are useful for extremely
+                 volatile data.
+
+         6.1.2.2  QCLASS Values: RFC-1035 Section 3.2.5
+
+            A query with "QCLASS=*" SHOULD NOT be used unless the
+            requestor is seeking data from more than one class.  In
+            particular, if the requestor is only interested in Internet
+            data types, QCLASS=IN MUST be used.
+
+         6.1.2.3  Unused Fields: RFC-1035 Section 4.1.1
+
+            Unused fields in a query or response message MUST be zero.
+
+         6.1.2.4  Compression: RFC-1035 Section 4.1.4
+
+            Name servers MUST use compression in responses.
+
+            DISCUSSION:
+                 Compression is essential to avoid overflowing UDP
+                 datagrams; see Section 6.1.3.2.
+
+         6.1.2.5  Misusing Configuration Info: RFC-1035 Section 6.1.2
+
+            Recursive name servers and full-service resolvers generally
+            have some configuration information containing hints about
+            the location of root or local name servers.  An
+            implementation MUST NOT include any of these hints in a
+            response.
+
+            DISCUSSION:
+                 Many implementors have found it convenient to store
+                 these hints as if they were cached data, but some
+                 neglected to ensure that this "cached data" was not
+                 included in responses.  This has caused serious
+                 problems in the Internet when the hints were obsolete
+                 or incorrect.
+
+
+
+
+
+Internet Engineering Task Force                                [Page 73]
+
+
+
+
+RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989
+
+
+      6.1.3  SPECIFIC ISSUES
+
+         6.1.3.1  Resolver Implementation
+
+            A name resolver SHOULD be able to multiplex concurrent
+            requests if the host supports concurrent processes.
+
+            In implementing a DNS resolver, one of two different models
+            MAY optionally be chosen: a full-service resolver, or a stub
+            resolver.
+
+
+            (A)  Full-Service Resolver
+
+                 A full-service resolver is a complete implementation of
+                 the resolver service, and is capable of dealing with
+                 communication failures, failure of individual name
+                 servers, location of the proper name server for a given
+                 name, etc.  It must satisfy the following requirements:
+
+                 o    The resolver MUST implement a local caching
+                      function to avoid repeated remote access for
+                      identical requests, and MUST time out information
+                      in the cache.
+
+                 o    The resolver SHOULD be configurable with start-up
+                      information pointing to multiple root name servers
+                      and multiple name servers for the local domain.
+                      This insures that the resolver will be able to
+                      access the whole name space in normal cases, and
+                      will be able to access local domain information
+                      should the local network become disconnected from
+                      the rest of the Internet.
+
+
+            (B)  Stub Resolver
+
+                 A "stub resolver" relies on the services of a recursive
+                 name server on the connected network or a "nearby"
+                 network.  This scheme allows the host to pass on the
+                 burden of the resolver function to a name server on
+                 another host.  This model is often essential for less
+                 capable hosts, such as PCs, and is also recommended
+                 when the host is one of several workstations on a local
+                 network, because it allows all of the workstations to
+                 share the cache of the recursive name server and hence
+                 reduce the number of domain requests exported by the
+                 local network.
+
+
+
+Internet Engineering Task Force                                [Page 74]
+
+
+
+
+RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989
+
+
+                 At a minimum, the stub resolver MUST be capable of
+                 directing its requests to redundant recursive name
+                 servers.  Note that recursive name servers are allowed
+                 to restrict the sources of requests that they will
+                 honor, so the host administrator must verify that the
+                 service will be provided.  Stub resolvers MAY implement
+                 caching if they choose, but if so, MUST timeout cached
+                 information.
+
+
+         6.1.3.2  Transport Protocols
+
+            DNS resolvers and recursive servers MUST support UDP, and
+            SHOULD support TCP, for sending (non-zone-transfer) queries.
+            Specifically, a DNS resolver or server that is sending a
+            non-zone-transfer query MUST send a UDP query first.  If the
+            Answer section of the response is truncated and if the
+            requester supports TCP, it SHOULD try the query again using
+            TCP.
+
+            DNS servers MUST be able to service UDP queries and SHOULD
+            be able to service TCP queries.  A name server MAY limit the
+            resources it devotes to TCP queries, but it SHOULD NOT
+            refuse to service a TCP query just because it would have
+            succeeded with UDP.
+
+            Truncated responses MUST NOT be saved (cached) and later
+            used in such a way that the fact that they are truncated is
+            lost.
+
+            DISCUSSION:
+                 UDP is preferred over TCP for queries because UDP
+                 queries have much lower overhead, both in packet count
+                 and in connection state.  The use of UDP is essential
+                 for heavily-loaded servers, especially the root
+                 servers.  UDP also offers additional robustness, since
+                 a resolver can attempt several UDP queries to different
+                 servers for the cost of a single TCP query.
+
+                 It is possible for a DNS response to be truncated,
+                 although this is a very rare occurrence in the present
+                 Internet DNS.  Practically speaking, truncation cannot
+                 be predicted, since it is data-dependent.  The
+                 dependencies include the number of RRs in the answer,
+                 the size of each RR, and the savings in space realized
+                 by the name compression algorithm.  As a rule of thumb,
+                 truncation in NS and MX lists should not occur for
+                 answers containing 15 or fewer RRs.
+
+
+
+Internet Engineering Task Force                                [Page 75]
+
+
+
+
+RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989
+
+
+                 Whether it is possible to use a truncated answer
+                 depends on the application.  A mailer must not use a
+                 truncated MX response, since this could lead to mail
+                 loops.
+
+                 Responsible practices can make UDP suffice in the vast
+                 majority of cases.  Name servers must use compression
+                 in responses.  Resolvers must differentiate truncation
+                 of the Additional section of a response (which only
+                 loses extra information) from truncation of the Answer
+                 section (which for MX records renders the response
+                 unusable by mailers).  Database administrators should
+                 list only a reasonable number of primary names in lists
+                 of name servers, MX alternatives, etc.
+
+                 However, it is also clear that some new DNS record
+                 types defined in the future will contain information
+                 exceeding the 512 byte limit that applies to UDP, and
+                 hence will require TCP.  Thus, resolvers and name
+                 servers should implement TCP services as a backup to
+                 UDP today, with the knowledge that they will require
+                 the TCP service in the future.
+
+            By private agreement, name servers and resolvers MAY arrange
+            to use TCP for all traffic between themselves.  TCP MUST be
+            used for zone transfers.
+
+            A DNS server MUST have sufficient internal concurrency that
+            it can continue to process UDP queries while awaiting a
+            response or performing a zone transfer on an open TCP
+            connection [DNS:2].
+
+            A server MAY support a UDP query that is delivered using an
+            IP broadcast or multicast address.  However, the Recursion
+            Desired bit MUST NOT be set in a query that is multicast,
+            and MUST be ignored by name servers receiving queries via a
+            broadcast or multicast address.  A host that sends broadcast
+            or multicast DNS queries SHOULD send them only as occasional
+            probes, caching the IP address(es) it obtains from the
+            response(s) so it can normally send unicast queries.
+
+            DISCUSSION:
+                 Broadcast or (especially) IP multicast can provide a
+                 way to locate nearby name servers without knowing their
+                 IP addresses in advance.  However, general broadcasting
+                 of recursive queries can result in excessive and
+                 unnecessary load on both network and servers.
+
+
+
+
+Internet Engineering Task Force                                [Page 76]
+
+
+
+
+RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989
+
+
+         6.1.3.3  Efficient Resource Usage
+
+            The following requirements on servers and resolvers are very
+            important to the health of the Internet as a whole,
+            particularly when DNS services are invoked repeatedly by
+            higher level automatic servers, such as mailers.
+
+            (1)  The resolver MUST implement retransmission controls to
+                 insure that it does not waste communication bandwidth,
+                 and MUST impose finite bounds on the resources consumed
+                 to respond to a single request.  See [DNS:2] pages 43-
+                 44 for specific recommendations.
+
+            (2)  After a query has been retransmitted several times
+                 without a response, an implementation MUST give up and
+                 return a soft error to the application.
+
+            (3)  All DNS name servers and resolvers SHOULD cache
+                 temporary failures, with a timeout period of the order
+                 of minutes.
+
+                 DISCUSSION:
+                      This will prevent applications that immediately
+                      retry soft failures (in violation of Section 2.2
+                      of this document) from generating excessive DNS
+                      traffic.
+
+            (4)  All DNS name servers and resolvers SHOULD cache
+                 negative responses that indicate the specified name, or
+                 data of the specified type, does not exist, as
+                 described in [DNS:2].
+
+            (5)  When a DNS server or resolver retries a UDP query, the
+                 retry interval SHOULD be constrained by an exponential
+                 backoff algorithm, and SHOULD also have upper and lower
+                 bounds.
+
+                 IMPLEMENTATION:
+                      A measured RTT and variance (if available) should
+                      be used to calculate an initial retransmission
+                      interval.  If this information is not available, a
+                      default of no less than 5 seconds should be used.
+                      Implementations may limit the retransmission
+                      interval, but this limit must exceed twice the
+                      Internet maximum segment lifetime plus service
+                      delay at the name server.
+
+            (6)  When a resolver or server receives a Source Quench for
+
+
+
+Internet Engineering Task Force                                [Page 77]
+
+
+
+
+RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989
+
+
+                 a query it has issued, it SHOULD take steps to reduce
+                 the rate of querying that server in the near future.  A
+                 server MAY ignore a Source Quench that it receives as
+                 the result of sending a response datagram.
+
+                 IMPLEMENTATION:
+                      One recommended action to reduce the rate is to
+                      send the next query attempt to an alternate
+                      server, if there is one available.  Another is to
+                      backoff the retry interval for the same server.
+
+
+         6.1.3.4  Multihomed Hosts
+
+            When the host name-to-address function encounters a host
+            with multiple addresses, it SHOULD rank or sort the
+            addresses using knowledge of the immediately connected
+            network number(s) and any other applicable performance or
+            history information.
+
+            DISCUSSION:
+                 The different addresses of a multihomed host generally
+                 imply different Internet paths, and some paths may be
+                 preferable to others in performance, reliability, or
+                 administrative restrictions.  There is no general way
+                 for the domain system to determine the best path.  A
+                 recommended approach is to base this decision on local
+                 configuration information set by the system
+                 administrator.
+
+            IMPLEMENTATION:
+                 The following scheme has been used successfully:
+
+                 (a)  Incorporate into the host configuration data a
+                      Network-Preference List, that is simply a list of
+                      networks in preferred order.  This list may be
+                      empty if there is no preference.
+
+                 (b)  When a host name is mapped into a list of IP
+                      addresses, these addresses should be sorted by
+                      network number, into the same order as the
+                      corresponding networks in the Network-Preference
+                      List.  IP addresses whose networks do not appear
+                      in the Network-Preference List should be placed at
+                      the end of the list.
+
+
+
+
+
+
+Internet Engineering Task Force                                [Page 78]
+
+
+
+
+RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989
+
+
+         6.1.3.5  Extensibility
+
+            DNS software MUST support all well-known, class-independent
+            formats [DNS:2], and SHOULD be written to minimize the
+            trauma associated with the introduction of new well-known
+            types and local experimentation with non-standard types.
+
+            DISCUSSION:
+                 The data types and classes used by the DNS are
+                 extensible, and thus new types will be added and old
+                 types deleted or redefined.  Introduction of new data
+                 types ought to be dependent only upon the rules for
+                 compression of domain names inside DNS messages, and
+                 the translation between printable (i.e., master file)
+                 and internal formats for Resource Records (RRs).
+
+                 Compression relies on knowledge of the format of data
+                 inside a particular RR.  Hence compression must only be
+                 used for the contents of well-known, class-independent
+                 RRs, and must never be used for class-specific RRs or
+                 RR types that are not well-known.  The owner name of an
+                 RR is always eligible for compression.
+
+                 A name server may acquire, via zone transfer, RRs that
+                 the server doesn't know how to convert to printable
+                 format.  A resolver can receive similar information as
+                 the result of queries.  For proper operation, this data
+                 must be preserved, and hence the implication is that
+                 DNS software cannot use textual formats for internal
+                 storage.
+
+                 The DNS defines domain name syntax very generally -- a
+                 string of labels each containing up to 63 8-bit octets,
+                 separated by dots, and with a maximum total of 255
+                 octets.  Particular applications of the DNS are
+                 permitted to further constrain the syntax of the domain
+                 names they use, although the DNS deployment has led to
+                 some applications allowing more general names.  In
+                 particular, Section 2.1 of this document liberalizes
+                 slightly the syntax of a legal Internet host name that
+                 was defined in RFC-952 [DNS:4].
+
+         6.1.3.6  Status of RR Types
+
+            Name servers MUST be able to load all RR types except MD and
+            MF from configuration files.  The MD and MF types are
+            obsolete and MUST NOT be implemented; in particular, name
+            servers MUST NOT load these types from configuration files.
+
+
+
+Internet Engineering Task Force                                [Page 79]
+
+
+
+
+RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989
+
+
+            DISCUSSION:
+                 The RR types MB, MG, MR, NULL, MINFO and RP are
+                 considered experimental, and applications that use the
+                 DNS cannot expect these RR types to be supported by
+                 most domains.  Furthermore these types are subject to
+                 redefinition.
+
+                 The TXT and WKS RR types have not been widely used by
+                 Internet sites; as a result, an application cannot rely
+                 on the the existence of a TXT or WKS RR in most
+                 domains.
+
+         6.1.3.7  Robustness
+
+            DNS software may need to operate in environments where the
+            root servers or other servers are unavailable due to network
+            connectivity or other problems.  In this situation, DNS name
+            servers and resolvers MUST continue to provide service for
+            the reachable part of the name space, while giving temporary
+            failures for the rest.
+
+            DISCUSSION:
+                 Although the DNS is meant to be used primarily in the
+                 connected Internet, it should be possible to use the
+                 system in networks which are unconnected to the
+                 Internet.  Hence implementations must not depend on
+                 access to root servers before providing service for
+                 local names.
+
+         6.1.3.8  Local Host Table
+
+            DISCUSSION:
+                 A host may use a local host table as a backup or
+                 supplement to the DNS.  This raises the question of
+                 which takes precedence, the DNS or the host table; the
+                 most flexible approach would make this a configuration
+                 option.
+
+                 Typically, the contents of such a supplementary host
+                 table will be determined locally by the site.  However,
+                 a publically-available table of Internet hosts is
+                 maintained by the DDN Network Information Center (DDN
+                 NIC), with a format documented in [DNS:4].  This table
+                 can be retrieved from the DDN NIC using a protocol
+                 described in [DNS:5].  It must be noted that this table
+                 contains only a small fraction of all Internet hosts.
+                 Hosts using this protocol to retrieve the DDN NIC host
+                 table should use the VERSION command to check if the
+
+
+
+Internet Engineering Task Force                                [Page 80]
+
+
+
+
+RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989
+
+
+                 table has changed before requesting the entire table
+                 with the ALL command.  The VERSION identifier should be
+                 treated as an arbitrary string and tested only for
+                 equality; no numerical sequence may be assumed.
+
+                 The DDN NIC host table includes administrative
+                 information that is not needed for host operation and
+                 is therefore not currently included in the DNS
+                 database; examples include network and gateway entries.
+                 However, much of this additional information will be
+                 added to the DNS in the future.  Conversely, the DNS
+                 provides essential services (in particular, MX records)
+                 that are not available from the DDN NIC host table.
+
+      6.1.4  DNS USER INTERFACE
+
+         6.1.4.1  DNS Administration
+
+            This document is concerned with design and implementation
+            issues in host software, not with administrative or
+            operational issues.  However, administrative issues are of
+            particular importance in the DNS, since errors in particular
+            segments of this large distributed database can cause poor
+            or erroneous performance for many sites.  These issues are
+            discussed in [DNS:6] and [DNS:7].
+
+         6.1.4.2  DNS User Interface
+
+            Hosts MUST provide an interface to the DNS for all
+            application programs running on the host.  This interface
+            will typically direct requests to a system process to
+            perform the resolver function [DNS:1, 6.1:2].
+
+            At a minimum, the basic interface MUST support a request for
+            all information of a specific type and class associated with
+            a specific name, and it MUST return either all of the
+            requested information, a hard error code, or a soft error
+            indication.  When there is no error, the basic interface
+            returns the complete response information without
+            modification, deletion, or ordering, so that the basic
+            interface will not need to be changed to accommodate new
+            data types.
+
+            DISCUSSION:
+                 The soft error indication is an essential part of the
+                 interface, since it may not always be possible to
+                 access particular information from the DNS; see Section
+                 6.1.3.3.
+
+
+
+Internet Engineering Task Force                                [Page 81]
+
+
+
+
+RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989
+
+
+            A host MAY provide other DNS interfaces tailored to
+            particular functions, transforming the raw domain data into
+            formats more suited to these functions.  In particular, a
+            host MUST provide a DNS interface to facilitate translation
+            between host addresses and host names.
+
+         6.1.4.3 Interface Abbreviation Facilities
+
+            User interfaces MAY provide a method for users to enter
+            abbreviations for commonly-used names.  Although the
+            definition of such methods is outside of the scope of the
+            DNS specification, certain rules are necessary to insure
+            that these methods allow access to the entire DNS name space
+            and to prevent excessive use of Internet resources.
+
+            If an abbreviation method is provided, then:
+
+            (a)  There MUST be some convention for denoting that a name
+                 is already complete, so that the abbreviation method(s)
+                 are suppressed.  A trailing dot is the usual method.
+
+            (b)  Abbreviation expansion MUST be done exactly once, and
+                 MUST be done in the context in which the name was
+                 entered.
+
+
+            DISCUSSION:
+                 For example, if an abbreviation is used in a mail
+                 program for a destination, the abbreviation should be
+                 expanded into a full domain name and stored in the
+                 queued message with an indication that it is already
+                 complete.  Otherwise, the abbreviation might be
+                 expanded with a mail system search list, not the
+                 user's, or a name could grow due to repeated
+                 canonicalizations attempts interacting with wildcards.
+
+            The two most common abbreviation methods are:
+
+            (1)  Interface-level aliases
+
+                 Interface-level aliases are conceptually implemented as
+                 a list of alias/domain name pairs. The list can be
+                 per-user or per-host, and separate lists can be
+                 associated with different functions, e.g. one list for
+                 host name-to-address translation, and a different list
+                 for mail domains.  When the user enters a name, the
+                 interface attempts to match the name to the alias
+                 component of a list entry, and if a matching entry can
+
+
+
+Internet Engineering Task Force                                [Page 82]
+
+
+
+
+RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989
+
+
+                 be found, the name is replaced by the domain name found
+                 in the pair.
+
+                 Note that interface-level aliases and CNAMEs are
+                 completely separate mechanisms; interface-level aliases
+                 are a local matter while CNAMEs are an Internet-wide
+                 aliasing mechanism which is a required part of any DNS
+                 implementation.
+
+            (2)  Search Lists
+
+                 A search list is conceptually implemented as an ordered
+                 list of domain names.  When the user enters a name, the
+                 domain names in the search list are used as suffixes to
+                 the user-supplied name, one by one, until a domain name
+                 with the desired associated data is found, or the
+                 search list is exhausted.  Search lists often contain
+                 the name of the local host's parent domain or other
+                 ancestor domains.  Search lists are often per-user or
+                 per-process.
+
+                 It SHOULD be possible for an administrator to disable a
+                 DNS search-list facility.  Administrative denial may be
+                 warranted in some cases, to prevent abuse of the DNS.
+
+                 There is danger that a search-list mechanism will
+                 generate excessive queries to the root servers while
+                 testing whether user input is a complete domain name,
+                 lacking a final period to mark it as complete.  A
+                 search-list mechanism MUST have one of, and SHOULD have
+                 both of, the following two provisions to prevent this:
+
+                 (a)  The local resolver/name server can implement
+                      caching  of negative responses (see Section
+                      6.1.3.3).
+
+                 (b)  The search list expander can require two or more
+                      interior dots in a generated domain name before it
+                      tries using the name in a query to non-local
+                      domain servers, such as the root.
+
+                 DISCUSSION:
+                      The intent of this requirement is to avoid
+                      excessive delay for the user as the search list is
+                      tested, and more importantly to prevent excessive
+                      traffic to the root and other high-level servers.
+                      For example, if the user supplied a name "X" and
+                      the search list contained the root as a component,
+
+
+
+Internet Engineering Task Force                                [Page 83]
+
+
+
+
+RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989
+
+
+                      a query would have to consult a root server before
+                      the next search list alternative could be tried.
+                      The resulting load seen by the root servers and
+                      gateways near the root would be multiplied by the
+                      number of hosts in the Internet.
+
+                      The negative caching alternative limits the effect
+                      to the first time a name is used.  The interior
+                      dot rule is simpler to implement but can prevent
+                      easy use of some top-level names.
+
+
+      6.1.5  DOMAIN NAME SYSTEM REQUIREMENTS SUMMARY
+
+                                               |           | | | |S| |
+                                               |           | | | |H| |F
+                                               |           | | | |O|M|o
+                                               |           | |S| |U|U|o
+                                               |           | |H| |L|S|t
+                                               |           |M|O| |D|T|n
+                                               |           |U|U|M| | |o
+                                               |           |S|L|A|N|N|t
+                                               |           |T|D|Y|O|O|t
+FEATURE                                        |SECTION    | | | |T|T|e
+-----------------------------------------------|-----------|-|-|-|-|-|--
+GENERAL ISSUES                                 |           | | | | | |
+                                               |           | | | | | |
+Implement DNS name-to-address conversion       |6.1.1      |x| | | | |
+Implement DNS address-to-name conversion       |6.1.1      |x| | | | |
+Support conversions using host table           |6.1.1      | | |x| | |
+Properly handle RR with zero TTL               |6.1.2.1    |x| | | | |
+Use QCLASS=* unnecessarily                     |6.1.2.2    | |x| | | |
+  Use QCLASS=IN for Internet class             |6.1.2.2    |x| | | | |
+Unused fields zero                             |6.1.2.3    |x| | | | |
+Use compression in responses                   |6.1.2.4    |x| | | | |
+                                               |           | | | | | |
+Include config info in responses               |6.1.2.5    | | | | |x|
+Support all well-known, class-indep. types     |6.1.3.5    |x| | | | |
+Easily expand type list                        |6.1.3.5    | |x| | | |
+Load all RR types (except MD and MF)           |6.1.3.6    |x| | | | |
+Load MD or MF type                             |6.1.3.6    | | | | |x|
+Operate when root servers, etc. unavailable    |6.1.3.7    |x| | | | |
+-----------------------------------------------|-----------|-|-|-|-|-|--
+RESOLVER ISSUES:                               |           | | | | | |
+                                               |           | | | | | |
+Resolver support multiple concurrent requests  |6.1.3.1    | |x| | | |
+Full-service resolver:                         |6.1.3.1    | | |x| | |
+  Local caching                                |6.1.3.1    |x| | | | |
+
+
+
+Internet Engineering Task Force                                [Page 84]
+
+
+
+
+RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989
+
+
+  Information in local cache times out         |6.1.3.1    |x| | | | |
+  Configurable with starting info              |6.1.3.1    | |x| | | |
+Stub resolver:                                 |6.1.3.1    | | |x| | |
+  Use redundant recursive name servers         |6.1.3.1    |x| | | | |
+  Local caching                                |6.1.3.1    | | |x| | |
+  Information in local cache times out         |6.1.3.1    |x| | | | |
+Support for remote multi-homed hosts:          |           | | | | | |
+  Sort multiple addresses by preference list   |6.1.3.4    | |x| | | |
+                                               |           | | | | | |
+-----------------------------------------------|-----------|-|-|-|-|-|--
+TRANSPORT PROTOCOLS:                           |           | | | | | |
+                                               |           | | | | | |
+Support UDP queries                            |6.1.3.2    |x| | | | |
+Support TCP queries                            |6.1.3.2    | |x| | | |
+  Send query using UDP first                   |6.1.3.2    |x| | | | |1
+  Try TCP if UDP answers are truncated         |6.1.3.2    | |x| | | |
+Name server limit TCP query resources          |6.1.3.2    | | |x| | |
+  Punish unnecessary TCP query                 |6.1.3.2    | | | |x| |
+Use truncated data as if it were not           |6.1.3.2    | | | | |x|
+Private agreement to use only TCP              |6.1.3.2    | | |x| | |
+Use TCP for zone transfers                     |6.1.3.2    |x| | | | |
+TCP usage not block UDP queries                |6.1.3.2    |x| | | | |
+Support broadcast or multicast queries         |6.1.3.2    | | |x| | |
+  RD bit set in query                          |6.1.3.2    | | | | |x|
+  RD bit ignored by server is b'cast/m'cast    |6.1.3.2    |x| | | | |
+  Send only as occasional probe for addr's     |6.1.3.2    | |x| | | |
+-----------------------------------------------|-----------|-|-|-|-|-|--
+RESOURCE USAGE:                                |           | | | | | |
+                                               |           | | | | | |
+Transmission controls, per [DNS:2]             |6.1.3.3    |x| | | | |
+  Finite bounds per request                    |6.1.3.3    |x| | | | |
+Failure after retries => soft error            |6.1.3.3    |x| | | | |
+Cache temporary failures                       |6.1.3.3    | |x| | | |
+Cache negative responses                       |6.1.3.3    | |x| | | |
+Retries use exponential backoff                |6.1.3.3    | |x| | | |
+  Upper, lower bounds                          |6.1.3.3    | |x| | | |
+Client handle Source Quench                    |6.1.3.3    | |x| | | |
+Server ignore Source Quench                    |6.1.3.3    | | |x| | |
+-----------------------------------------------|-----------|-|-|-|-|-|--
+USER INTERFACE:                                |           | | | | | |
+                                               |           | | | | | |
+All programs have access to DNS interface      |6.1.4.2    |x| | | | |
+Able to request all info for given name        |6.1.4.2    |x| | | | |
+Returns complete info or error                 |6.1.4.2    |x| | | | |
+Special interfaces                             |6.1.4.2    | | |x| | |
+  Name<->Address translation                   |6.1.4.2    |x| | | | |
+                                               |           | | | | | |
+Abbreviation Facilities:                       |6.1.4.3    | | |x| | |
+
+
+
+Internet Engineering Task Force                                [Page 85]
+
+
+
+
+RFC1123               SUPPORT SERVICES -- DOMAINS           October 1989
+
+
+  Convention for complete names                |6.1.4.3    |x| | | | |
+  Conversion exactly once                      |6.1.4.3    |x| | | | |
+  Conversion in proper context                 |6.1.4.3    |x| | | | |
+  Search list:                                 |6.1.4.3    | | |x| | |
+    Administrator can disable                  |6.1.4.3    | |x| | | |
+    Prevention of excessive root queries       |6.1.4.3    |x| | | | |
+      Both methods                             |6.1.4.3    | |x| | | |
+-----------------------------------------------|-----------|-|-|-|-|-|--
+-----------------------------------------------|-----------|-|-|-|-|-|--
+
+1.   Unless there is private agreement between particular resolver and
+     particular server.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Internet Engineering Task Force                                [Page 86]
+
+
+
+
+RFC1123            SUPPORT SERVICES -- INITIALIZATION       October 1989
+
+
+   6.2  HOST INITIALIZATION
+
+      6.2.1  INTRODUCTION
+
+         This section discusses the initialization of host software
+         across a connected network, or more generally across an
+         Internet path.  This is necessary for a diskless host, and may
+         optionally be used for a host with disk drives.  For a diskless
+         host, the initialization process is called "network booting"
+         and is controlled by a bootstrap program located in a boot ROM.
+
+         To initialize a diskless host across the network, there are two
+         distinct phases:
+
+         (1)  Configure the IP layer.
+
+              Diskless machines often have no permanent storage in which
+              to store network configuration information, so that
+              sufficient configuration information must be obtained
+              dynamically to support the loading phase that follows.
+              This information must include at least the IP addresses of
+              the host and of the boot server.  To support booting
+              across a gateway, the address mask and a list of default
+              gateways are also required.
+
+         (2)  Load the host system code.
+
+              During the loading phase, an appropriate file transfer
+              protocol is used to copy the system code across the
+              network from the boot server.
+
+         A host with a disk may perform the first step, dynamic
+         configuration.  This is important for microcomputers, whose
+         floppy disks allow network configuration information to be
+         mistakenly duplicated on more than one host.  Also,
+         installation of new hosts is much simpler if they automatically
+         obtain their configuration information from a central server,
+         saving administrator time and decreasing the probability of
+         mistakes.
+
+      6.2.2  REQUIREMENTS
+
+         6.2.2.1  Dynamic Configuration
+
+            A number of protocol provisions have been made for dynamic
+            configuration.
+
+            o    ICMP Information Request/Reply messages
+
+
+
+Internet Engineering Task Force                                [Page 87]
+
+
+
+
+RFC1123            SUPPORT SERVICES -- INITIALIZATION       October 1989
+
+
+                 This obsolete message pair was designed to allow a host
+                 to find the number of the network it is on.
+                 Unfortunately, it was useful only if the host already
+                 knew the host number part of its IP address,
+                 information that hosts requiring dynamic configuration
+                 seldom had.
+
+            o    Reverse Address Resolution Protocol (RARP) [BOOT:4]
+
+                 RARP is a link-layer protocol for a broadcast medium
+                 that allows a host to find its IP address given its
+                 link layer address.  Unfortunately, RARP does not work
+                 across IP gateways and therefore requires a RARP server
+                 on every network.  In addition, RARP does not provide
+                 any other configuration information.
+
+            o    ICMP Address Mask Request/Reply messages
+
+                 These ICMP messages allow a host to learn the address
+                 mask for a particular network interface.
+
+            o    BOOTP Protocol [BOOT:2]
+
+                 This protocol allows a host to determine the IP
+                 addresses of the local host and the boot server, the
+                 name of an appropriate boot file, and optionally the
+                 address mask and list of default gateways.  To locate a
+                 BOOTP server, the host broadcasts a BOOTP request using
+                 UDP.  Ad hoc gateway extensions have been used to
+                 transmit the BOOTP broadcast through gateways, and in
+                 the future the IP Multicasting facility will provide a
+                 standard mechanism for this purpose.
+
+
+            The suggested approach to dynamic configuration is to use
+            the BOOTP protocol with the extensions defined in "BOOTP
+            Vendor Information Extensions" RFC-1084 [BOOT:3].  RFC-1084
+            defines some important general (not vendor-specific)
+            extensions.  In particular, these extensions allow the
+            address mask to be supplied in BOOTP; we RECOMMEND that the
+            address mask be supplied in this manner.
+
+            DISCUSSION:
+                 Historically, subnetting was defined long after IP, and
+                 so a separate mechanism (ICMP Address Mask messages)
+                 was designed to supply the address mask to a host.
+                 However, the IP address mask and the corresponding IP
+                 address conceptually form a pair, and for operational
+
+
+
+Internet Engineering Task Force                                [Page 88]
+
+
+
+
+RFC1123            SUPPORT SERVICES -- INITIALIZATION       October 1989
+
+
+                 simplicity they ought to be defined at the same time
+                 and by the same mechanism, whether a configuration file
+                 or a dynamic mechanism like BOOTP.
+
+                 Note that BOOTP is not sufficiently general to specify
+                 the configurations of all interfaces of a multihomed
+                 host.  A multihomed host must either use BOOTP
+                 separately for each interface, or configure one
+                 interface using BOOTP to perform the loading, and
+                 perform the complete initialization from a file later.
+
+                 Application layer configuration information is expected
+                 to be obtained from files after loading of the system
+                 code.
+
+         6.2.2.2  Loading Phase
+
+            A suggested approach for the loading phase is to use TFTP
+            [BOOT:1] between the IP addresses established by BOOTP.
+
+            TFTP to a broadcast address SHOULD NOT be used, for reasons
+            explained in Section 4.2.3.4.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Internet Engineering Task Force                                [Page 89]
+
+
+
+
+RFC1123              SUPPORT SERVICES -- MANAGEMENT         October 1989
+
+
+   6.3  REMOTE MANAGEMENT
+
+      6.3.1  INTRODUCTION
+
+         The Internet community has recently put considerable effort
+         into the development of network management protocols.  The
+         result has been a two-pronged approach [MGT:1, MGT:6]:  the
+         Simple Network Management Protocol (SNMP) [MGT:4] and the
+         Common Management Information Protocol over TCP (CMOT) [MGT:5].
+
+         In order to be managed using SNMP or CMOT, a host will need to
+         implement an appropriate management agent.  An Internet host
+         SHOULD include an agent for either SNMP or CMOT.
+
+         Both SNMP and CMOT operate on a Management Information Base
+         (MIB) that defines a collection of management values.  By
+         reading and setting these values, a remote application may
+         query and change the state of the managed system.
+
+         A standard MIB [MGT:3] has been defined for use by both
+         management protocols, using data types defined by the Structure
+         of Management Information (SMI) defined in [MGT:2].  Additional
+         MIB variables can be introduced under the "enterprises" and
+         "experimental" subtrees of the MIB naming space [MGT:2].
+
+         Every protocol module in the host SHOULD implement the relevant
+         MIB variables.  A host SHOULD implement the MIB variables as
+         defined in the most recent standard MIB, and MAY implement
+         other MIB variables when appropriate and useful.
+
+      6.3.2  PROTOCOL WALK-THROUGH
+
+         The MIB is intended to cover both hosts and gateways, although
+         there may be detailed differences in MIB application to the two
+         cases.  This section contains the appropriate interpretation of
+         the MIB for hosts.  It is likely that later versions of the MIB
+         will include more entries for host management.
+
+         A managed host must implement the following groups of MIB
+         object definitions: System, Interfaces, Address Translation,
+         IP, ICMP, TCP, and UDP.
+
+         The following specific interpretations apply to hosts:
+
+         o    ipInHdrErrors
+
+              Note that the error "time-to-live exceeded" can occur in a
+              host only when it is forwarding a source-routed datagram.
+
+
+
+Internet Engineering Task Force                                [Page 90]
+
+
+
+
+RFC1123              SUPPORT SERVICES -- MANAGEMENT         October 1989
+
+
+         o    ipOutNoRoutes
+
+              This object counts datagrams discarded because no route
+              can be found.  This may happen in a host if all the
+              default gateways in the host's configuration are down.
+
+         o    ipFragOKs, ipFragFails, ipFragCreates
+
+              A host that does not implement intentional fragmentation
+              (see "Fragmentation" section of [INTRO:1]) MUST return the
+              value zero for these three objects.
+
+         o    icmpOutRedirects
+
+              For a host, this object MUST always be zero, since hosts
+              do not send Redirects.
+
+         o    icmpOutAddrMaskReps
+
+              For a host, this object MUST always be zero, unless the
+              host is an authoritative source of address mask
+              information.
+
+         o    ipAddrTable
+
+              For a host, the "IP Address Table" object is effectively a
+              table of logical interfaces.
+
+         o    ipRoutingTable
+
+              For a host, the "IP Routing Table" object is effectively a
+              combination of the host's Routing Cache and the static
+              route table described in "Routing Outbound Datagrams"
+              section of [INTRO:1].
+
+              Within each ipRouteEntry, ipRouteMetric1...4 normally will
+              have no meaning for a host and SHOULD always be -1, while
+              ipRouteType will normally have the value "remote".
+
+              If destinations on the connected network do not appear in
+              the Route Cache (see "Routing Outbound Datagrams section
+              of [INTRO:1]), there will be no entries with ipRouteType
+              of "direct".
+
+
+         DISCUSSION:
+              The current MIB does not include Type-of-Service in an
+              ipRouteEntry, but a future revision is expected to make
+
+
+
+Internet Engineering Task Force                                [Page 91]
+
+
+
+
+RFC1123              SUPPORT SERVICES -- MANAGEMENT         October 1989
+
+
+              this addition.
+
+              We also expect the MIB to be expanded to allow the remote
+              management of applications (e.g., the ability to partially
+              reconfigure mail systems).  Network service applications
+              such as mail systems should therefore be written with the
+              "hooks" for remote management.
+
+      6.3.3  MANAGEMENT REQUIREMENTS SUMMARY
+
+                                               |           | | | |S| |
+                                               |           | | | |H| |F
+                                               |           | | | |O|M|o
+                                               |           | |S| |U|U|o
+                                               |           | |H| |L|S|t
+                                               |           |M|O| |D|T|n
+                                               |           |U|U|M| | |o
+                                               |           |S|L|A|N|N|t
+                                               |           |T|D|Y|O|O|t
+FEATURE                                        |SECTION    | | | |T|T|e
+-----------------------------------------------|-----------|-|-|-|-|-|--
+Support SNMP or CMOT agent                     |6.3.1      | |x| | | |
+Implement specified objects in standard MIB    |6.3.1      | |x| | | |
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Internet Engineering Task Force                                [Page 92]
+
+
+
+
+RFC1123              SUPPORT SERVICES -- MANAGEMENT         October 1989
+
+
+7.  REFERENCES
+
+   This section lists the primary references with which every
+   implementer must be thoroughly familiar.  It also lists some
+   secondary references that are suggested additional reading.
+
+   INTRODUCTORY REFERENCES:
+
+
+   [INTRO:1] "Requirements for Internet Hosts -- Communication Layers,"
+        IETF Host Requirements Working Group, R. Braden, Ed., RFC-1122,
+        October 1989.
+
+   [INTRO:2]  "DDN Protocol Handbook," NIC-50004, NIC-50005, NIC-50006,
+        (three volumes), SRI International, December 1985.
+
+   [INTRO:3]  "Official Internet Protocols," J. Reynolds and J. Postel,
+        RFC-1011, May 1987.
+
+        This document is republished periodically with new RFC numbers;
+        the latest version must be used.
+
+   [INTRO:4]  "Protocol Document Order Information," O. Jacobsen and J.
+        Postel, RFC-980, March 1986.
+
+   [INTRO:5]  "Assigned Numbers," J. Reynolds and J. Postel, RFC-1010,
+        May 1987.
+
+        This document is republished periodically with new RFC numbers;
+        the latest version must be used.
+
+
+   TELNET REFERENCES:
+
+
+   [TELNET:1]  "Telnet Protocol Specification," J. Postel and J.
+        Reynolds, RFC-854, May 1983.
+
+   [TELNET:2]  "Telnet Option Specification," J. Postel and J. Reynolds,
+        RFC-855, May 1983.
+
+   [TELNET:3]  "Telnet Binary Transmission," J. Postel and J. Reynolds,
+        RFC-856, May 1983.
+
+   [TELNET:4]  "Telnet Echo Option," J. Postel and J. Reynolds, RFC-857,
+        May 1983.
+
+   [TELNET:5]  "Telnet Suppress Go Ahead Option," J. Postel and J.
+
+
+
+Internet Engineering Task Force                                [Page 93]
+
+
+
+
+RFC1123              SUPPORT SERVICES -- MANAGEMENT         October 1989
+
+
+        Reynolds, RFC-858, May 1983.
+
+   [TELNET:6]  "Telnet Status Option," J. Postel and J. Reynolds, RFC-
+        859, May 1983.
+
+   [TELNET:7]  "Telnet Timing Mark Option," J. Postel and J. Reynolds,
+        RFC-860, May 1983.
+
+   [TELNET:8]  "Telnet Extended Options List," J. Postel and J.
+        Reynolds, RFC-861, May 1983.
+
+   [TELNET:9]  "Telnet End-Of-Record Option," J. Postel, RFC-855,
+        December 1983.
+
+   [TELNET:10] "Telnet Terminal-Type Option," J. VanBokkelen, RFC-1091,
+        February 1989.
+
+        This document supercedes RFC-930.
+
+   [TELNET:11] "Telnet Window Size Option," D. Waitzman, RFC-1073,
+        October 1988.
+
+   [TELNET:12] "Telnet Linemode Option," D. Borman, RFC-1116, August
+        1989.
+
+   [TELNET:13] "Telnet Terminal Speed Option," C. Hedrick, RFC-1079,
+        December 1988.
+
+   [TELNET:14] "Telnet Remote Flow Control Option," C. Hedrick, RFC-
+        1080, November 1988.
+
+
+   SECONDARY TELNET REFERENCES:
+
+
+   [TELNET:15] "Telnet Protocol," MIL-STD-1782, U.S. Department of
+        Defense, May 1984.
+
+        This document is intended to describe the same protocol as RFC-
+        854.  In case of conflict, RFC-854 takes precedence, and the
+        present document takes precedence over both.
+
+   [TELNET:16] "SUPDUP Protocol," M. Crispin, RFC-734, October 1977.
+
+   [TELNET:17] "Telnet SUPDUP Option," M. Crispin, RFC-736, October
+        1977.
+
+   [TELNET:18] "Data Entry Terminal Option," J. Day, RFC-732, June 1977.
+
+
+
+Internet Engineering Task Force                                [Page 94]
+
+
+
+
+RFC1123              SUPPORT SERVICES -- MANAGEMENT         October 1989
+
+
+   [TELNET:19] "TELNET Data Entry Terminal option -- DODIIS
+        Implementation," A. Yasuda and T. Thompson, RFC-1043, February
+        1988.
+
+
+   FTP REFERENCES:
+
+
+   [FTP:1]  "File Transfer Protocol," J. Postel and J. Reynolds, RFC-
+        959, October 1985.
+
+   [FTP:2]  "Document File Format Standards," J. Postel, RFC-678,
+        December 1974.
+
+   [FTP:3]  "File Transfer Protocol," MIL-STD-1780, U.S. Department of
+        Defense, May 1984.
+
+        This document is based on an earlier version of the FTP
+        specification (RFC-765) and is obsolete.
+
+
+   TFTP REFERENCES:
+
+
+   [TFTP:1]  "The TFTP Protocol Revision 2," K. Sollins, RFC-783, June
+        1981.
+
+
+   MAIL REFERENCES:
+
+
+   [SMTP:1]  "Simple Mail Transfer Protocol," J. Postel, RFC-821, August
+        1982.
+
+   [SMTP:2]  "Standard For The Format of ARPA Internet Text Messages,"
+        D. Crocker, RFC-822, August 1982.
+
+        This document obsoleted an earlier specification, RFC-733.
+
+   [SMTP:3]  "Mail Routing and the Domain System," C. Partridge, RFC-
+        974, January 1986.
+
+        This RFC describes the use of MX records, a mandatory extension
+        to the mail delivery process.
+
+   [SMTP:4]  "Duplicate Messages and SMTP," C. Partridge, RFC-1047,
+        February 1988.
+
+
+
+
+Internet Engineering Task Force                                [Page 95]
+
+
+
+
+RFC1123              SUPPORT SERVICES -- MANAGEMENT         October 1989
+
+
+   [SMTP:5a]  "Mapping between X.400 and RFC 822," S. Kille, RFC-987,
+        June 1986.
+
+   [SMTP:5b]  "Addendum to RFC-987," S. Kille, RFC-???, September 1987.
+
+        The two preceding RFC's define a proposed standard for
+        gatewaying mail between the Internet and the X.400 environments.
+
+   [SMTP:6]  "Simple Mail Transfer Protocol,"  MIL-STD-1781, U.S.
+        Department of Defense, May 1984.
+
+        This specification is intended to describe the same protocol as
+        does RFC-821.  However, MIL-STD-1781 is incomplete; in
+        particular, it does not include MX records [SMTP:3].
+
+   [SMTP:7]  "A Content-Type Field for Internet Messages," M. Sirbu,
+        RFC-1049, March 1988.
+
+
+   DOMAIN NAME SYSTEM REFERENCES:
+
+
+   [DNS:1]  "Domain Names - Concepts and Facilities," P. Mockapetris,
+        RFC-1034, November 1987.
+
+        This document and the following one obsolete RFC-882, RFC-883,
+        and RFC-973.
+
+   [DNS:2]  "Domain Names - Implementation and Specification," RFC-1035,
+        P. Mockapetris, November 1987.
+
+
+   [DNS:3]  "Mail Routing and the Domain System," C. Partridge, RFC-974,
+        January 1986.
+
+
+   [DNS:4]  "DoD Internet Host Table Specification," K. Harrenstein,
+        RFC-952, M. Stahl, E. Feinler, October 1985.
+
+        SECONDARY DNS REFERENCES:
+
+
+   [DNS:5]  "Hostname Server," K. Harrenstein, M. Stahl, E. Feinler,
+        RFC-953, October 1985.
+
+   [DNS:6]  "Domain Administrators Guide," M. Stahl, RFC-1032, November
+        1987.
+
+
+
+
+Internet Engineering Task Force                                [Page 96]
+
+
+
+
+RFC1123              SUPPORT SERVICES -- MANAGEMENT         October 1989
+
+
+   [DNS:7]  "Domain Administrators Operations Guide," M. Lottor, RFC-
+        1033, November 1987.
+
+   [DNS:8]  "The Domain Name System Handbook," Vol. 4 of Internet
+        Protocol Handbook, NIC 50007, SRI Network Information Center,
+        August 1989.
+
+
+   SYSTEM INITIALIZATION REFERENCES:
+
+
+   [BOOT:1] "Bootstrap Loading Using TFTP," R. Finlayson, RFC-906, June
+        1984.
+
+   [BOOT:2] "Bootstrap Protocol (BOOTP)," W. Croft and J. Gilmore, RFC-
+        951, September 1985.
+
+   [BOOT:3] "BOOTP Vendor Information Extensions," J. Reynolds, RFC-
+        1084, December 1988.
+
+        Note: this RFC revised and obsoleted RFC-1048.
+
+   [BOOT:4] "A Reverse Address Resolution Protocol," R. Finlayson, T.
+        Mann, J. Mogul, and M. Theimer, RFC-903, June 1984.
+
+
+   MANAGEMENT REFERENCES:
+
+
+   [MGT:1]  "IAB Recommendations for the Development of Internet Network
+        Management Standards," V. Cerf, RFC-1052, April 1988.
+
+   [MGT:2]  "Structure and Identification of Management Information for
+        TCP/IP-based internets," M. Rose and K. McCloghrie, RFC-1065,
+        August 1988.
+
+   [MGT:3]  "Management Information Base for Network Management of
+        TCP/IP-based internets," M. Rose and K. McCloghrie, RFC-1066,
+        August 1988.
+
+   [MGT:4]  "A Simple Network Management Protocol," J. Case, M. Fedor,
+        M. Schoffstall, and C. Davin, RFC-1098, April 1989.
+
+   [MGT:5]  "The Common Management Information Services and Protocol
+        over TCP/IP," U. Warrier and L. Besaw, RFC-1095, April 1989.
+
+   [MGT:6]  "Report of the Second Ad Hoc Network Management Review
+        Group," V. Cerf, RFC-1109, August 1989.
+
+
+
+Internet Engineering Task Force                                [Page 97]
+
+
+
+
+RFC1123              SUPPORT SERVICES -- MANAGEMENT         October 1989
+
+
+Security Considerations
+
+   There are many security issues in the application and support
+   programs of host software, but a full discussion is beyond the scope
+   of this RFC.  Security-related issues are mentioned in sections
+   concerning TFTP (Sections 4.2.1, 4.2.3.4, 4.2.3.5), the SMTP VRFY and
+   EXPN commands (Section 5.2.3), the SMTP HELO command (5.2.5), and the
+   SMTP DATA command (Section 5.2.8).
+
+Author's Address
+
+   Robert Braden
+   USC/Information Sciences Institute
+   4676 Admiralty Way
+   Marina del Rey, CA 90292-6695
+
+   Phone: (213) 822 1511
+
+   EMail: Braden@ISI.EDU
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Internet Engineering Task Force                                [Page 98]
+
diff --git a/doc/rfc/rfc1183.txt b/doc/rfc/rfc1183.txt
new file mode 100644
index 0000000..6f08044
--- /dev/null
+++ b/doc/rfc/rfc1183.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+Network Working Group                                        C. Everhart
+Request for Comments: 1183                                      Transarc
+Updates: RFCs 1034, 1035                                      L. Mamakos
+                                                  University of Maryland
+                                                              R. Ullmann
+                                                          Prime Computer
+                                                  P. Mockapetris, Editor
+                                                                     ISI
+                                                            October 1990
+
+
+                         New DNS RR Definitions
+
+Status of this Memo
+
+   This memo defines five new DNS types for experimental purposes.  This
+   RFC describes an Experimental Protocol for the Internet community,
+   and requests discussion and suggestions for improvements.
+   Distribution of this memo is unlimited.
+
+Table of Contents
+
+   Introduction....................................................    1
+   1. AFS Data Base location.......................................    2
+   2. Responsible Person...........................................    3
+   2.1. Identification of the guilty party.........................    3
+   2.2. The Responsible Person RR..................................    4
+   3. X.25 and ISDN addresses, Route Binding.......................    6
+   3.1. The X25 RR.................................................    6
+   3.2. The ISDN RR................................................    7
+   3.3. The Route Through RR.......................................    8
+   REFERENCES and BIBLIOGRAPHY.....................................    9
+   Security Considerations.........................................   10
+   Authors' Addresses..............................................   11
+
+Introduction
+
+   This RFC defines the format of new Resource Records (RRs) for the
+   Domain Name System (DNS), and reserves corresponding DNS type
+   mnemonics and numerical codes.  The definitions are in three
+   independent sections: (1) location of AFS database servers, (2)
+   location of responsible persons, and (3) representation of X.25 and
+   ISDN addresses and route binding.  All are experimental.
+
+   This RFC assumes that the reader is familiar with the DNS [3,4].  The
+   data shown is for pedagogical use and does not necessarily reflect
+   the real Internet.
+
+
+
+
+Everhart, Mamakos, Ullmann & Mockapetris                        [Page 1]
+
+RFC 1183                 New DNS RR Definitions             October 1990
+
+
+1. AFS Data Base location
+
+   This section defines an extension of the DNS to locate servers both
+   for AFS (AFS is a registered trademark of Transarc Corporation) and
+   for the Open Software Foundation's (OSF) Distributed Computing
+   Environment (DCE) authenticated naming system using HP/Apollo's NCA,
+   both to be components of the OSF DCE.  The discussion assumes that
+   the reader is familiar with AFS [5] and NCA [6].
+
+   The AFS (originally the Andrew File System) system uses the DNS to
+   map from a domain name to the name of an AFS cell database server.
+   The DCE Naming service uses the DNS for a similar function: mapping
+   from the domain name of a cell to authenticated name servers for that
+   cell.  The method uses a new RR type with mnemonic AFSDB and type
+   code of 18 (decimal).
+
+   AFSDB has the following format:
+
+   <owner> <ttl> <class> AFSDB <subtype> <hostname>
+
+   Both RDATA fields are required in all AFSDB RRs.  The <subtype> field
+   is a 16 bit integer.  The <hostname> field is a domain name of a host
+   that has a server for the cell named by the owner name of the RR.
+
+   The format of the AFSDB RR is class insensitive.  AFSDB records cause
+   type A additional section processing for <hostname>.  This, in fact,
+   is the rationale for using a new type code, rather than trying to
+   build the same functionality with TXT RRs.
+
+   Note that the format of AFSDB in a master file is identical to MX.
+   For purposes of the DNS itself, the subtype is merely an integer.
+   The present subtype semantics are discussed below, but changes are
+   possible and will be announced in subsequent RFCs.
+
+   In the case of subtype 1, the host has an AFS version 3.0 Volume
+   Location Server for the named AFS cell.  In the case of subtype 2,
+   the host has an authenticated name server holding the cell-root
+   directory node for the named DCE/NCA cell.
+
+   The use of subtypes is motivated by two considerations.  First, the
+   space of DNS RR types is limited.  Second, the services provided are
+   sufficiently distinct that it would continue to be confusing for a
+   client to attempt to connect to a cell's servers using the protocol
+   for one service, if the cell offered only the other service.
+
+   As an example of the use of this RR, suppose that the Toaster
+   Corporation has deployed AFS 3.0 but not (yet) the OSF's DCE.  Their
+   cell, named toaster.com, has three "AFS 3.0 cell database server"
+
+
+
+Everhart, Mamakos, Ullmann & Mockapetris                        [Page 2]
+
+RFC 1183                 New DNS RR Definitions             October 1990
+
+
+   machines: bigbird.toaster.com, ernie.toaster.com, and
+   henson.toaster.com.  These three machines would be listed in three
+   AFSDB RRs.  These might appear in a master file as:
+
+   toaster.com.   AFSDB   1 bigbird.toaster.com.
+   toaster.com.   AFSDB   1 ernie.toaster.com.
+   toaster.com.   AFSDB   1 henson.toaster.com.
+
+   As another example use of this RR, suppose that Femto College (domain
+   name femto.edu) has deployed DCE, and that their DCE cell root
+   directory is served by processes running on green.femto.edu and
+   turquoise.femto.edu.  Furthermore, their DCE file servers also run
+   AFS 3.0-compatible volume location servers, on the hosts
+   turquoise.femto.edu and orange.femto.edu.  These machines would be
+   listed in four AFSDB RRs, which might appear in a master file as:
+
+   femto.edu.   AFSDB   2 green.femto.edu.
+   femto.edu.   AFSDB   2 turquoise.femto.edu.
+   femto.edu.   AFSDB   1 turquoise.femto.edu.
+   femto.edu.   AFSDB   1 orange.femto.edu.
+
+2. Responsible Person
+
+   The purpose of this section is to provide a standard method for
+   associating responsible person identification to any name in the DNS.
+
+   The domain name system functions as a distributed database which
+   contains many different form of information.  For a particular name
+   or host, you can discover it's Internet address, mail forwarding
+   information, hardware type and operating system among others.
+
+   A key aspect of the DNS is that the tree-structured namespace can be
+   divided into pieces, called zones, for purposes of distributing
+   control and responsibility.  The responsible person for zone database
+   purposes is named in the SOA RR for that zone.  This section
+   describes an extension which allows different responsible persons to
+   be specified for different names in a zone.
+
+2.1. Identification of the guilty party
+
+   Often it is desirable to be able to identify the responsible entity
+   for a particular host.  When that host is down or malfunctioning, it
+   is difficult to contact those parties which might resolve or repair
+   the host.  Mail sent to POSTMASTER may not reach the person in a
+   timely fashion.  If the host is one of a multitude of workstations,
+   there may be no responsible person which can be contacted on that
+   host.
+
+
+
+
+Everhart, Mamakos, Ullmann & Mockapetris                        [Page 3]
+
+RFC 1183                 New DNS RR Definitions             October 1990
+
+
+   The POSTMASTER mailbox on that host continues to be a good contact
+   point for mail problems, and the zone contact in the SOA record for
+   database problem, but the RP record allows us to associate a mailbox
+   to entities that don't receive mail or are not directly connected
+   (namespace-wise) to the problem (e.g., GATEWAY.ISI.EDU might want to
+   point at HOTLINE@BBN.COM, and GATEWAY doesn't get mail, nor does the
+   ISI zone administrator have a clue about fixing gateways).
+
+2.2. The Responsible Person RR
+
+   The method uses a new RR type with mnemonic RP and type code of 17
+   (decimal).
+
+   RP has the following format:
+
+   <owner> <ttl> <class> RP <mbox-dname> <txt-dname>
+
+   Both RDATA fields are required in all RP RRs.
+
+   The first field, <mbox-dname>, is a domain name that specifies the
+   mailbox for the responsible person.  Its format in master files uses
+   the DNS convention for mailbox encoding, identical to that used for
+   the RNAME mailbox field in the SOA RR.  The root domain name (just
+   ".") may be specified for <mbox-dname> to indicate that no mailbox is
+   available.
+
+   The second field, <txt-dname>, is a domain name for which TXT RR's
+   exist.  A subsequent query can be performed to retrieve the
+   associated TXT resource records at <txt-dname>.  This provides a
+   level of indirection so that the entity can be referred to from
+   multiple places in the DNS.  The root domain name (just ".") may be
+   specified for <txt-dname> to indicate that the TXT_DNAME is absent,
+   and no associated TXT RR exists.
+
+   The format of the RP RR is class insensitive.  RP records cause no
+   additional section processing.  (TXT additional section processing
+   for <txt-dname> is allowed as an option, but only if it is disabled
+   for the root, i.e., ".").
+
+   The Responsible Person RR can be associated with any node in the
+   Domain Name System hierarchy, not just at the leaves of the tree.
+
+   The TXT RR associated with the TXT_DNAME contain free format text
+   suitable for humans.  Refer to [4] for more details on the TXT RR.
+
+   Multiple RP records at a single name may be present in the database.
+   They should have identical TTLs.
+
+
+
+
+Everhart, Mamakos, Ullmann & Mockapetris                        [Page 4]
+
+RFC 1183                 New DNS RR Definitions             October 1990
+
+
+   EXAMPLES
+
+   Some examples of how the RP record might be used.
+
+   sayshell.umd.edu. A     128.8.1.14
+                     MX    10 sayshell.umd.edu.
+                     HINFO NeXT UNIX
+                     WKS   128.8.1.14 tcp ftp telnet smtp
+                     RP    louie.trantor.umd.edu.  LAM1.people.umd.edu.
+
+   LAM1.people.umd.edu. TXT (
+         "Louis A. Mamakos, (301) 454-2946, don't call me at home!" )
+
+   In this example, the responsible person's mailbox for the host
+   SAYSHELL.UMD.EDU is louie@trantor.umd.edu.  The TXT RR at
+   LAM1.people.umd.edu provides additional information and advice.
+
+   TERP.UMD.EDU.    A     128.8.10.90
+                    MX    10 128.8.10.90
+                    HINFO MICROVAX-II UNIX
+                    WKS   128.8.10.90 udp domain
+                    WKS   128.8.10.90 tcp ftp telnet smtp domain
+                    RP    louie.trantor.umd.edu. LAM1.people.umd.edu.
+                    RP    root.terp.umd.edu. ops.CS.UMD.EDU.
+
+   TRANTOR.UMD.EDU. A     128.8.10.14
+                    MX    10 trantor.umd.edu.
+                    HINFO MICROVAX-II UNIX
+                    WKS   128.8.10.14 udp domain
+                    WKS   128.8.10.14 tcp ftp telnet smtp domain
+                    RP    louie.trantor.umd.edu. LAM1.people.umd.edu.
+                    RP    petry.netwolf.umd.edu. petry.people.UMD.EDU.
+                    RP    root.trantor.umd.edu. ops.CS.UMD.EDU.
+                    RP    gregh.sunset.umd.edu.  .
+
+   LAM1.people.umd.edu.  TXT   "Louis A. Mamakos (301) 454-2946"
+   petry.people.umd.edu. TXT   "Michael G. Petry (301) 454-2946"
+   ops.CS.UMD.EDU.       TXT   "CS Operations Staff (301) 454-2943"
+
+   This set of resource records has two hosts, TRANTOR.UMD.EDU and
+   TERP.UMD.EDU, as well as a number of TXT RRs.  Note that TERP.UMD.EDU
+   and TRANTOR.UMD.EDU both reference the same pair of TXT resource
+   records, although the mail box names (root.terp.umd.edu and
+   root.trantor.umd.edu) differ.
+
+   Here, we obviously care much more if the machine flakes out, as we've
+   specified four persons which might want to be notified of problems or
+   other events involving TRANTOR.UMD.EDU.  In this example, the last RP
+
+
+
+Everhart, Mamakos, Ullmann & Mockapetris                        [Page 5]
+
+RFC 1183                 New DNS RR Definitions             October 1990
+
+
+   RR for TRANTOR.UMD.EDU specifies a mailbox (gregh.sunset.umd.edu),
+   but no associated TXT RR.
+
+3. X.25 and ISDN addresses, Route Binding
+
+   This section describes an experimental representation of X.25 and
+   ISDN addresses in the DNS, as well as a route binding method,
+   analogous to the MX for mail routing, for very large scale networks.
+
+   There are several possible uses, all experimental at this time.
+   First, the RRs provide simple documentation of the correct addresses
+   to use in static configurations of IP/X.25 [11] and SMTP/X.25 [12].
+
+   The RRs could also be used automatically by an internet network-layer
+   router, typically IP.  The procedure would be to map IP address to
+   domain name, then name to canonical name if needed, then following RT
+   records, and finally attempting an IP/X.25 call to the address found.
+   Alternately, configured domain names could be resolved to identify IP
+   to X.25/ISDN bindings for a static but periodically refreshed routing
+   table.
+
+   This provides a function similar to ARP for wide area non-broadcast
+   networks that will scale well to a network with hundreds of millions
+   of hosts.
+
+   Also, a standard address binding reference will facilitate other
+   experiments in the use of X.25 and ISDN, especially in serious
+   inter-operability testing.  The majority of work in such a test is
+   establishing the n-squared entries in static tables.
+
+   Finally, the RRs are intended for use in a proposal [13] by one of
+   the authors for a possible next-generation internet.
+
+3.1. The X25 RR
+
+   The X25 RR is defined with mnemonic X25 and type code 19 (decimal).
+
+   X25 has the following format:
+
+   <owner> <ttl> <class> X25 <PSDN-address>
+
+   <PSDN-address> is required in all X25 RRs.
+
+   <PSDN-address> identifies the PSDN (Public Switched Data Network)
+   address in the X.121 [10] numbering plan associated with <owner>.
+   Its format in master files is a <character-string> syntactically
+   identical to that used in TXT and HINFO.
+
+
+
+
+Everhart, Mamakos, Ullmann & Mockapetris                        [Page 6]
+
+RFC 1183                 New DNS RR Definitions             October 1990
+
+
+   The format of X25 is class insensitive.  X25 RRs cause no additional
+   section processing.
+
+   The <PSDN-address> is a string of decimal digits, beginning with the
+   4 digit DNIC (Data Network Identification Code), as specified in
+   X.121. National prefixes (such as a 0) MUST NOT be used.
+
+   For example:
+
+   Relay.Prime.COM.  X25       311061700956
+
+3.2. The ISDN RR
+
+   The ISDN RR is defined with mnemonic ISDN and type code 20 (decimal).
+
+   An ISDN (Integrated Service Digital Network) number is simply a
+   telephone number.  The intent of the members of the CCITT is to
+   upgrade all telephone and data network service to a common service.
+
+   The numbering plan (E.163/E.164) is the same as the familiar
+   international plan for POTS (an un-official acronym, meaning Plain
+   Old Telephone Service).  In E.166, CCITT says "An E.163/E.164
+   telephony subscriber may become an ISDN subscriber without a number
+   change."
+
+   ISDN has the following format:
+
+   <owner> <ttl> <class> ISDN <ISDN-address> <sa>
+
+   The <ISDN-address> field is required; <sa> is optional.
+
+   <ISDN-address> identifies the ISDN number of <owner> and DDI (Direct
+   Dial In) if any, as defined by E.164 [8] and E.163 [7], the ISDN and
+   PSTN (Public Switched Telephone Network) numbering plan.  E.163
+   defines the country codes, and E.164 the form of the addresses.  Its
+   format in master files is a <character-string> syntactically
+   identical to that used in TXT and HINFO.
+
+   <sa> specifies the subaddress (SA).  The format of <sa> in master
+   files is a <character-string> syntactically identical to that used in
+   TXT and HINFO.
+
+   The format of ISDN is class insensitive.  ISDN RRs cause no
+   additional section processing.
+
+   The <ISDN-address> is a string of characters, normally decimal
+   digits, beginning with the E.163 country code and ending with the DDI
+   if any.  Note that ISDN, in Q.931, permits any IA5 character in the
+
+
+
+Everhart, Mamakos, Ullmann & Mockapetris                        [Page 7]
+
+RFC 1183                 New DNS RR Definitions             October 1990
+
+
+   general case.
+
+   The <sa> is a string of hexadecimal digits.  For digits 0-9, the
+   concrete encoding in the Q.931 call setup information element is
+   identical to BCD.
+
+   For example:
+
+   Relay.Prime.COM.   IN   ISDN      150862028003217
+   sh.Prime.COM.      IN   ISDN      150862028003217 004
+
+   (Note: "1" is the country code for the North American Integrated
+   Numbering Area, i.e., the system of "area codes" familiar to people
+   in those countries.)
+
+   The RR data is the ASCII representation of the digits.  It is encoded
+   as one or two <character-string>s, i.e., count followed by
+   characters.
+
+   CCITT recommendation E.166 [9] defines prefix escape codes for the
+   representation of ISDN (E.163/E.164) addresses in X.121, and PSDN
+   (X.121) addresses in E.164.  It specifies that the exact codes are a
+   "national matter", i.e., different on different networks.  A host
+   connected to the ISDN may be able to use both the X25 and ISDN
+   addresses, with the local prefix added.
+
+3.3. The Route Through RR
+
+   The Route Through RR is defined with mnemonic RT and type code 21
+   (decimal).
+
+   The RT resource record provides a route-through binding for hosts
+   that do not have their own direct wide area network addresses.  It is
+   used in much the same way as the MX RR.
+
+   RT has the following format:
+
+   <owner> <ttl> <class> RT <preference> <intermediate-host>
+
+   Both RDATA fields are required in all RT RRs.
+
+   The first field, <preference>, is a 16 bit integer, representing the
+   preference of the route.  Smaller numbers indicate more preferred
+   routes.
+
+   <intermediate-host> is the domain name of a host which will serve as
+   an intermediate in reaching the host specified by <owner>.  The DNS
+   RRs associated with <intermediate-host> are expected to include at
+
+
+
+Everhart, Mamakos, Ullmann & Mockapetris                        [Page 8]
+
+RFC 1183                 New DNS RR Definitions             October 1990
+
+
+   least one A, X25, or ISDN record.
+
+   The format of the RT RR is class insensitive.  RT records cause type
+   X25, ISDN, and A additional section processing for <intermediate-
+   host>.
+
+   For example,
+
+   sh.prime.com.      IN   RT   2    Relay.Prime.COM.
+                      IN   RT   10   NET.Prime.COM.
+   *.prime.com.       IN   RT   90   Relay.Prime.COM.
+
+   When a host is looking up DNS records to attempt to route a datagram,
+   it first looks for RT records for the destination host, which point
+   to hosts with address records (A, X25, ISDN) compatible with the wide
+   area networks available to the host.  If it is itself in the set of
+   RT records, it discards any RTs with preferences higher or equal to
+   its own.  If there are no (remaining) RTs, it can then use address
+   records of the destination itself.
+
+   Wild-card RTs are used exactly as are wild-card MXs.  RT's do not
+   "chain"; that is, it is not valid to use the RT RRs found for a host
+   referred to by an RT.
+
+   The concrete encoding is identical to the MX RR.
+
+REFERENCES and BIBLIOGRAPHY
+
+   [1] Stahl, M., "Domain Administrators Guide", RFC 1032, Network
+       Information Center, SRI International, November 1987.
+
+   [2] Lottor, M., "Domain Administrators Operations Guide", RFC 1033,
+       Network Information Center, SRI International, November, 1987.
+
+   [3] Mockapetris, P., "Domain Names - Concepts and Facilities", RFC
+       1034, USC/Information Sciences Institute, November 1987.
+
+   [4] Mockapetris, P., "Domain Names - Implementation and
+       Specification", RFC 1035, USC/Information Sciences Institute,
+       November 1987.
+
+   [5] Spector A., and M. Kazar, "Uniting File Systems", UNIX Review,
+       7(3), pp. 61-69, March 1989.
+
+   [6] Zahn, et al., "Network Computing Architecture", Prentice-Hall,
+       1989.
+
+   [7] International Telegraph and Telephone Consultative Committee,
+
+
+
+Everhart, Mamakos, Ullmann & Mockapetris                        [Page 9]
+
+RFC 1183                 New DNS RR Definitions             October 1990
+
+
+       "Numbering Plan for the International Telephone Service", CCITT
+       Recommendations E.163., IXth Plenary Assembly, Melbourne, 1988,
+       Fascicle II.2 ("Blue Book").
+
+   [8] International Telegraph and Telephone Consultative Committee,
+       "Numbering Plan for the ISDN Era", CCITT Recommendations E.164.,
+       IXth Plenary Assembly, Melbourne, 1988, Fascicle II.2 ("Blue
+       Book").
+
+   [9] International Telegraph and Telephone Consultative Committee.
+       "Numbering Plan Interworking in the ISDN Era", CCITT
+       Recommendations E.166., IXth Plenary Assembly, Melbourne, 1988,
+       Fascicle II.2 ("Blue Book").
+
+  [10] International Telegraph and Telephone Consultative Committee,
+       "International Numbering Plan for the Public Data Networks",
+       CCITT Recommendations X.121., IXth Plenary Assembly, Melbourne,
+       1988, Fascicle VIII.3 ("Blue Book"); provisional, Geneva, 1978;
+       amended, Geneva, 1980, Malaga-Torremolinos, 1984 and Melborne,
+       1988.
+
+  [11] Korb, J., "Standard for the Transmission of IP datagrams Over
+       Public Data Networks", RFC 877, Purdue University, September
+       1983.
+
+  [12] Ullmann, R., "SMTP on X.25", RFC 1090, Prime Computer, February
+       1989.
+
+  [13] Ullmann, R., "TP/IX: The Next Internet", Prime Computer
+       (unpublished), July 1990.
+
+  [14] Mockapetris, P., "DNS Encoding of Network Names and Other Types",
+       RFC 1101, USC/Information Sciences Institute, April 1989.
+
+Security Considerations
+
+   Security issues are not addressed in this memo.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Everhart, Mamakos, Ullmann & Mockapetris                       [Page 10]
+
+RFC 1183                 New DNS RR Definitions             October 1990
+
+
+Authors' Addresses
+
+   Craig F. Everhart
+   Transarc Corporation
+   The Gulf Tower
+   707 Grant Street
+   Pittsburgh, PA  15219
+
+   Phone: +1 412 338 4467
+
+   EMail: Craig_Everhart@transarc.com
+
+
+   Louis A. Mamakos
+   Network Infrastructure Group
+   Computer Science Center
+   University of Maryland
+   College Park, MD 20742-2411
+
+   Phone: +1-301-405-7836
+
+   Email: louie@Sayshell.UMD.EDU
+
+
+   Robert Ullmann 10-30
+   Prime Computer, Inc.
+   500 Old Connecticut Path
+   Framingham, MA 01701
+
+   Phone: +1 508 620 2800 ext 1736
+
+   Email: Ariel@Relay.Prime.COM
+
+
+   Paul Mockapetris
+   USC Information Sciences Institute
+   4676 Admiralty Way
+   Marina del Rey, CA 90292
+
+   Phone: 213-822-1511
+
+   EMail: pvm@isi.edu
+
+
+
+
+
+
+
+
+
+Everhart, Mamakos, Ullmann & Mockapetris                       [Page 11]
+
\ No newline at end of file
diff --git a/doc/rfc/rfc1348.txt b/doc/rfc/rfc1348.txt
new file mode 100644
index 0000000..d9e5dea
--- /dev/null
+++ b/doc/rfc/rfc1348.txt
@@ -0,0 +1,227 @@
+
+
+
+
+
+
+Network Working Group                                         B. Manning
+Request for Comments: 1348                               Rice University
+Updates: RFCs 1034, 1035                                       July 1992
+
+
+                              DNS NSAP RRs
+
+Status of this Memo
+
+   This memo defines an Experimental Protocol for the Internet
+   community.  Discussion and suggestions for improvement are requested.
+   Please refer to the current edition of the "IAB Official Protocol
+   Standards" for the standardization state and status of this protocol.
+   Distribution of this memo is unlimited.
+
+Table of Contents
+
+   Introduction .....................................................  1
+   Background .......................................................  1
+   NSAP RR ..........................................................  2
+   NSAP-PTR RR ......................................................  2
+   REFERENCES and BIBLIOGRAPHY ......................................  3
+   Security Considerations ..........................................  4
+   Author's Address .................................................  4
+
+Introduction
+
+   This RFC defines the format of two new Resource Records (RRs) for the
+   Domain Name System (DNS), and reserves corresponding DNS type
+   mnemonic and numerical codes.  This format may be used with the any
+   proposal that has variable length addresses, but is targeted for CLNP
+   use.
+
+   This memo assumes that the reader is familiar with the DNS [3,4].
+
+Background
+
+   This section describes an experimental representation of NSAP
+   addresses in the DNS. There are several reasons to take this approch.
+   First, it provides simple documentation of the correct addresses to
+   use in static configurations of CLNP compliant hosts and routers.
+
+   NSAP support requires that a new DNS resource record entry type
+   ("NSAP") be defined, to store longer Internet (i.e., NSAP) addresses.
+   This resource record allows mapping from DNS names to NSAP addresses,
+   and will contain entries for systems which are able to run Internet
+   applications, over TCP or UDP, over CLNP.
+
+
+
+
+Manning                                                         [Page 1]
+
+RFC 1348                      DNS NSAP RRs                     July 1992
+
+
+   The backward translation (from NSAP address to DNS name) is
+   facilitated by definition of an associated resource record. This
+   resource record is known as "NSAP-PTR", and is used in a manner
+   analogous to the existing "in-addr.arpa".
+
+   These RRs are intended for use in a proposal [6] by one of the
+   members of the NOOP WG to address the next-generation internet.
+
+The NSAP RR
+
+   The NSAP RR is defined with mnemonic NSAP and type code 22 (decimal).
+
+   An NSAP (Network Service Access Protocol) number is a unique string
+   to OSI transport service.
+
+   The numbering plan follows RFC 1237 and associated OSI definitions
+   for NSAP format.
+
+   NSAP has the following format:
+
+   <owner> <ttl> <class> NSAP <length> <NSAP-address>
+
+   All fields are required.
+
+   <length> identifies the number of octets in the <NSAP-address> as
+   defined by the various national and international authorities.
+
+   <NSAP-address> enumerates the actual octet values assigned by the
+   assigning authority.  Its format in master files is a <character-
+   string> syntactically identical to that used in TXT and HINFO.
+
+   The format of NSAP is class insensitive.  NSAP RR causes no
+   additional section processing.
+
+   For example:
+
+foo.bar.com.    IN  NSAP   21 47000580ffff000000321099991111222233334444
+host.school.de  IN  NSAP   17 39276f3100111100002222333344449876
+
+   The RR data is the ASCII representation of the digits.  It is encoded
+   as two <character-strings>, i.e., count followed by characters.
+
+The NSAP-PTR RR
+
+   The NSAP-PTR RR is defined with mnemonic NSAP-PTR and a type code 23
+   (decimal).
+
+   Its function is analogous to the PTR record used for IP addresses
+
+
+
+Manning                                                         [Page 2]
+
+RFC 1348                      DNS NSAP RRs                     July 1992
+
+
+   [4,7].
+
+   NSAP-PTR has the following format:
+
+   <NSAP-suffix> <ttl> <class> NSAP-PTR <owner>
+
+   All fields are required.
+
+   <NSAP-suffix> enumerates the actual octet values assigned by the
+   assigning authority for the LOCAL network.  Its format in master
+   files is a <character-string> syntactically identical to that used in
+   TXT and HINFO.
+
+   The format of NSAP-PTR is class insensitive.  NSAP-PTR RR causes no
+   additional section processing.
+
+   For example:
+
+   In net ff08000574.nsap-in-addr.arpa:
+
+   444433332222111199990123000000ff    NSAP-PTR   foo.bar.com.
+
+   Or in net 11110031f67293.nsap-in-addr.arpa:
+
+   67894444333322220000  NSAP-PTR        host.school.de.
+
+   The RR data is the ASCII representation of the digits.  It is encoded
+   as a <character-string>.
+
+REFERENCES and BIBLIOGRAPHY
+
+   [1] Stahl, M., "Domain Administrators Guide", RFC 1032, Network
+       Information Center, SRI International, November 1987.
+
+   [2] Lottor, M., "Domain Administrators Operations Guide", RFC 1033,
+       Network Information Center, SRI International, November, 1987.
+
+   [3] Mockapetris, P., "Domain Names - Concepts and Facilities", RFC
+       1034, USC/Information Sciences Institute, November 1987.
+
+   [4] Mockapetris, P., "Domain Names - Implementation and
+       Specification", RFC 1035, USC/Information Sciences Institute,
+       November 1987.
+
+   [5] Colella, R., Gardner, E., and R. Callon, "Guidelines for OSI
+       NSAP Allocation in the Internet", RFC 1237, NIST, Mitre, DEC,
+       July 1991.
+
+
+
+
+Manning                                                         [Page 3]
+
+RFC 1348                      DNS NSAP RRs                     July 1992
+
+
+   [6] Callon, R., "TCP and UDP with Bigger Addresses (TUBA),
+       A Simple Proposal for Internet Addressing and Routing",
+       Digital Equipment Corporation, RFC 1347, June 1992.
+
+   [7] Mockapetris, P., "DNS Encoding of Network Names and Other Types",
+       RFC 1101, USC/Information Sciences Institute, April 1989.
+
+   [8] ISO/IEC.  Information Processing Systems -- Data Communications
+       -- Network Service Definition Addendum 2: Network Layer Address-
+       ing. International Standard 8348/Addendum 2, ISO/IEC JTC 1,
+       Switzerland, 1988.
+
+   [9] Bryant, P., "NSAPs", PB660, IPTAG/92/23, SCIENCE AND ENGINEERING
+       RESEARCH COUNCIL, RUTHERFORD APPLETON LABORATORY May 1992.
+
+Security Considerations
+
+   Security issues are not addressed in this memo.
+
+Author's Address
+
+   Bill Manning
+   Rice University - ONCS
+   PO Box 1892
+   6100 South Main
+   Houston, Texas  77251-1892
+
+   Phone: +1.713.285.5415
+   EMail: bmanning@rice.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Manning                                                         [Page 4]
+
\ No newline at end of file
diff --git a/doc/rfc/rfc1535.txt b/doc/rfc/rfc1535.txt
new file mode 100644
index 0000000..03bddee
--- /dev/null
+++ b/doc/rfc/rfc1535.txt
@@ -0,0 +1,283 @@
+
+
+
+
+
+
+Network Working Group                                          E. Gavron
+Request for Comments: 1535                            ACES Research Inc.
+Category: Informational                                     October 1993
+
+
+              A Security Problem and Proposed Correction
+                   With Widely Deployed DNS Software
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard.  Distribution of this memo is
+   unlimited.
+
+Abstract
+
+   This document discusses a flaw in some of the currently distributed
+   name resolver clients.  The flaw exposes a security weakness related
+   to the search heuristic invoked by these same resolvers when users
+   provide a partial domain name, and which is easy to exploit (although
+   not by the masses).  This document points out the flaw, a case in
+   point, and a solution.
+
+Background
+
+   Current Domain Name Server clients are designed to ease the burden of
+   remembering IP dotted quad addresses.  As such they translate human-
+   readable names into addresses and other resource records.  Part of
+   the translation process includes understanding and dealing with
+   hostnames that are not fully qualified domain names (FQDNs).
+
+   An absolute "rooted" FQDN is of the format {name}{.} A non "rooted"
+   domain name is of the format {name}
+
+   A domain name may have many parts and typically these include the
+   host, domain, and type.  Example:  foobar.company.com or
+   fooschool.university.edu.
+
+Flaw
+
+   The problem with most widely distributed resolvers based on the BSD
+   BIND resolver is that they attempt to resolve a partial name by
+   processing a search list of partial domains to be added to portions
+   of the specified host name until a DNS record is found.  This
+   "feature" is disabled by default in the official BIND 4.9.2 release.
+
+   Example: A TELNET attempt by    User@Machine.Tech.ACES.COM
+                             to    UnivHost.University.EDU
+
+
+
+Gavron                                                          [Page 1]
+
+RFC 1535               DNS Software Enhancements            October 1993
+
+
+   The resolver client will realize that since "UnivHost.University.EDU"
+   does not end with a ".", it is not an absolute "rooted" FQDN.  It
+   will then try the following combinations until a resource record is
+   found:
+
+                UnivHost.University.EDU.Tech.ACES.COM.
+                UnivHost.University.EDU.ACES.COM.
+                UnivHost.University.EDU.COM.
+                UnivHost.University.EDU.
+
+Security Issue
+
+   After registering the EDU.COM domain, it was discovered that an
+   unliberal application of one wildcard CNAME record would cause *all*
+   connects from any .COM site to any .EDU site to terminate at one
+   target machine in the private edu.com sub-domain.
+
+   Further, discussion reveals that specific hostnames registered in
+   this private subdomain, or any similarly named subdomain may be used
+   to spoof a host.
+
+        Example:        harvard.edu.com.        CNAME   targethost
+
+   Thus all connects to Harvard.edu from all .com sites would end up at
+   targthost, a machine which could provide a Harvard.edu login banner.
+
+   This is clearly unacceptable.  Further, it could only be made worse
+   with domains like COM.EDU, MIL.GOV, GOV.COM, etc.
+
+Public vs. Local Name Space Administration
+
+   The specification of the Domain Name System and the software that
+   implements it provides an undifferentiated hierarchy which permits
+   delegation of administration for subordinate portions of the name
+   space.  Actual administration of the name space is divided between
+   "public" and "local" portions.  Public administration pertains to all
+   top-level domains, such as .COM and .EDU.  For some domains, it also
+   pertains to some number of sub-domain levels.  The multi-level nature
+   of the public administration is most evident for top-level domains
+   for countries.  For example in the Fully Qualified Domain Name,
+   dbc.mtview.ca.us., the portion "mtview.ca.us" represents three levels
+   of public administration.  Only the left-most portion is subject to
+   local administration.
+
+
+
+
+
+
+
+
+Gavron                                                          [Page 2]
+
+RFC 1535               DNS Software Enhancements            October 1993
+
+
+   The danger of the heuristic search common in current practise is that
+   it it is possible to "intercept" the search by matching against an
+   unintended value while walking up the search list.  While this is
+   potentially dangerous at any level, it is entirely unacceptable when
+   the error impacts users outside of a local administration.
+
+   When attempting to resolve a partial domain name, DNS resolvers use
+   the Domain Name of the searching host for deriving the search list.
+   Existing DNS resolvers do not distinguish the portion of that name
+   which is in the locally administered scope from the part that is
+   publically administered.
+
+Solution(s)
+
+   At a minimum, DNS resolvers must honor the BOUNDARY between local and
+   public administration, by limiting any search lists to locally-
+   administered portions of the Domain Name space.  This requires a
+   parameter which shows the scope of the name space controlled by the
+   local administrator.
+
+   This would permit progressive searches from the most qualified to
+   less qualified up through the locally controlled domain, but not
+   beyond.
+
+   For example, if the local user were trying to reach:
+
+        User@chief.admin.DESERTU.EDU from
+        starburst,astro.DESERTU.EDU,
+
+   it is reasonable to permit the user to enter just chief.admin, and
+   for the search to cover:
+
+        chief.admin.astro.DESERTU.EDU
+        chief.admin.DESERTU.EDU
+
+   but not
+
+        chief.admin.EDU
+
+   In this case, the value of "search" should be set to "DESERTU.EDU"
+   because that's the scope of the name space controlled by the local
+   DNS administrator.
+
+   This is more than a mere optimization hack.  The local administrator
+   has control over the assignment of names within the locally
+   administered domain, so the administrator can make sure that
+   abbreviations result in the right thing.  Outside of the local
+   control, users are necessarily at risk.
+
+
+
+Gavron                                                          [Page 3]
+
+RFC 1535               DNS Software Enhancements            October 1993
+
+
+   A more stringent mechanism is implemented in BIND 4.9.2, to respond
+   to this problem:
+
+   The DNS Name resolver clients narrows its IMPLICIT search list IF ANY
+   to only try the first and the last of the examples shown.
+
+   Any additional search alternatives must be configured into the
+   resolver EXPLICITLY.
+
+   DNS Name resolver software SHOULD NOT use implicit search lists in
+   attempts to resolve partial names into absolute FQDNs other than the
+   hosts's immediate parent domain.
+
+   Resolvers which continue to use implicit search lists MUST limit
+   their scope to locally administered sub-domains.
+
+   DNS Name resolver software SHOULD NOT come pre-configured with
+   explicit search lists that perpetuate this problem.
+
+   Further, in any event where a "." exists in a specified name it
+   should be assumed to be a fully qualified domain name (FQDN) and
+   SHOULD be tried as a rooted name first.
+
+   Example:  Given  user@a.b.c.d connecting to e.f.g.h  only two tries
+             should be attempted as a result of using an implicit
+             search list:
+
+                e.f.g.h.  and e.f.g.h.b.c.d.
+
+             Given user@a.b.c.d. connecting to host those same two
+             tries would appear as:
+
+                x.b.c.d.  and x.
+
+   Some organizations make regular use of multi-part, partially
+   qualified Domain Names.  For example, host foo.loc1.org.city.state.us
+   might be used to making references to bar.loc2, or mumble.loc3, all
+   of which refer to whatever.locN.org.city.state.us
+
+   The stringent implicit search rules for BIND 4.9.2 will now cause
+   these searches to fail.  To return the ability for them to succeed,
+   configuration of the client resolvers must be changed to include an
+   explicit search rule for org.city.state.us.  That is, it must contain
+   an explicit rule for any -- and each -- portion of the locally-
+   administered sub-domain that it wishes to have as part of the search
+   list.
+
+
+
+
+
+Gavron                                                          [Page 4]
+
+RFC 1535               DNS Software Enhancements            October 1993
+
+
+References
+
+   [1] Mockapetris, P., "Domain Names Concepts and Facilities", STD 13,
+       RFC 1034, USC/Information Sciences Institute, November 1987.
+
+   [2] Mockapetris, P., "Domain Names Implementation and Specification",
+       STD 13, RFC 1035, USC/Information Sciences Institute, November
+       1987.
+
+   [3] Partridge, C., "Mail Routing and the Domain System", STD 14, RFC
+       974, CSNET CIC BBN, January 1986.
+
+   [4] Kumar, A., Postel, J., Neuman, C., Danzig, P., and S. Miller,
+       "Common DNS Implementation Errors and Suggested Fixes", RFC 1536,
+       USC/Information Sciences Institute, USC, October 1993.
+
+   [5] Beertema, P., "Common DNS Data File Configuration Errors", RFC
+       1537, CWI, October 1993.
+
+Security Considerations
+
+   This memo indicates vulnerabilities with all too-forgiving DNS
+   clients.  It points out a correction that would eliminate the future
+   potential of the problem.
+
+Author's Address
+
+   Ehud Gavron
+   ACES Research Inc.
+   PO Box 14546
+   Tucson, AZ 85711
+
+   Phone: (602) 743-9841
+   EMail: gavron@aces.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gavron                                                          [Page 5]
+
diff --git a/doc/rfc/rfc1536.txt b/doc/rfc/rfc1536.txt
new file mode 100644
index 0000000..5ff2b25
--- /dev/null
+++ b/doc/rfc/rfc1536.txt
@@ -0,0 +1,675 @@
+
+
+
+
+
+
+Network Working Group                                           A. Kumar
+Request for Comments: 1536                                     J. Postel
+Category: Informational                                        C. Neuman
+                                                                     ISI
+                                                               P. Danzig
+                                                               S. Miller
+                                                                     USC
+                                                            October 1993
+
+
+          Common DNS Implementation Errors and Suggested Fixes
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard.  Distribution of this memo is
+   unlimited.
+
+Abstract
+
+   This memo describes common errors seen in DNS implementations and
+   suggests some fixes. Where applicable, violations of recommendations
+   from STD 13, RFC 1034 and STD 13, RFC 1035 are mentioned. The memo
+   also describes, where relevant, the algorithms followed in BIND
+   (versions 4.8.3 and 4.9 which the authors referred to) to serve as an
+   example.
+
+Introduction
+
+   The last few years have seen, virtually, an explosion of DNS traffic
+   on the NSFnet backbone. Various DNS implementations and various
+   versions of these implementations interact with each other, producing
+   huge amounts of unnecessary traffic. Attempts are being made by
+   researchers all over the internet, to document the nature of these
+   interactions, the symptomatic traffic patterns and to devise remedies
+   for the sick pieces of software.
+
+   This draft is an attempt to document fixes for known DNS problems so
+   people know what problems to watch out for and how to repair broken
+   software.
+
+1. Fast Retransmissions
+
+   DNS implements the classic request-response scheme of client-server
+   interaction. UDP is, therefore, the chosen protocol for communication
+   though TCP is used for zone transfers. The onus of requerying in case
+   no response is seen in a "reasonable" period of time, lies with the
+   client. Although RFC 1034 and 1035 do not recommend any
+
+
+
+Kumar, Postel, Neuman, Danzig & Miller                          [Page 1]
+
+RFC 1536            Common DNS Implementation Errors        October 1993
+
+
+   retransmission policy, RFC 1035 does recommend that the resolvers
+   should cycle through a list of servers. Both name servers and stub
+   resolvers should, therefore, implement some kind of a retransmission
+   policy based on round trip time estimates of the name servers. The
+   client should back-off exponentially, probably to a maximum timeout
+   value.
+
+   However, clients might not implement either of the two. They might
+   not wait a sufficient amount of time before retransmitting or they
+   might not back-off their inter-query times sufficiently.
+
+   Thus, what the server would see will be a series of queries from the
+   same querying entity, spaced very close together. Of course, a
+   correctly implemented server discards all duplicate queries but the
+   queries contribute to wide-area traffic, nevertheless.
+
+   We classify a retransmission of a query as a pure Fast retry timeout
+   problem when a series of query packets meet the following conditions.
+
+      a. Query packets are seen within a time less than a "reasonable
+         waiting period" of each other.
+
+      b. No response to the original query was seen i.e., we see two or
+         more queries, back to back.
+
+      c. The query packets share the same query identifier.
+
+      d. The server eventually responds to the query.
+
+A GOOD IMPLEMENTATION:
+
+   BIND (we looked at versions 4.8.3 and 4.9) implements a good
+   retransmission algorithm which solves or limits all of these
+   problems.  The Berkeley stub-resolver queries servers at an interval
+   that starts at the greater of 4 seconds and 5 seconds divided by the
+   number of servers the resolver queries. The resolver cycles through
+   servers and at the end of a cycle, backs off the time out
+   exponentially.
+
+   The Berkeley full-service resolver (built in with the program
+   "named") starts with a time-out equal to the greater of 4 seconds and
+   two times the round-trip time estimate of the server.  The time-out
+   is backed off with each cycle, exponentially, to a ceiling value of
+   45 seconds.
+
+
+
+
+
+
+
+Kumar, Postel, Neuman, Danzig & Miller                          [Page 2]
+
+RFC 1536            Common DNS Implementation Errors        October 1993
+
+
+FIXES:
+
+      a. Estimate round-trip times or set a reasonably high initial
+         time-out.
+
+      b. Back-off timeout periods exponentially.
+
+      c. Yet another fundamental though difficult fix is to send the
+         client an acknowledgement of a query, with a round-trip time
+         estimate.
+
+   Since UDP is used, no response is expected by the client until the
+   query is complete.  Thus, it is less likely to have information about
+   previous packets on which to estimate its back-off time.  Unless, you
+   maintain state across queries, so subsequent queries to the same
+   server use information from previous queries.  Unfortunately, such
+   estimates are likely to be inaccurate for chained requests since the
+   variance is likely to be high.
+
+   The fix chosen in the ARDP library used by Prospero is that the
+   server will send an initial acknowledgement to the client in those
+   cases where the server expects the query to take a long time (as
+   might be the case for chained queries).  This initial acknowledgement
+   can include an expected time to wait before retrying.
+
+   This fix is more difficult since it requires that the client software
+   also be trained to expect the acknowledgement packet. This, in an
+   internet of millions of hosts is at best a hard problem.
+
+2. Recursion Bugs
+
+   When a server receives a client request, it first looks up its zone
+   data and the cache to check if the query can be answered. If the
+   answer is unavailable in either place, the server seeks names of
+   servers that are more likely to have the information, in its cache or
+   zone data. It then does one of two things. If the client desires the
+   server to recurse and the server architecture allows recursion, the
+   server chains this request to these known servers closest to the
+   queried name. If the client doesn't seek recursion or if the server
+   cannot handle recursion, it returns the list of name servers to the
+   client assuming the client knows what to do with these records.
+
+   The client queries this new list of name servers to get either the
+   answer, or names of another set of name servers to query. This
+   process repeats until the client is satisfied. Servers might also go
+   through this chaining process if the server returns a CNAME record
+   for the queried name. Some servers reprocess this name to try and get
+   the desired record type.
+
+
+
+Kumar, Postel, Neuman, Danzig & Miller                          [Page 3]
+
+RFC 1536            Common DNS Implementation Errors        October 1993
+
+
+   However, in certain cases, this chain of events may not be good. For
+   example, a broken or malicious name server might list itself as one
+   of the name servers to query again. The unsuspecting client resends
+   the same query to the same server.
+
+   In another situation, more difficult to detect, a set of servers
+   might form a loop wherein A refers to B and B refers to A. This loop
+   might involve more than two servers.
+
+   Yet another error is where the client does not know how to process
+   the list of name servers returned, and requeries the same server
+   since that is one (of the few) servers it knows.
+
+   We, therefore, classify recursion bugs into three distinct
+   categories:
+
+      a. Ignored referral: Client did not know how to handle NS records
+         in the AUTHORITY section.
+
+      b. Too many referrals: Client called on a server too many times,
+         beyond a "reasonable" number, with same query. This is
+         different from a Fast retransmission problem and a Server
+         Failure detection problem in that a response is seen for every
+         query.  Also, the identifiers are always different. It implies
+         client is in a loop and should have detected that and broken
+         it.  (RFC 1035 mentions that client should not recurse beyond
+         a certain depth.)
+
+      c. Malicious Server: a server refers to itself in the authority
+         section. If a server does not have an answer now, it is very
+         unlikely it will be any better the next time you query it,
+         specially when it claims to be authoritative over a domain.
+
+      RFC 1034 warns against such situations, on page 35.
+
+      "Bound the amount of work (packets sent, parallel processes
+       started) so that a request can't get into an infinite loop or
+       start off a chain reaction of requests or queries with other
+       implementations EVEN IF SOMEONE HAS INCORRECTLY CONFIGURED
+       SOME DATA."
+
+A GOOD IMPLEMENTATION:
+
+   BIND fixes at least one of these problems. It places an upper limit
+   on the number of recursive queries it will make, to answer a
+   question.  It chases a maximum of 20 referral links and 8 canonical
+   name translations.
+
+
+
+
+Kumar, Postel, Neuman, Danzig & Miller                          [Page 4]
+
+RFC 1536            Common DNS Implementation Errors        October 1993
+
+
+FIXES:
+
+      a. Set an upper limit on the number of referral links and CNAME
+         links you are willing to chase.
+
+         Note that this is not guaranteed to break only recursion loops.
+         It could, in a rare case, prune off a very long search path,
+         prematurely.  We know, however, with high probability, that if
+         the number of links cross a certain metric (two times the depth
+         of the DNS tree), it is a recursion problem.
+
+      b. Watch out for self-referring servers. Avoid them whenever
+         possible.
+
+      c. Make sure you never pass off an authority NS record with your
+         own name on it!
+
+      d. Fix clients to accept iterative answers from servers not built
+         to provide recursion. Such clients should either be happy with
+         the non-authoritative answer or be willing to chase the
+         referral links themselves.
+
+3. Zero Answer Bugs:
+
+   Name servers sometimes return an authoritative NOERROR with no
+   ANSWER, AUTHORITY or ADDITIONAL records. This happens when the
+   queried name is valid but it does not have a record of the desired
+   type. Of course, the server has authority over the domain.
+
+   However, once again, some implementations of resolvers do not
+   interpret this kind of a response reasonably. They always expect an
+   answer record when they see an authoritative NOERROR. These entities
+   continue to resend their queries, possibly endlessly.
+
+A GOOD IMPLEMENTATION
+
+   BIND resolver code does not query a server more than 3 times. If it
+   is unable to get an answer from 4 servers, querying them three times
+   each, it returns error.
+
+   Of course, it treats a zero-answer response the way it should be
+   treated; with respect!
+
+FIXES:
+
+      a. Set an upper limit on the number of retransmissions for a given
+         query, at the very least.
+
+
+
+
+Kumar, Postel, Neuman, Danzig & Miller                          [Page 5]
+
+RFC 1536            Common DNS Implementation Errors        October 1993
+
+
+      b. Fix resolvers to interpret such a response as an authoritative
+         statement of non-existence of the record type for the given
+         name.
+
+4. Inability to detect server failure:
+
+   Servers in the internet are not very reliable (they go down every
+   once in a while) and resolvers are expected to adapt to the changed
+   scenario by not querying the server for a while. Thus, when a server
+   does not respond to a query, resolvers should try another server.
+   Also, non-stub resolvers should update their round trip time estimate
+   for the server to a large value so that server is not tried again
+   before other, faster servers.
+
+   Stub resolvers, however, cycle through a fixed set of servers and if,
+   unfortunately, a server is down while others do not respond for other
+   reasons (high load, recursive resolution of query is taking more time
+   than the resolver's time-out, ....), the resolver queries the dead
+   server again! In fact, some resolvers might not set an upper limit on
+   the number of query retransmissions they will send and continue to
+   query dead servers indefinitely.
+
+   Name servers running system or chained queries might also suffer from
+   the same problem. They store names of servers they should query for a
+   given domain. They cycle through these names and in case none of them
+   answers, hit each one more than one. It is, once again, important
+   that there be an upper limit on the number of retransmissions, to
+   prevent network overload.
+
+   This behavior is clearly in violation of the dictum in RFC 1035 (page
+   46)
+
+      "If a resolver gets a server error or other bizarre response
+       from a name server, it should remove it from SLIST, and may
+       wish to schedule an immediate transmission to the next
+       candidate server address."
+
+   Removal from SLIST implies that the server is not queried again for
+   some time.
+
+   Correctly implemented full-service resolvers should, as pointed out
+   before, update round trip time values for servers that do not respond
+   and query them only after other, good servers. Full-service resolvers
+   might, however, not follow any of these common sense directives. They
+   query dead servers, and they query them endlessly.
+
+
+
+
+
+
+Kumar, Postel, Neuman, Danzig & Miller                          [Page 6]
+
+RFC 1536            Common DNS Implementation Errors        October 1993
+
+
+A GOOD IMPLEMENTATION:
+
+   BIND places an upper limit on the number of times it queries a
+   server.  Both the stub-resolver and the full-service resolver code do
+   this.  Also, since the full-service resolver estimates round-trip
+   times and sorts name server addresses by these estimates, it does not
+   query a dead server again, until and unless all the other servers in
+   the list are dead too!  Further, BIND implements exponential back-off
+   too.
+
+FIXES:
+
+      a. Set an upper limit on number of retransmissions.
+
+      b. Measure round-trip time from servers (some estimate is better
+         than none). Treat no response as a "very large" round-trip
+         time.
+
+      c. Maintain a weighted rtt estimate and decay the "large" value
+         slowly, with time, so that the server is eventually tested
+         again, but not after an indefinitely long period.
+
+      d. Follow an exponential back-off scheme so that even if you do
+         not restrict the number of queries, you do not overload the
+         net excessively.
+
+5. Cache Leaks:
+
+   Every resource record returned by a server is cached for TTL seconds,
+   where the TTL value is returned with the RR. Full-service (or stub)
+   resolvers cache the RR and answer any queries based on this cached
+   information, in the future, until the TTL expires. After that, one
+   more query to the wide-area network gets the RR in cache again.
+
+   Full-service resolvers might not implement this caching mechanism
+   well. They might impose a limit on the cache size or might not
+   interpret the TTL value correctly. In either case, queries repeated
+   within a TTL period of a RR constitute a cache leak.
+
+A GOOD/BAD IMPLEMENTATION:
+
+   BIND has no restriction on the cache size and the size is governed by
+   the limits on the virtual address space of the machine it is running
+   on. BIND caches RRs for the duration of the TTL returned with each
+   record.
+
+   It does, however, not follow the RFCs with respect to interpretation
+   of a 0 TTL value. If a record has a TTL value of 0 seconds, BIND uses
+
+
+
+Kumar, Postel, Neuman, Danzig & Miller                          [Page 7]
+
+RFC 1536            Common DNS Implementation Errors        October 1993
+
+
+   the minimum TTL value, for that zone, from the SOA record and caches
+   it for that duration. This, though it saves some traffic on the
+   wide-area network, is not correct behavior.
+
+FIXES:
+
+      a. Look over your caching mechanism to ensure TTLs are interpreted
+         correctly.
+
+      b. Do not restrict cache sizes (come on, memory is cheap!).
+         Expired entries are reclaimed periodically, anyway. Of course,
+         the cache size is bound to have some physical limit. But, when
+         possible, this limit should be large (run your name server on
+         a machine with a large amount of physical memory).
+
+      c. Possibly, a mechanism is needed to flush the cache, when it is
+         known or even suspected that the information has changed.
+
+6. Name Error Bugs:
+
+   This bug is very similar to the Zero Answer bug. A server returns an
+   authoritative NXDOMAIN when the queried name is known to be bad, by
+   the server authoritative for the domain, in the absence of negative
+   caching. This authoritative NXDOMAIN response is usually accompanied
+   by the SOA record for the domain, in the authority section.
+
+   Resolvers should recognize that the name they queried for was a bad
+   name and should stop querying further.
+
+   Some resolvers might, however, not interpret this correctly and
+   continue to query servers, expecting an answer record.
+
+   Some applications, in fact, prompt NXDOMAIN answers! When given a
+   perfectly good name to resolve, they append the local domain to it
+   e.g., an application in the domain "foo.bar.com", when trying to
+   resolve the name "usc.edu" first tries "usc.edu.foo.bar.com", then
+   "usc.edu.bar.com" and finally the good name "usc.edu". This causes at
+   least two queries that return NXDOMAIN, for every good query. The
+   problem is aggravated since the negative answers from the previous
+   queries are not cached.  When the same name is sought again, the
+   process repeats.
+
+   Some DNS resolver implementations suffer from this problem, too. They
+   append successive sub-parts of the local domain using an implicit
+   searchlist mechanism, when certain conditions are satisfied and try
+   the original name, only when this first set of iterations fails. This
+   behavior recently caused pandemonium in the Internet when the domain
+   "edu.com" was registered and a wildcard "CNAME" record placed at the
+
+
+
+Kumar, Postel, Neuman, Danzig & Miller                          [Page 8]
+
+RFC 1536            Common DNS Implementation Errors        October 1993
+
+
+   top level. All machines from "com" domains trying to connect to hosts
+   in the "edu" domain ended up with connections to the local machine in
+   the "edu.com" domain!
+
+GOOD/BAD IMPLEMENTATIONS:
+
+   Some local versions of BIND already implement negative caching. They
+   typically cache negative answers with a very small TTL, sufficient to
+   answer a burst of queries spaced close together, as is typically
+   seen.
+
+   The next official public release of BIND (4.9.2) will have negative
+   caching as an ifdef'd feature.
+
+   The BIND resolver appends local domain to the given name, when one of
+   two conditions is met:
+
+      i.  The name has no periods and the flag RES_DEFNAME is set.
+      ii. There is no trailing period and the flag RES_DNSRCH is set.
+
+   The flags RES_DEFNAME and RES_DNSRCH are default resolver options, in
+   BIND, but can be changed at compile time.
+
+   Only if the name, so generated, returns an NXDOMAIN is the original
+   name tried as a Fully Qualified Domain Name. And only if it contains
+   at least one period.
+
+FIXES:
+
+      a. Fix the resolver code.
+
+      b. Negative Caching. Negative caching servers will restrict the
+         traffic seen on the wide-area network, even if not curb it
+         altogether.
+
+      c. Applications and resolvers should not append the local domain to
+         names they seek to resolve, as far as possible. Names
+         interspersed with periods should be treated as Fully Qualified
+         Domain Names.
+
+         In other words, Use searchlists only when explicitly specified.
+         No implicit searchlists should be used. A name that contains
+         any dots should first be tried as a FQDN and if that fails, with
+         the local domain name (or searchlist if specified) appended. A
+         name containing no dots can be appended with the searchlist right
+         away, but once again, no implicit searchlists should be used.
+
+
+
+
+
+Kumar, Postel, Neuman, Danzig & Miller                          [Page 9]
+
+RFC 1536            Common DNS Implementation Errors        October 1993
+
+
+   Associated with the name error bug is another problem where a server
+   might return an authoritative NXDOMAIN, although the name is valid. A
+   secondary server, on start-up, reads the zone information from the
+   primary, through a zone transfer. While it is in the process of
+   loading the zones, it does not have information about them, although
+   it is authoritative for them.  Thus, any query for a name in that
+   domain is answered with an NXDOMAIN response code. This problem might
+   not be disastrous were it not for negative caching servers that cache
+   this answer and so propagate incorrect information over the internet.
+
+BAD IMPLEMENTATION:
+
+   BIND apparently suffers from this problem.
+
+   Also, a new name added to the primary database will take a while to
+   propagate to the secondaries. Until that time, they will return
+   NXDOMAIN answers for a good name. Negative caching servers store this
+   answer, too and aggravate this problem further. This is probably a
+   more general DNS problem but is apparently more harmful in this
+   situation.
+
+FIX:
+
+      a. Servers should start answering only after loading all the zone
+         data. A failed server is better than a server handing out
+         incorrect information.
+
+      b. Negative cache records for a very small time, sufficient only
+         to ward off a burst of requests for the same bad name. This
+         could be related to the round-trip time of the server from
+         which the negative answer was received. Alternatively, a
+         statistical measure of the amount of time for which queries
+         for such names are received could be used. Minimum TTL value
+         from the SOA record is not advisable since they tend to be
+         pretty large.
+
+      c. A "PUSH" (or, at least, a "NOTIFY") mechanism should be allowed
+         and implemented, to allow the primary server to inform
+         secondaries that the database has been modified since it last
+         transferred zone data.  To alleviate the problem of "too many
+         zone transfers" that this might cause, Incremental Zone
+         Transfers should also be part of DNS.  Also, the primary should
+         not NOTIFY/PUSH with every update but bunch a good number
+         together.
+
+
+
+
+
+
+
+Kumar, Postel, Neuman, Danzig & Miller                         [Page 10]
+
+RFC 1536            Common DNS Implementation Errors        October 1993
+
+
+7. Format Errors:
+
+   Some resolvers issue query packets that do not necessarily conform to
+   standards as laid out in the relevant RFCs. This unnecessarily
+   increases net traffic and wastes server time.
+
+FIXES:
+
+      a. Fix resolvers.
+
+      b. Each resolver verify format of packets before sending them out,
+         using a mechanism outside of the resolver. This is, obviously,
+         needed only if step 1 cannot be followed.
+
+References
+
+   [1] Mockapetris, P., "Domain Names Concepts and Facilities", STD 13,
+       RFC 1034, USC/Information Sciences Institute, November 1987.
+
+   [2] Mockapetris, P., "Domain Names Implementation and Specification",
+       STD 13, RFC 1035, USC/Information Sciences Institute, November
+       1987.
+
+   [3] Partridge, C., "Mail Routing and the Domain System", STD 14, RFC
+       974, CSNET CIC BBN, January 1986.
+
+   [4] Gavron, E., "A Security Problem and Proposed Correction With
+       Widely Deployed DNS Software", RFC 1535, ACES Research Inc.,
+       October 1993.
+
+   [5] Beertema, P., "Common DNS Data File Configuration Errors", RFC
+       1537, CWI, October 1993.
+
+Security Considerations
+
+   Security issues are not discussed in this memo.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kumar, Postel, Neuman, Danzig & Miller                         [Page 11]
+
+RFC 1536            Common DNS Implementation Errors        October 1993
+
+
+Authors' Addresses
+
+   Anant Kumar
+   USC Information Sciences Institute
+   4676 Admiralty Way
+   Marina Del Rey CA 90292-6695
+
+   Phone:(310) 822-1511
+   FAX:  (310) 823-6741
+   EMail: anant@isi.edu
+
+
+   Jon Postel
+   USC Information Sciences Institute
+   4676 Admiralty Way
+   Marina Del Rey CA 90292-6695
+
+   Phone:(310) 822-1511
+   FAX:  (310) 823-6714
+   EMail: postel@isi.edu
+
+
+   Cliff Neuman
+   USC Information Sciences Institute
+   4676 Admiralty Way
+   Marina Del Rey CA 90292-6695
+
+   Phone:(310) 822-1511
+   FAX:  (310) 823-6714
+   EMail: bcn@isi.edu
+
+
+   Peter Danzig
+   Computer Science Department
+   University of Southern California
+   University Park
+
+   EMail: danzig@caldera.usc.edu
+
+
+   Steve Miller
+   Computer Science Department
+   University of Southern California
+   University Park
+   Los Angeles CA 90089
+
+   EMail: smiller@caldera.usc.edu
+
+
+
+
+Kumar, Postel, Neuman, Danzig & Miller                         [Page 12]
+
diff --git a/doc/rfc/rfc1537.txt b/doc/rfc/rfc1537.txt
new file mode 100644
index 0000000..81b9768
--- /dev/null
+++ b/doc/rfc/rfc1537.txt
@@ -0,0 +1,507 @@
+
+
+
+
+
+
+Network Working Group                                        P. Beertema
+Request for Comments: 1537                                           CWI
+Category: Informational                                     October 1993
+
+
+               Common DNS Data File Configuration Errors
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard.  Distribution of this memo is
+   unlimited.
+
+Abstract
+
+   This memo describes errors often found in DNS data files. It points
+   out common mistakes system administrators tend to make and why they
+   often go unnoticed for long periods of time.
+
+Introduction
+
+   Due to the lack of extensive documentation and automated tools, DNS
+   zone files have mostly been configured by system administrators, by
+   hand. Some of the rules for writing the data files are rather subtle
+   and a few common mistakes are seen in domains worldwide.
+
+   This document is an attempt to list "surprises" that administrators
+   might find hidden in their zone files. It describes the symptoms of
+   the malady and prescribes medicine to cure that. It also gives some
+   general recommendations and advice on specific nameserver and zone
+   file issues and on the (proper) use of the Domain Name System.
+
+1. SOA records
+
+   A problem I've found in quite some nameservers is that the various
+   timers have been set (far) too low. Especially for top level domain
+   nameservers this causes unnecessary traffic over international and
+   intercontinental links.
+
+   Unfortunately the examples given in the BIND manual, in RFC's and in
+   some expert documents give those very short timer values, and that's
+   most likely what people have modeled their SOA records after.
+
+   First of all a short explanation of the timers used in the SOA
+   record:
+
+
+
+
+
+
+Beertema                                                        [Page 1]
+
+RFC 1537       Common DNS Data File Configuration Errors    October 1993
+
+
+        - Refresh: The SOA record of the primary server is checked
+                   every "refresh" time by the secondary servers;
+                   if it has changed, a zone transfer is done.
+
+        - Retry: If a secondary server cannot reach the primary
+                 server, it tries it again every "retry" time.
+
+        - Expire: If for "expire" time the primary server cannot
+                  be reached, all information about the zone is
+                  invalidated on the secondary servers (i.e., they
+                  are no longer authoritative for that zone).
+
+        - Minimum TTL: The default TTL value for all records in the
+                       zone file; a different TTL value may be given
+                       explicitly in a record when necessary.
+                       (This timer is named "Minimum", and that's
+                       what it's function should be according to
+                       STD 13, RFC 1035, but most (all?)
+                       implementations take it as the default value
+                       exported with records without an explicit TTL
+                       value).
+
+   For top level domain servers I would recommend the following values:
+
+          86400 ; Refresh     24 hours
+           7200 ; Retry        2 hours
+        2592000 ; Expire      30 days
+         345600 ; Minimum TTL  4 days
+
+   For other servers I would suggest:
+
+          28800 ; Refresh     8 hours
+           7200 ; Retry       2 hours
+         604800 ; Expire      7 days
+          86400 ; Minimum TTL 1 day
+
+   but here the frequency of changes, the required speed of propagation,
+   the reachability of the primary server etc. play a role in optimizing
+   the timer values.
+
+2. Glue records
+
+   Quite often, people put unnecessary glue (A) records in their zone
+   files. Even worse is that I've even seen *wrong* glue records for an
+   external host in a primary zone file! Glue records need only be in a
+   zone file if the server host is within the zone and there is no A
+   record for that host elsewhere in the zone file.
+
+
+
+
+Beertema                                                        [Page 2]
+
+RFC 1537       Common DNS Data File Configuration Errors    October 1993
+
+
+   Old BIND versions ("native" 4.8.3 and older versions) showed the
+   problem that wrong glue records could enter secondary servers in a
+   zone transfer.
+
+3. "Secondary server surprise"
+
+   I've seen it happen on various occasions that hosts got bombarded by
+   nameserver requests without knowing why. On investigation it turned
+   out then that such a host was supposed to (i.e., the information was
+   in the root servers) run secondary for some domain (or reverse (in-
+   addr.arpa)) domain, without that host's nameserver manager having
+   been asked or even been told so!
+
+   Newer BIND versions (4.9 and later) solved this problem.  At the same
+   time though the fix has the disadvantage that it's far less easy to
+   spot this problem.
+
+   Practice has shown that most domain registrars accept registrations
+   of nameservers without checking if primary (!) and secondary servers
+   have been set up, informed, or even asked.  It should also be noted
+   that a combination of long-lasting unreachability of primary
+   nameservers, (therefore) expiration of zone information, plus static
+   IP routing, can lead to massive network traffic that can fill up
+   lines completely.
+
+4. "MX records surprise"
+
+   In a sense similar to point 3. Sometimes nameserver managers enter MX
+   records in their zone files that point to external hosts, without
+   first asking or even informing the systems managers of those external
+   hosts.  This has to be fought out between the nameserver manager and
+   the systems managers involved. Only as a last resort, if really
+   nothing helps to get the offending records removed, can the systems
+   manager turn to the naming authority of the domain above the
+   offending domain to get the problem sorted out.
+
+5. "Name extension surprise"
+
+   Sometimes one encounters weird names, which appear to be an external
+   name extended with a local domain. This is caused by forgetting to
+   terminate a name with a dot: names in zone files that don't end with
+   a dot are always expanded with the name of the current zone (the
+   domain that the zone file stands for or the last $ORIGIN).
+
+   Example: zone file for foo.xx:
+
+   pqr          MX 100  relay.yy.
+   xyz          MX 100  relay.yy           (no trailing dot!)
+
+
+
+Beertema                                                        [Page 3]
+
+RFC 1537       Common DNS Data File Configuration Errors    October 1993
+
+
+   When fully written out this stands for:
+
+      pqr.foo.xx.  MX 100  relay.yy.
+      xyz.foo.xx.  MX 100  relay.yy.foo.xx.   (name extension!)
+
+6. Missing secondary servers
+
+   It is required that there be a least 2 nameservers for a domain. For
+   obvious reasons the nameservers for top level domains need to be very
+   well reachable from all over the Internet. This implies that there
+   must be more than just 2 of them; besides, most of the (secondary)
+   servers should be placed at "strategic" locations, e.g., close to a
+   point where international and/or intercontinental lines come
+   together.  To keep things manageable, there shouldn't be too many
+   servers for a domain either.
+
+   Important aspects in selecting the location of primary and secondary
+   servers are reliability (network, host) and expedient contacts: in
+   case of problems, changes/fixes must be carried out quickly.  It
+   should be considered logical that primary servers for European top
+   level domains should run on a host in Europe, preferably (if
+   possible) in the country itself. For each top level domain there
+   should be 2 secondary servers in Europe and 2 in the USA, but there
+   may of course be more on either side.  An excessive number of
+   nameservers is not a good idea though; a recommended maximum is 7
+   nameservers.  In Europe, EUnet has offered to run secondary server
+   for each European top level domain.
+
+7. Wildcard MX records
+
+   Wildcard MX records should be avoided where possible. They often
+   cause confusion and errors: especially beginning nameserver managers
+   tend to overlook the fact that a host/domain listed with ANY type of
+   record in a zone file is NOT covered by an overall wildcard MX record
+   in that zone; this goes not only for simple domain/host names, but
+   also for names that cover one or more domains. Take the following
+   example in zone foo.bar:
+
+         *            MX 100  mailhost
+         pqr          MX 100  mailhost
+         abc.def      MX 100  mailhost
+
+   This makes pqr.foo.bar, def.foo.bar and abd.def.foo.bar valid
+   domains, but the wildcard MX record covers NONE of them, nor anything
+   below them.  To cover everything by MX records, the required entries
+   are:
+
+
+
+
+
+Beertema                                                        [Page 4]
+
+RFC 1537       Common DNS Data File Configuration Errors    October 1993
+
+
+         *            MX 100  mailhost
+         pqr          MX 100  mailhost
+         *.pqr        MX 100  mailhost
+         abc.def      MX 100  mailhost
+         *.def        MX 100  mailhost
+         *.abc.def    MX 100  mailhost
+
+   An overall wildcard MX record is almost never useful.
+
+   In particular the zone file of a top level domain should NEVER
+   contain only an overall wildcard MX record (*.XX). The effect of such
+   a wildcard MX record can be that mail is unnecessarily sent across
+   possibly expensive links, only to fail at the destination or gateway
+   that the record points to. Top level domain zone files should
+   explicitly list at least all the officially registered primary
+   subdomains.
+
+   Whereas overall wildcard MX records should be avoided, wildcard MX
+   records are acceptable as an explicit part of subdomain entries,
+   provided they are allowed under a given subdomain (to be determined
+   by the naming authority for that domain).
+
+   Example:
+
+         foo.xx.      MX 100  gateway.xx.
+                      MX 200  fallback.yy.
+         *.foo.xx.    MX 100  gateway.xx.
+                      MX 200  fallback.yy.
+8. Hostnames
+
+   People appear to sometimes look only at STD 11, RFC 822 to determine
+   whether a particular hostname is correct or not. Hostnames should
+   strictly conform to the syntax given in STD 13, RFC 1034 (page 11),
+   with *addresses* in addition conforming to RFC 822. As an example
+   take "c&w.blues" which is perfectly legal according to RFC 822, but
+   which can have quite surprising effects on particular systems, e.g.,
+   "telnet c&w.blues" on a Unix system.
+
+9. HINFO records
+
+   There appears to be a common misunderstanding that one of the data
+   fields (usually the second field) in HINFO records is optional. A
+   recent scan of all reachable nameservers in only one country revealed
+   some 300 incomplete HINFO records. Specifying two data fields in a
+   HINFO record is mandatory (RFC 1033), but note that this does *not*
+   mean that HINFO records themselves are mandatory.
+
+
+
+
+
+Beertema                                                        [Page 5]
+
+RFC 1537       Common DNS Data File Configuration Errors    October 1993
+
+
+10. Safety measures and specialties
+
+   Nameservers and resolvers aren't flawless. Bogus queries should be
+   kept from being forwarded to the root servers, since they'll only
+   lead to unnecessary intercontinental traffic. Known bogus queries
+   that can easily be dealt with locally are queries for 0 and broadcast
+   addresses.  To catch such queries, every nameserver should run
+   primary for the 0.in-addr.arpa and 255.in-addr.arpa zones; the zone
+   files need only contain a SOA and an NS record.
+
+   Also each nameserver should run primary for 0.0.127.in-addr.arpa;
+   that zone file should contain a SOA and NS record and an entry:
+
+         1    PTR     localhost.
+
+   There has been extensive discussion about whether or not to append
+   the local domain to it. The conclusion was that "localhost." would be
+   the best solution; reasons given were:
+
+   - "localhost" itself is used and expected to work on some systems.
+
+   - translating 127.0.0.1 into "localhost.my_domain" can cause some
+     software to connect to itself using the loopback interface when
+     it didn't want to.
+
+   Note that all domains that contain hosts should have a "localhost" A
+   record in them.
+
+   People maintaining zone files with the Serial number given in dotted
+   decimal notation (e.g., when SCCS is used to maintain the files)
+   should beware of a bug in all BIND versions: if the serial number is
+   in Release.Version (dotted decimal) notation, then it is virtually
+   impossible to change to a higher release: because of the wrong way
+   that notation is turned into an integer, it results in a serial
+   number that is LOWER than that of the former release.
+
+   For this reason and because the Serial is an (unsigned) integer
+   according to STD 13, RFC 1035, it is recommended not to use the
+   dotted decimal notation. A recommended notation is to use the date
+   (yyyymmdd), if necessary with an extra digit (yyyymmddn) if there is
+   or can be more than one change per day in a zone file.
+
+   Very old versions of DNS resolver code have a bug that causes queries
+   for A records with domain names like "192.16.184.3" to go out. This
+   happens when users type in IP addresses and the resolver code does
+   not catch this case before sending out a DNS query. This problem has
+   been fixed in all resolver implementations known to us but if it
+   still pops up it is very serious because all those queries will go to
+
+
+
+Beertema                                                        [Page 6]
+
+RFC 1537       Common DNS Data File Configuration Errors    October 1993
+
+
+   the root servers looking for top level domains like "3" etc. It is
+   strongly recommended to install the latest (publicly) available BIND
+   version plus all available patches to get rid of these and other
+   problems.
+
+   Running secondary nameserver off another secondary nameserver is
+   possible, but not recommended unless really necessary: there are
+   known cases where it has led to problems like bogus TTL values. This
+   can be caused by older or flawed implementations, but secondary
+   nameservers in principle should always transfer their zones from the
+   official primary nameserver.
+
+11. Some general points
+
+   The Domain Name System and nameserver are purely technical tools, not
+   meant in any way to exert control or impose politics. The function of
+   a naming authority is that of a clearing house. Anyone registering a
+   subdomain under a particular (top level) domain becomes naming
+   authority and therewith the sole responsible for that subdomain.
+   Requests to enter MX or NS records concerning such a subdomain
+   therefore always MUST be honored by the registrar of the next higher
+   domain.
+
+   Examples of practices that are not allowed are:
+
+      - imposing specific mail routing (MX records) when registering
+        a subdomain.
+
+      - making registration of a subdomain dependent on to the use of
+        certain networks or services.
+
+      - using TXT records as a means of (free) commercial advertising.
+
+   In the latter case a network service provider could decide to cut off
+   a particular site until the offending TXT records have been removed
+   from the site's zone file.
+
+   Of course there are obvious cases where a naming authority can refuse
+   to register a particular subdomain and can require a proposed name to
+   be changed in order to get it registered (think of DEC trying to
+   register a domain IBM.XX).
+
+   There are also cases were one has to probe the authority of the
+   person: sending in the application - not every systems manager should
+   be able to register a domain name for a whole university.  The naming
+   authority can impose certain extra rules as long as they don't
+   violate or conflict with the rights and interest of the registrars of
+   subdomains; a top level domain registrar may e.g., require that there
+
+
+
+Beertema                                                        [Page 7]
+
+RFC 1537       Common DNS Data File Configuration Errors    October 1993
+
+
+   be primary subdomain "ac" and "co" only and that subdomains be
+   registered under those primary subdomains.
+
+   The naming authority can also interfere in exceptional cases like the
+   one mentioned in point 4, e.g., by temporarily removing a domain's
+   entry from the nameserver zone files; this of course should be done
+   only with extreme care and only as a last resort.
+
+   When adding NS records for subdomains, top level domain nameserver
+   managers should realize that the people setting up the nameserver for
+   a subdomain often are rather inexperienced and can make mistakes that
+   can easily lead to the subdomain becoming completely unreachable or
+   that can cause unnecessary DNS traffic (see point 1). It is therefore
+   highly recommended that, prior to entering such an NS record, the
+   (top level) nameserver manager does a couple of sanity checks on the
+   new nameserver (SOA record and timers OK?, MX records present where
+   needed? No obvious errors made? Listed secondary servers
+   operational?). Things that cannot be caught though by such checks
+   are:
+
+      - resolvers set up to use external hosts as nameservers
+
+      - nameservers set up to use external hosts as forwarders
+        without permission from those hosts.
+
+   Care should also be taken when registering 2-letter subdomains.
+   Although this is allowed, an implication is that abbreviated
+   addressing (see STD 11, RFC 822, paragraph 6.2.2) is not possible in
+   and under that subdomain.  When requested to register such a domain,
+   one should always notify the people of this consequence. As an
+   example take the name "cs", which is commonly used for Computer
+   Science departments: it is also the name of the top level domain for
+   Czecho-Slovakia, so within the domain cs.foo.bar the user@host.cs is
+   ambiguous in that in can denote both a user on the host
+   host.cs.foo.bar and a user on the host "host" in Czecho-Slovakia.
+   (This example does not take into account the recent political changes
+   in the mentioned country).
+
+References
+
+   [1] Mockapetris, P., "Domain Names Concepts and Facilities", STD 13,
+       RFC 1034, USC/Information Sciences Institute, November 1987.
+
+   [2] Mockapetris, P., "Domain Names Implementation and Specification",
+       STD 13, RFC 1035, USC/Information Sciences Institute, November
+       1987.
+
+
+
+
+
+Beertema                                                        [Page 8]
+
+RFC 1537       Common DNS Data File Configuration Errors    October 1993
+
+
+   [3] Partridge, C., "Mail Routing and the Domain System", STD 14, RFC
+       974, CSNET CIC BBN, January 1986.
+
+   [4] Gavron, E., "A Security Problem and Proposed Correction With
+       Widely Deployed DNS Software", RFC 1535, ACES Research Inc.,
+       October 1993.
+
+   [5] Kumar, A., Postel, J., Neuman, C., Danzig, P., and S. Miller,
+       "Common DNS Implementation Errors and Suggested Fixes", RFC 1536,
+       USC/Information Sciences Institute, USC, October 1993.
+
+Security Considerations
+
+   Security issues are not discussed in this memo.
+
+Author's Address
+
+   Piet Beertema
+   CWI
+   Kruislaan 413
+   NL-1098 SJ Amsterdam
+   The Netherlands
+
+   Phone: +31 20 592 4112
+   FAX:   +31 20 592 4199
+   EMail: Piet.Beertema@cwi.nl
+
+
+Editor's Address
+
+   Anant Kumar
+   USC Information Sciences Institute
+   4676 Admiralty Way
+   Marina Del Rey CA 90292-6695
+
+   Phone:(310) 822-1511
+   FAX:  (310) 823-6741
+   EMail: anant@isi.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+Beertema                                                        [Page 9]
+
\ No newline at end of file
diff --git a/doc/rfc/rfc1591.txt b/doc/rfc/rfc1591.txt
new file mode 100644
index 0000000..89e0a25
--- /dev/null
+++ b/doc/rfc/rfc1591.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Network Working Group                                          J. Postel
+Request for Comments: 1591                                           ISI
+Category: Informational                                       March 1994
+
+
+              Domain Name System Structure and Delegation
+
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  This memo
+   does not specify an Internet standard of any kind.  Distribution of
+   this memo is unlimited.
+
+1. Introduction
+
+   This memo provides some information on the structure of the names in
+   the Domain Name System (DNS), specifically the top-level domain
+   names; and on the administration of domains.  The Internet Assigned
+   Numbers Authority (IANA) is the overall authority for the IP
+   Addresses, the Domain Names, and many other parameters, used in the
+   Internet.  The day-to-day responsibility for the assignment of IP
+   Addresses, Autonomous System Numbers, and most top and second level
+   Domain Names are handled by the Internet Registry (IR) and regional
+   registries.
+
+2.  The Top Level Structure of the Domain Names
+
+   In the Domain Name System (DNS) naming of computers there is a
+   hierarchy of names.  The root of system is unnamed.  There are a set
+   of what are called "top-level domain names" (TLDs).  These are the
+   generic TLDs (EDU, COM, NET, ORG, GOV, MIL, and INT), and the two
+   letter country codes from ISO-3166.  It is extremely unlikely that
+   any other TLDs will be created.
+
+   Under each TLD may be created a hierarchy of names.  Generally, under
+   the generic TLDs the structure is very flat.  That is, many
+   organizations are registered directly under the TLD, and any further
+   structure is up to the individual organizations.
+
+   In the country TLDs, there is a wide variation in the structure, in
+   some countries the structure is very flat, in others there is
+   substantial structural organization.  In some country domains the
+   second levels are generic categories (such as, AC, CO, GO, and RE),
+   in others they are based on political geography, and in still others,
+   organization names are listed directly under the country code.  The
+   organization for the US country domain is described in RFC 1480 [1].
+
+
+
+
+Postel                                                          [Page 1]
+
+RFC 1591      Domain Name System Structure and Delegation     March 1994
+
+
+   Each of the generic TLDs was created for a general category of
+   organizations.  The country code domains (for example, FR, NL, KR,
+   US) are each organized by an administrator for that country.  These
+   administrators may further delegate the management of portions of the
+   naming tree.  These administrators are performing a public service on
+   behalf of the Internet community.  Descriptions of the generic
+   domains and the US country domain follow.
+
+   Of these generic domains, five are international in nature, and two
+   are restricted to use by entities in the United States.
+
+   World Wide Generic Domains:
+
+   COM - This domain is intended for commercial entities, that is
+         companies.  This domain has grown very large and there is
+         concern about the administrative load and system performance if
+         the current growth pattern is continued.  Consideration is
+         being taken to subdivide the COM domain and only allow future
+         commercial registrations in the subdomains.
+
+   EDU - This domain was originally intended for all educational
+         institutions.  Many Universities, colleges, schools,
+         educational service organizations, and educational consortia
+         have registered here.  More recently a decision has been taken
+         to limit further registrations to 4 year colleges and
+         universities.  Schools and 2-year colleges will be registered
+         in the country domains (see US Domain, especially K12 and CC,
+         below).
+
+   NET - This domain is intended to hold only the computers of network
+         providers, that is the NIC and NOC computers, the
+         administrative computers, and the network node computers.  The
+         customers of the network provider would have domain names of
+         their own (not in the NET TLD).
+
+   ORG - This domain is intended as the miscellaneous TLD for
+         organizations that didn't fit anywhere else.  Some non-
+         government organizations may fit here.
+
+   INT - This domain is for organizations established by international
+         treaties, or international databases.
+
+   United States Only Generic Domains:
+
+   GOV - This domain was originally intended for any kind of government
+         office or agency.  More recently a decision was taken to
+         register only agencies of the US Federal government in this
+         domain.  State and local agencies are registered in the country
+
+
+
+Postel                                                          [Page 2]
+
+RFC 1591      Domain Name System Structure and Delegation     March 1994
+
+
+         domains (see US Domain, below).
+
+   MIL - This domain is used by the US military.
+
+   Example country code Domain:
+
+   US - As an example of a country domain, the US domain provides for
+        the registration of all kinds of entities in the United States
+        on the basis of political geography, that is, a hierarchy of
+        <entity-name>.<locality>.<state-code>.US.  For example,
+        "IBM.Armonk.NY.US".  In addition, branches of the US domain are
+        provided within each state for schools (K12), community colleges
+        (CC), technical schools (TEC), state government agencies
+        (STATE), councils of governments (COG),libraries (LIB), museums
+        (MUS), and several other generic types of entities (see RFC 1480
+        for details [1]).
+
+   To find a contact for a TLD use the "whois" program to access the
+   database on the host rs.internic.net.  Append "-dom" to the name of
+   TLD you are interested in.  For example:
+
+                       whois -h rs.internic.net us-dom
+      or
+                       whois -h rs.internic.net edu-dom
+
+3.  The Administration of Delegated Domains
+
+   The Internet Assigned Numbers Authority (IANA) is responsible for the
+   overall coordination and management of the Domain Name System (DNS),
+   and especially the delegation of portions of the name space called
+   top-level domains.  Most of these top-level domains are two-letter
+   country codes taken from the ISO standard 3166.
+
+   A central Internet Registry (IR) has been selected and designated to
+   handled the bulk of the day-to-day administration of the Domain Name
+   System.  Applications for new top-level domains (for example, country
+   code domains) are handled by the IR with consultation with the IANA.
+   The central IR is INTERNIC.NET.  Second level domains in COM, EDU,
+   ORG, NET, and GOV are registered by the Internet Registry at the
+   InterNIC.  The second level domains in the MIL are registered by the
+   DDN registry at NIC.DDN.MIL.  Second level names in INT are
+   registered by the PVM at ISI.EDU.
+
+   While all requests for new top-level domains must be sent to the
+   Internic (at hostmaster@internic.net), the regional registries are
+   often enlisted to assist in the administration of the DNS, especially
+   in solving problems with a country administration.  Currently, the
+   RIPE NCC is the regional registry for Europe and the APNIC is the
+
+
+
+Postel                                                          [Page 3]
+
+RFC 1591      Domain Name System Structure and Delegation     March 1994
+
+
+   regional registry for the Asia-Pacific region, while the INTERNIC
+   administers the North America region, and all the as yet undelegated
+   regions.
+
+      The contact mailboxes for these regional registries are:
+
+         INTERNIC        hostmaster@internic.net
+         APNIC           hostmaster@apnic.net
+         RIPE NCC        ncc@ripe.net
+
+   The policy concerns involved when a new top-level domain is
+   established are described in the following.  Also mentioned are
+   concerns raised when it is necessary to change the delegation of an
+   established domain from one party to another.
+
+   A new top-level domain is usually created and its management
+   delegated to a "designated manager" all at once.
+
+   Most of these same concerns are relevant when a sub-domain is
+   delegated and in general the principles described here apply
+   recursively to all delegations of the Internet DNS name space.
+
+   The major concern in selecting a designated manager for a domain is
+   that it be able to carry out the necessary responsibilities, and have
+   the ability to do a equitable, just, honest, and competent job.
+
+   1) The key requirement is that for each domain there be a designated
+      manager for supervising that domain's name space.  In the case of
+      top-level domains that are country codes this means that there is
+      a manager that supervises the domain names and operates the domain
+      name system in that country.
+
+      The manager must, of course, be on the Internet.  There must be
+      Internet Protocol (IP) connectivity to the nameservers and email
+      connectivity to the management and staff of the manager.
+
+      There must be an administrative contact and a technical contact
+      for each domain.  For top-level domains that are country codes at
+      least the administrative contact must reside in the country
+      involved.
+
+   2) These designated authorities are trustees for the delegated
+      domain, and have a duty to serve the community.
+
+      The designated manager is the trustee of the top-level domain for
+      both the nation, in the case of a country code, and the global
+      Internet community.
+
+
+
+
+Postel                                                          [Page 4]
+
+RFC 1591      Domain Name System Structure and Delegation     March 1994
+
+
+      Concerns about "rights" and "ownership" of domains are
+      inappropriate.  It is appropriate to be concerned about
+      "responsibilities" and "service" to the community.
+
+   3) The designated manager must be equitable to all groups in the
+      domain that request domain names.
+
+      This means that the same rules are applied to all requests, all
+      requests must be processed in a non-discriminatory fashion, and
+      academic and commercial (and other) users are treated on an equal
+      basis.  No bias shall be shown regarding requests that may come
+      from customers of some other business related to the manager --
+      e.g., no preferential service for customers of a particular data
+      network provider.  There can be no requirement that a particular
+      mail system (or other application), protocol, or product be used.
+
+      There are no requirements on subdomains of top-level domains
+      beyond the requirements on higher-level domains themselves.  That
+      is, the requirements in this memo are applied recursively.  In
+      particular, all subdomains shall be allowed to operate their own
+      domain name servers, providing in them whatever information the
+      subdomain manager sees fit (as long as it is true and correct).
+
+   4) Significantly interested parties in the domain should agree that
+      the designated manager is the appropriate party.
+
+      The IANA tries to have any contending parties reach agreement
+      among themselves, and generally takes no action to change things
+      unless all the contending parties agree; only in cases where the
+      designated manager has substantially mis-behaved would the IANA
+      step in.
+
+      However, it is also appropriate for interested parties to have
+      some voice in selecting the designated manager.
+
+      There are two cases where the IANA and the central IR may
+      establish a new top-level domain and delegate only a portion of
+      it: (1) there are contending parties that cannot agree, or (2) the
+      applying party may not be able to represent or serve the whole
+      country.  The later case sometimes arises when a party outside a
+      country is trying to be helpful in getting networking started in a
+      country -- this is sometimes called a "proxy" DNS service.
+
+      The Internet DNS Names Review Board (IDNB), a committee
+      established by the IANA, will act as a review panel for cases in
+      which the parties can not reach agreement among themselves.  The
+      IDNB's decisions will be binding.
+
+
+
+
+Postel                                                          [Page 5]
+
+RFC 1591      Domain Name System Structure and Delegation     March 1994
+
+
+   5) The designated manager must do a satisfactory job of operating the
+      DNS service for the domain.
+
+      That is, the actual management of the assigning of domain names,
+      delegating subdomains and operating nameservers must be done with
+      technical competence.  This includes keeping the central IR (in
+      the case of top-level domains) or other higher-level domain
+      manager advised of the status of the domain, responding to
+      requests in a timely manner, and operating the database with
+      accuracy, robustness, and resilience.
+
+      There must be a primary and a secondary nameserver that have IP
+      connectivity to the Internet and can be easily checked for
+      operational status and database accuracy by the IR and the IANA.
+
+      In cases when there are persistent problems with the proper
+      operation of a domain, the delegation may be revoked, and possibly
+      delegated to another designated manager.
+
+   6) For any transfer of the designated manager trusteeship from one
+      organization to another, the higher-level domain manager (the IANA
+      in the case of top-level domains) must receive communications from
+      both the old organization and the new organization that assure the
+      IANA that the transfer in mutually agreed, and that the new
+      organization understands its responsibilities.
+
+      It is also very helpful for the IANA to receive communications
+      from other parties that may be concerned or affected by the
+      transfer.
+
+4. Rights to Names
+
+   1) Names and Trademarks
+
+      In case of a dispute between domain name registrants as to the
+      rights to a particular name, the registration authority shall have
+      no role or responsibility other than to provide the contact
+      information to both parties.
+
+      The registration of a domain name does not have any Trademark
+      status.  It is up to the requestor to be sure he is not violating
+      anyone else's Trademark.
+
+   2) Country Codes
+
+      The IANA is not in the business of deciding what is and what is
+      not a country.
+
+
+
+
+Postel                                                          [Page 6]
+
+RFC 1591      Domain Name System Structure and Delegation     March 1994
+
+
+      The selection of the ISO 3166 list as a basis for country code
+      top-level domain names was made with the knowledge that ISO has a
+      procedure for determining which entities should be and should not
+      be on that list.
+
+5. Security Considerations
+
+   Security issues are not discussed in this memo.
+
+6. Acknowledgements
+
+   Many people have made comments on draft version of these descriptions
+   and procedures.  Steve Goldstein and John Klensin have been
+   particularly helpful.
+
+7. Author's Address
+
+   Jon Postel
+   USC/Information Sciences Institute
+   4676 Admiralty Way
+   Marina del Rey, CA  90292
+
+   Phone: 310-822-1511
+   Fax:   310-823-6714
+   EMail: Postel@ISI.EDU
+
+7. References
+
+   [1] Cooper, A., and J. Postel, "The US Domain", RFC 1480,
+       USC/Information Sciences Institute, June 1993.
+
+   [2] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340,
+       USC/Information Sciences Institute, July 1992.
+
+   [3] Mockapetris, P., "Domain Names - Concepts and Facilities", STD
+       13, RFC 1034, USC/Information Sciences Institute, November 1987.
+
+   [4] Mockapetris, P., "Domain Names - Implementation and
+       Specification", STD 13, RFC 1035, USC/Information Sciences
+       Institute, November 1987.
+
+   [6] Partridge, C., "Mail Routing and the Domain System", STD 14, RFC
+       974, CSNET CIC BBN, January 1986.
+
+   [7] Braden, R., Editor, "Requirements for Internet Hosts --
+       Application and Support", STD 3, RFC 1123, Internet Engineering
+       Task Force, October 1989.
+
+
+
+
+Postel                                                          [Page 7]
+
diff --git a/doc/rfc/rfc1611.txt b/doc/rfc/rfc1611.txt
new file mode 100644
index 0000000..ed5b93a
--- /dev/null
+++ b/doc/rfc/rfc1611.txt
@@ -0,0 +1,1683 @@
+
+
+
+
+
+
+Network Working Group                                         R. Austein
+Request for Comments: 1611               Epilogue Technology Corporation
+Category: Standards Track                                     J. Saperia
+                                           Digital Equipment Corporation
+                                                                May 1994
+
+                       DNS Server MIB Extensions
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Table of Contents
+
+   1. Introduction ..............................................    1
+   2. The SNMPv2 Network Management Framework ...................    2
+   2.1 Object Definitions .......................................    2
+   3. Overview ..................................................    2
+   3.1 Resolvers ................................................    3
+   3.2 Name Servers .............................................    3
+   3.3 Selected Objects .........................................    4
+   3.4 Textual Conventions ......................................    4
+   4. Definitions ...............................................    5
+   5. Acknowledgements ..........................................   28
+   6. References ................................................   28
+   7. Security Considerations ...................................   29
+   8. Authors' Addresses ........................................   30
+
+1.  Introduction
+
+   This memo defines a portion of the Management Information Base (MIB)
+   for use with network management protocols in the Internet community.
+   In particular, it describes a set of extensions which instrument DNS
+   name server functions.  This memo was produced by the DNS working
+   group.
+
+   With the adoption of the Internet-standard Network Management
+   Framework [4,5,6,7], and with a large number of vendor
+   implementations of these standards in commercially available
+   products, it became possible to provide a higher level of effective
+   network management in TCP/IP-based internets than was previously
+   available.  With the growth in the use of these standards, it has
+   become possible to consider the management of other elements of the
+   infrastructure beyond the basic TCP/IP protocols.  A key element of
+
+
+
+Austein & Saperia                                               [Page 1]
+
+RFC 1611               DNS Server MIB Extensions                May 1994
+
+
+   the TCP/IP infrastructure is the DNS.
+
+   Up to this point there has been no mechanism to integrate the
+   management of the DNS with SNMP-based managers.  This memo provides
+   the mechanisms by which IP-based management stations can effectively
+   manage DNS name server software in an integrated fashion.
+
+   We have defined DNS MIB objects to be used in conjunction with the
+   Internet MIB to allow access to and control of DNS name server
+   software via SNMP by the Internet community.
+
+2.  The SNMPv2 Network Management Framework
+
+   The SNMPv2 Network Management Framework consists of four major
+   components.  They are:
+
+      o  RFC 1442 which defines the SMI, the mechanisms used for
+         describing and naming objects for the purpose of management.
+
+      o  STD 17, RFC 1213 defines MIB-II, the core set of managed objects
+         for the Internet suite of protocols.
+
+      o  RFC 1445 which defines the administrative and other architectural
+         aspects of the framework.
+
+      o  RFC 1448 which defines the protocol used for network access to
+         managed objects.
+
+      The Framework permits new objects to be defined for the purpose of
+      experimentation and evaluation.
+
+2.1.  Object Definitions
+
+   Managed objects are accessed via a virtual information store, termed
+   the Management Information Base or MIB.  Objects in the MIB are
+   defined using the subset of Abstract Syntax Notation One (ASN.1)
+   defined in the SMI.  In particular, each object object type is named
+   by an OBJECT IDENTIFIER, an administratively assigned name.  The
+   object type together with an object instance serves to uniquely
+   identify a specific instantiation of the object.  For human
+   convenience, we often use a textual string, termed the descriptor, to
+   refer to the object type.
+
+3.  Overview
+
+   In theory, the DNS world is pretty simple.  There are two kinds of
+   entities: resolvers and name servers.  Resolvers ask questions.  Name
+   servers answer them.  The real world, however, is not so simple.
+
+
+
+Austein & Saperia                                               [Page 2]
+
+RFC 1611               DNS Server MIB Extensions                May 1994
+
+
+   Implementors have made widely differing choices about how to divide
+   DNS functions between resolvers and servers.  They have also
+   constructed various sorts of exotic hybrids.  The most difficult task
+   in defining this MIB was to accommodate this wide range of entities
+   without having to come up with a separate MIB for each.
+
+   We divided up the various DNS functions into two, non-overlapping
+   classes, called "resolver functions" and "name server functions."  A
+   DNS entity that performs what we define as resolver functions
+   contains a resolver, and therefore must implement the MIB groups
+   required of all resolvers which are defined in a separate MIB Module.
+   A DNS entity which implements name server functions is considered to
+   be a name server, and must implement the MIB groups required for name
+   servers in this module.  If the same piece of software performs both
+   resolver and server functions, we imagine that it contains both a
+   resolver and a server and would thus implement both the DNS Server
+   and DNS Resolver MIBs.
+
+3.1.  Resolvers
+
+   In our model, a resolver is a program (or piece thereof) which
+   obtains resource records from servers.  Normally it does so at the
+   behest of an application, but may also do so as part of its own
+   operation.  A resolver sends DNS protocol queries and receives DNS
+   protocol replies.  A resolver neither receives queries nor sends
+   replies.  A full service resolver is one that knows how to resolve
+   queries: it obtains the needed resource records by contacting a
+   server authoritative for the records desired.  A stub resolver does
+   not know how to resolve queries: it sends all queries to a local name
+   server, setting the "recursion desired" flag to indicate that it
+   hopes that the name server will be willing to resolve the query.  A
+   resolver may (optionally) have a cache for remembering previously
+   acquired resource records.  It may also have a negative cache for
+   remembering names or data that have been determined not to exist.
+
+3.2.  Name Servers
+
+   A name server is a program (or piece thereof) that provides resource
+   records to resolvers.  All references in this document to "a name
+   server" imply "the name server's role"; in some cases the name
+   server's role and the resolver's role might be combined into a single
+   program.  A name server receives DNS protocol queries and sends DNS
+   protocol replies.  A name server neither sends queries nor receives
+   replies.  As a consequence, name servers do not have caches.
+   Normally, a name server would expect to receive only those queries to
+   which it could respond with authoritative information.  However, if a
+   name server receives a query that it cannot respond to with purely
+   authoritative information, it may choose to try to obtain the
+
+
+
+Austein & Saperia                                               [Page 3]
+
+RFC 1611               DNS Server MIB Extensions                May 1994
+
+
+   necessary additional information from a resolver which may or may not
+   be a separate process.
+
+3.3.  Selected Objects
+
+   Many of the objects included in this memo have been created from
+   information contained in the DNS specifications [1,2], as amended and
+   clarified by subsequent host requirements documents [3].  Other
+   objects have been created based on experience with existing DNS
+   management tools, expected operational needs, the statistics
+   generated by existing DNS implementations, and the configuration
+   files used by existing DNS implementations.  These objects have been
+   ordered into groups as follows:
+
+      o  Server Configuration Group
+
+      o  Server Counter Group
+
+      o  Server Optional Counter Group
+
+      o  Server Zone Group
+
+   This information has been converted into a standard form using the
+   SNMPv2 SMI defined in [9].  For the most part, the descriptions are
+   influenced by the DNS related RFCs noted above.  For example, the
+   descriptions for counters used for the various types of queries of
+   DNS records are influenced by the definitions used for the various
+   record types found in [2].
+
+3.4.  Textual Conventions
+
+   Several conceptual data types have been introduced as a textual
+   conventions in this DNS MIB document.  These additions will
+   facilitate the common understanding of information used by the DNS.
+   No changes to the SMI or the SNMP are necessary to support these
+   conventions.
+
+   Readers familiar with MIBs designed to manage entities in the lower
+   layers of the Internet protocol suite may be surprised at the number
+   of non-enumerated integers used in this MIB to represent values such
+   as DNS RR class and type numbers.  The reason for this choice is
+   simple: the DNS itself is designed as an extensible protocol,
+   allowing new classes and types of resource records to be added to the
+   protocol without recoding the core DNS software.  Using non-
+   enumerated integers to represent these data types in this MIB allows
+   the MIB to accommodate these changes as well.
+
+
+
+
+
+Austein & Saperia                                               [Page 4]
+
+RFC 1611               DNS Server MIB Extensions                May 1994
+
+
+4.  Definitions
+
+   DNS-SERVER-MIB DEFINITIONS ::= BEGIN
+
+   IMPORTS
+       mib-2
+           FROM RFC-1213
+       MODULE-IDENTITY, OBJECT-TYPE, OBJECT-IDENTITY,
+       IpAddress, Counter32, Gauge32
+           FROM SNMPv2-SMI
+       TEXTUAL-CONVENTION, RowStatus, DisplayString, TruthValue
+           FROM SNMPv2-TC
+       MODULE-COMPLIANCE, OBJECT-GROUP
+           FROM SNMPv2-CONF;
+
+   dns OBJECT-IDENTITY
+       STATUS  current
+       DESCRIPTION
+               "The OID assigned to DNS MIB work by the IANA."
+       ::= { mib-2 32 }
+
+   dnsServMIB MODULE-IDENTITY
+       LAST-UPDATED "9401282251Z"
+       ORGANIZATION "IETF DNS Working Group"
+       CONTACT-INFO
+               "       Rob Austein
+               Postal: Epilogue Technology Corporation
+                       268 Main Street, Suite 283
+                       North Reading, MA 10864
+                       US
+                  Tel: +1 617 245 0804
+                  Fax: +1 617 245 8122
+               E-Mail: sra@epilogue.com
+
+                       Jon Saperia
+               Postal: Digital Equipment Corporation
+                       110 Spit Brook Road
+                       ZKO1-3/H18
+                       Nashua, NH 03062-2698
+                       US
+                  Tel: +1 603 881 0480
+                  Fax: +1 603 881 0120
+                Email: saperia@zko.dec.com"
+       DESCRIPTION
+               "The MIB module for entities implementing the server side
+               of the Domain Name System (DNS) protocol."
+       ::= { dns 1 }
+
+
+
+
+Austein & Saperia                                               [Page 5]
+
+RFC 1611               DNS Server MIB Extensions                May 1994
+
+
+   dnsServMIBObjects       OBJECT IDENTIFIER ::= { dnsServMIB 1 }
+
+   -- (Old-style) groups in the DNS server MIB.
+
+   dnsServConfig           OBJECT IDENTIFIER ::= { dnsServMIBObjects 1 }
+   dnsServCounter          OBJECT IDENTIFIER ::= { dnsServMIBObjects 2 }
+   dnsServOptCounter       OBJECT IDENTIFIER ::= { dnsServMIBObjects 3 }
+   dnsServZone             OBJECT IDENTIFIER ::= { dnsServMIBObjects 4 }
+
+
+   -- Textual conventions
+
+   DnsName ::= TEXTUAL-CONVENTION
+       -- A DISPLAY-HINT would be nice, but difficult to express.
+       STATUS  current
+       DESCRIPTION
+               "A DNS name is a sequence of labels.  When DNS names are
+               displayed, the boundaries between labels are typically
+               indicated by dots (e.g. `Acme' and `COM' are labels in
+               the name `Acme.COM').  In the DNS protocol, however, no
+               such separators are needed because each label is encoded
+               as a length octet followed by the indicated number of
+               octets of label.  For example, `Acme.COM' is encoded as
+               the octet sequence { 4, 'A', 'c', 'm', 'e', 3, 'C', 'O',
+               'M', 0 } (the final 0 is the length of the name of the
+               root domain, which appears implicitly at the end of any
+               DNS name).  This MIB uses the same encoding as the DNS
+               protocol.
+
+               A DnsName must always be a fully qualified name.  It is
+               an error to encode a relative domain name as a DnsName
+               without first making it a fully qualified name."
+       REFERENCE
+               "RFC-1034 section 3.1."
+       SYNTAX  OCTET STRING (SIZE (0..255))
+
+   DnsNameAsIndex ::= TEXTUAL-CONVENTION
+       STATUS  current
+       DESCRIPTION
+               "This textual convention is like a DnsName, but is used
+               as an index componant in tables.  Alphabetic characters
+               in names of this type are restricted to uppercase: the
+               characters 'a' through 'z' are mapped to the characters
+               'A' through 'Z'.  This restriction is intended to make
+               the lexical ordering imposed by SNMP useful when applied
+               to DNS names.
+
+               Note that it is theoretically possible for a valid DNS
+
+
+
+Austein & Saperia                                               [Page 6]
+
+RFC 1611               DNS Server MIB Extensions                May 1994
+
+
+               name to exceed the allowed length of an SNMP object
+               identifer, and thus be impossible to represent in tables
+               in this MIB that are indexed by DNS name.  Sampling of
+               DNS names in current use on the Internet suggests that
+               this limit does not pose a serious problem in practice."
+       REFERENCE
+               "RFC-1034 section 3.1, RFC-1448 section 4.1."
+       SYNTAX  DnsName
+
+   DnsClass ::= TEXTUAL-CONVENTION
+       DISPLAY-HINT "2d"
+       STATUS  current
+       DESCRIPTION
+               "This data type is used to represent the class values
+               which appear in Resource Records in the DNS.  A 16-bit
+               unsigned integer is used to allow room for new classes
+               of records to be defined.  Existing standard classes are
+               listed in the DNS specifications."
+       REFERENCE
+               "RFC-1035 section 3.2.4."
+       SYNTAX  INTEGER (0..65535)
+
+   DnsType ::= TEXTUAL-CONVENTION
+       DISPLAY-HINT "2d"
+       STATUS  current
+       DESCRIPTION
+               "This data type is used to represent the type values
+               which appear in Resource Records in the DNS.  A 16-bit
+               unsigned integer is used to allow room for new record
+               types to be defined.  Existing standard types are listed
+               in the DNS specifications."
+       REFERENCE
+               "RFC-1035 section 3.2.2."
+       SYNTAX  INTEGER (0..65535)
+
+   DnsQClass ::= TEXTUAL-CONVENTION
+       DISPLAY-HINT "2d"
+       STATUS  current
+       DESCRIPTION
+               "This data type is used to represent the QClass values
+               which appear in Resource Records in the DNS.  A 16-bit
+               unsigned integer is used to allow room for new QClass
+               records to be defined.  Existing standard QClasses are
+               listed in the DNS specification."
+       REFERENCE
+               "RFC-1035 section 3.2.5."
+       SYNTAX  INTEGER (0..65535)
+
+
+
+
+Austein & Saperia                                               [Page 7]
+
+RFC 1611               DNS Server MIB Extensions                May 1994
+
+
+   DnsQType ::= TEXTUAL-CONVENTION
+       DISPLAY-HINT "2d"
+       STATUS  current
+       DESCRIPTION
+               "This data type is used to represent the QType values
+               which appear in Resource Records in the DNS.  A 16-bit
+               unsigned integer is used to allow room for new QType
+               records to be defined.  Existing standard QTypes are
+               listed in the DNS specification."
+       REFERENCE
+               "RFC-1035 section 3.2.3."
+       SYNTAX  INTEGER (0..65535)
+
+   DnsTime ::= TEXTUAL-CONVENTION
+       DISPLAY-HINT "4d"
+       STATUS  current
+       DESCRIPTION
+               "DnsTime values are 32-bit unsigned integers which
+               measure time in seconds."
+       REFERENCE
+               "RFC-1035."
+       SYNTAX  Gauge32
+
+
+   DnsOpCode ::= TEXTUAL-CONVENTION
+       STATUS  current
+       DESCRIPTION
+               "This textual convention is used to represent the DNS
+               OPCODE values used in the header section of DNS
+               messages.  Existing standard OPCODE values are listed in
+               the DNS specifications."
+       REFERENCE
+               "RFC-1035 section 4.1.1."
+       SYNTAX  INTEGER (0..15)
+
+   DnsRespCode ::= TEXTUAL-CONVENTION
+       STATUS  current
+       DESCRIPTION
+               "This data type is used to represent the DNS RCODE value
+               in DNS response messages.  Existing standard RCODE
+               values are listed in the DNS specifications."
+       REFERENCE
+               "RFC-1035 section 4.1.1."
+       SYNTAX  INTEGER (0..15)
+
+
+
+
+
+
+
+Austein & Saperia                                               [Page 8]
+
+RFC 1611               DNS Server MIB Extensions                May 1994
+
+
+   -- Server Configuration Group
+
+   dnsServConfigImplementIdent OBJECT-TYPE
+       SYNTAX      DisplayString
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "The implementation identification string for the DNS
+               server software in use on the system, for example;
+               `FNS-2.1'"
+       ::= { dnsServConfig 1 }
+
+   dnsServConfigRecurs  OBJECT-TYPE
+       SYNTAX      INTEGER { available(1),
+                             restricted(2),
+                             unavailable(3) }
+       MAX-ACCESS  read-write
+       STATUS      current
+       DESCRIPTION
+               "This represents the recursion services offered by this
+               name server.  The values that can be read or written
+               are:
+
+               available(1) - performs recursion on requests from
+               clients.
+
+               restricted(2) - recursion is performed on requests only
+               from certain clients, for example; clients on an access
+               control list.
+
+               unavailable(3) - recursion is not available."
+        ::= { dnsServConfig 2 }
+
+   dnsServConfigUpTime OBJECT-TYPE
+       SYNTAX      DnsTime
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "If the server has a persistent state (e.g., a process),
+               this value will be the time elapsed since it started.
+               For software without persistant state, this value will
+               be zero."
+       ::= { dnsServConfig 3 }
+
+   dnsServConfigResetTime OBJECT-TYPE
+       SYNTAX      DnsTime
+       MAX-ACCESS  read-only
+       STATUS      current
+
+
+
+Austein & Saperia                                               [Page 9]
+
+RFC 1611               DNS Server MIB Extensions                May 1994
+
+
+       DESCRIPTION
+               "If the server has a persistent state (e.g., a process)
+               and supports a `reset' operation (e.g., can be told to
+               re-read configuration files), this value will be the
+               time elapsed since the last time the name server was
+               `reset.'  For software that does not have persistence or
+               does not support a `reset' operation, this value will be
+               zero."
+       ::= { dnsServConfig 4 }
+
+   dnsServConfigReset OBJECT-TYPE
+       SYNTAX      INTEGER { other(1),
+                             reset(2),
+                             initializing(3),
+                             running(4) }
+       MAX-ACCESS  read-write
+       STATUS      current
+       DESCRIPTION
+               "Status/action object to reinitialize any persistant name
+               server state.  When set to reset(2), any persistant
+               name server state (such as a process) is reinitialized as
+               if the name server had just been started.  This value
+               will never be returned by a read operation.  When read,
+               one of the following values will be returned:
+                   other(1) - server in some unknown state;
+                   initializing(3) - server (re)initializing;
+                   running(4) - server currently running."
+       ::= { dnsServConfig 5 }
+
+
+   -- Server Counter Group
+
+   dnsServCounterAuthAns OBJECT-TYPE
+       SYNTAX      Counter32
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Number of queries which were authoritatively answered."
+       ::= { dnsServCounter 2 }
+
+   dnsServCounterAuthNoNames OBJECT-TYPE
+       SYNTAX      Counter32
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Number of queries for which `authoritative no such name'
+               responses were made."
+       ::= { dnsServCounter 3 }
+
+
+
+Austein & Saperia                                              [Page 10]
+
+RFC 1611               DNS Server MIB Extensions                May 1994
+
+
+   dnsServCounterAuthNoDataResps OBJECT-TYPE
+       SYNTAX      Counter32
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Number of queries for which `authoritative no such data'
+               (empty answer) responses were made."
+       ::= { dnsServCounter 4 }
+
+   dnsServCounterNonAuthDatas OBJECT-TYPE
+       SYNTAX      Counter32
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Number of queries which were non-authoritatively
+               answered (cached data)."
+       ::= { dnsServCounter 5 }
+
+   dnsServCounterNonAuthNoDatas OBJECT-TYPE
+       SYNTAX      Counter32
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Number of queries which were non-authoritatively
+               answered with no data (empty answer)."
+       ::= { dnsServCounter 6 }
+
+   dnsServCounterReferrals OBJECT-TYPE
+       SYNTAX      Counter32
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Number of requests that were referred to other servers."
+       ::= { dnsServCounter 7 }
+
+   dnsServCounterErrors OBJECT-TYPE
+       SYNTAX      Counter32
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Number of requests the server has processed that were
+               answered with errors (RCODE values other than 0 and 3)."
+       REFERENCE
+               "RFC-1035 section 4.1.1."
+       ::= { dnsServCounter 8 }
+
+   dnsServCounterRelNames OBJECT-TYPE
+       SYNTAX      Counter32
+
+
+
+Austein & Saperia                                              [Page 11]
+
+RFC 1611               DNS Server MIB Extensions                May 1994
+
+
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Number of requests received by the server for names that
+               are only 1 label long (text form - no internal dots)."
+       ::= { dnsServCounter 9 }
+
+   dnsServCounterReqRefusals OBJECT-TYPE
+       SYNTAX      Counter32
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Number of DNS requests refused by the server."
+       ::= { dnsServCounter 10 }
+
+   dnsServCounterReqUnparses OBJECT-TYPE
+       SYNTAX      Counter32
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Number of requests received which were unparseable."
+       ::= { dnsServCounter 11 }
+
+   dnsServCounterOtherErrors OBJECT-TYPE
+       SYNTAX      Counter32
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Number of requests which were aborted for other (local)
+               server errors."
+       ::= { dnsServCounter 12 }
+
+   -- DNS Server Counter Table
+
+   dnsServCounterTable OBJECT-TYPE
+       SYNTAX      SEQUENCE OF DnsServCounterEntry
+       MAX-ACCESS  not-accessible
+       STATUS      current
+       DESCRIPTION
+               "Counter information broken down by DNS class and type."
+       ::= { dnsServCounter 13 }
+
+   dnsServCounterEntry OBJECT-TYPE
+       SYNTAX      DnsServCounterEntry
+       MAX-ACCESS  not-accessible
+       STATUS      current
+       DESCRIPTION
+               "This table contains count information for each DNS class
+
+
+
+Austein & Saperia                                              [Page 12]
+
+RFC 1611               DNS Server MIB Extensions                May 1994
+
+
+               and type value known to the server.  The index allows
+               management software to to create indices to the table to
+               get the specific information desired, e.g., number of
+               queries over UDP for records with type value `A' which
+               came to this server.  In order to prevent an
+               uncontrolled expansion of rows in the table; if
+               dnsServCounterRequests is 0 and dnsServCounterResponses
+               is 0, then the row does not exist and `no such' is
+               returned when the agent is queried for such instances."
+       INDEX     { dnsServCounterOpCode,
+                   dnsServCounterQClass,
+                   dnsServCounterQType,
+                   dnsServCounterTransport }
+       ::= { dnsServCounterTable 1 }
+
+   DnsServCounterEntry ::=
+       SEQUENCE {
+           dnsServCounterOpCode
+               DnsOpCode,
+           dnsServCounterQClass
+               DnsClass,
+           dnsServCounterQType
+               DnsType,
+           dnsServCounterTransport
+               INTEGER,
+           dnsServCounterRequests
+               Counter32,
+           dnsServCounterResponses
+               Counter32
+           }
+
+   dnsServCounterOpCode OBJECT-TYPE
+       SYNTAX      DnsOpCode
+       MAX-ACCESS  not-accessible
+       STATUS      current
+       DESCRIPTION
+               "The DNS OPCODE being counted in this row of the table."
+       ::= { dnsServCounterEntry 1 }
+
+   dnsServCounterQClass OBJECT-TYPE
+       SYNTAX      DnsClass
+       MAX-ACCESS  not-accessible
+       STATUS      current
+       DESCRIPTION
+               "The class of record being counted in this row of the
+               table."
+       ::= { dnsServCounterEntry 2 }
+
+
+
+
+Austein & Saperia                                              [Page 13]
+
+RFC 1611               DNS Server MIB Extensions                May 1994
+
+
+   dnsServCounterQType OBJECT-TYPE
+       SYNTAX      DnsType
+       MAX-ACCESS  not-accessible
+       STATUS      current
+       DESCRIPTION
+               "The type of record which is being counted in this row in
+               the table."
+       ::= { dnsServCounterEntry 3 }
+
+   dnsServCounterTransport OBJECT-TYPE
+       SYNTAX      INTEGER { udp(1), tcp(2), other(3) }
+       MAX-ACCESS  not-accessible
+       STATUS      current
+       DESCRIPTION
+               "A value of udp(1) indicates that the queries reported on
+               this row were sent using UDP.
+
+               A value of tcp(2) indicates that the queries reported on
+               this row were sent using TCP.
+
+               A value of other(3) indicates that the queries reported
+               on this row were sent using a transport that was neither
+               TCP nor UDP."
+       ::= { dnsServCounterEntry 4 }
+
+   dnsServCounterRequests OBJECT-TYPE
+       SYNTAX      Counter32
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Number of requests (queries) that have been recorded in
+               this row of the table."
+       ::= { dnsServCounterEntry 5 }
+
+   dnsServCounterResponses OBJECT-TYPE
+       SYNTAX      Counter32
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Number of responses made by the server since
+               initialization for the kind of query identified on this
+               row of the table."
+       ::= { dnsServCounterEntry 6 }
+
+
+
+
+
+
+
+
+Austein & Saperia                                              [Page 14]
+
+RFC 1611               DNS Server MIB Extensions                May 1994
+
+
+   -- Server Optional Counter Group
+
+   -- The Server Optional Counter Group is intended for those systems
+   -- which make distinctions between the different sources of the DNS
+   -- queries as defined below.
+   --
+   -- Objects in this group are implemented on servers which distinguish
+   -- between queries which originate from the same host as the server,
+   -- queries from one of an arbitrary group of hosts that are on an
+   -- access list defined by the server, and queries from hosts that do
+   -- not fit either of these descriptions.
+   --
+   -- The objects found in the Server Counter group are totals.  Thus if
+   -- one wanted to identify, for example, the number of queries from
+   -- `remote' hosts which have been given authoritative answers, one
+   -- would subtract the current values of ServOptCounterFriendsAuthAns
+   -- and ServOptCounterSelfAuthAns from servCounterAuthAns.
+   --
+   -- The purpose of these distinctions is to allow for implementations
+   -- to group queries and responses on this basis.  One way in which
+   -- servers may make these distinctions is by looking at the source IP
+   -- address of the DNS query.  If the source of the query is `your
+   -- own' then the query should be counted as `yourself' (local host).
+   -- If the source of the query matches an `access list,' the query
+   -- came from a friend.  What constitutes an `access list' is
+   -- implementation dependent and could be as simple as a rule that all
+   -- hosts on the same IP network as the DNS server are classed
+   -- `friends.'
+   --
+   -- In order to avoid double counting, the following rules apply:
+   --
+   -- 1. No host is in more than one of the three groups defined above.
+   --
+   -- 2. All queries from the local host are always counted in the
+   --    `yourself' group regardless of what the access list, if any,
+   --    says.
+   --
+   -- 3. The access list should not define `your friends' in such a way
+   --    that it includes all hosts.   That is, not everybody is your
+   --    `friend.'
+
+   dnsServOptCounterSelfAuthAns OBJECT-TYPE
+       SYNTAX      Counter32
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Number of requests the server has processed which
+               originated from a resolver on the same host for which
+
+
+
+Austein & Saperia                                              [Page 15]
+
+RFC 1611               DNS Server MIB Extensions                May 1994
+
+
+               there has been an authoritative answer."
+       ::= { dnsServOptCounter 1 }
+
+   dnsServOptCounterSelfAuthNoNames OBJECT-TYPE
+       SYNTAX      Counter32
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Number of requests the server has processed which
+               originated from a resolver on the same host for which
+               there has been an authoritative no such name answer
+               given."
+       ::= { dnsServOptCounter 2 }
+
+   dnsServOptCounterSelfAuthNoDataResps OBJECT-TYPE
+       SYNTAX      Counter32
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Number of requests the server has processed which
+               originated from a resolver on the same host for which
+               there has been an authoritative no such data answer
+               (empty answer) made."
+       ::= { dnsServOptCounter 3 }
+
+   dnsServOptCounterSelfNonAuthDatas OBJECT-TYPE
+       SYNTAX      Counter32
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Number of requests the server has processed which
+               originated from a resolver on the same host for which a
+               non-authoritative answer (cached data) was made."
+       ::= { dnsServOptCounter 4 }
+
+   dnsServOptCounterSelfNonAuthNoDatas OBJECT-TYPE
+       SYNTAX      Counter32
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Number of requests the server has processed which
+               originated from a resolver on the same host for which a
+               `non-authoritative, no such data' response was made
+               (empty answer)."
+       ::= { dnsServOptCounter 5 }
+
+   dnsServOptCounterSelfReferrals OBJECT-TYPE
+       SYNTAX      Counter32
+
+
+
+Austein & Saperia                                              [Page 16]
+
+RFC 1611               DNS Server MIB Extensions                May 1994
+
+
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Number of queries the server has processed which
+               originated from a resolver on the same host and were
+               referred to other servers."
+       ::= { dnsServOptCounter 6 }
+
+   dnsServOptCounterSelfErrors OBJECT-TYPE
+       SYNTAX      Counter32
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Number of requests the server has processed which
+               originated from a resolver on the same host which have
+               been answered with errors (RCODEs other than 0 and 3)."
+       REFERENCE
+               "RFC-1035 section 4.1.1."
+       ::= { dnsServOptCounter 7 }
+
+   dnsServOptCounterSelfRelNames OBJECT-TYPE
+       SYNTAX      Counter32
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Number of requests received for names that are only 1
+               label long (text form - no internal dots) the server has
+               processed which originated from a resolver on the same
+               host."
+       ::= { dnsServOptCounter 8 }
+
+   dnsServOptCounterSelfReqRefusals OBJECT-TYPE
+       SYNTAX      Counter32
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Number of DNS requests refused by the server which
+               originated from a resolver on the same host."
+       ::= { dnsServOptCounter 9 }
+
+   dnsServOptCounterSelfReqUnparses OBJECT-TYPE
+       SYNTAX      Counter32
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Number of requests received which were unparseable and
+               which originated from a resolver on the same host."
+       ::= { dnsServOptCounter 10 }
+
+
+
+Austein & Saperia                                              [Page 17]
+
+RFC 1611               DNS Server MIB Extensions                May 1994
+
+
+   dnsServOptCounterSelfOtherErrors OBJECT-TYPE
+       SYNTAX      Counter32
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Number of requests which were aborted for other (local)
+               server errors and which originated on the same host."
+       ::= { dnsServOptCounter 11 }
+
+   dnsServOptCounterFriendsAuthAns OBJECT-TYPE
+       SYNTAX      Counter32
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Number of queries originating from friends which were
+               authoritatively answered.  The definition of friends is
+               a locally defined matter."
+       ::= { dnsServOptCounter 12 }
+
+   dnsServOptCounterFriendsAuthNoNames OBJECT-TYPE
+       SYNTAX      Counter32
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Number of queries originating from friends, for which
+               authoritative `no such name' responses were made.  The
+               definition of friends is a locally defined matter."
+       ::= { dnsServOptCounter 13 }
+
+   dnsServOptCounterFriendsAuthNoDataResps OBJECT-TYPE
+       SYNTAX      Counter32
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Number of queries originating from friends for which
+               authoritative no such data (empty answer) responses were
+               made.  The definition of friends is a locally defined
+               matter."
+       ::= { dnsServOptCounter 14 }
+
+   dnsServOptCounterFriendsNonAuthDatas OBJECT-TYPE
+       SYNTAX      Counter32
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Number of queries originating from friends which were
+               non-authoritatively answered (cached data). The
+               definition of friends is a locally defined matter."
+
+
+
+Austein & Saperia                                              [Page 18]
+
+RFC 1611               DNS Server MIB Extensions                May 1994
+
+
+       ::= { dnsServOptCounter 15 }
+
+   dnsServOptCounterFriendsNonAuthNoDatas OBJECT-TYPE
+       SYNTAX      Counter32
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Number of queries originating from friends which were
+               non-authoritatively answered with no such data (empty
+               answer)."
+       ::= { dnsServOptCounter 16 }
+
+   dnsServOptCounterFriendsReferrals OBJECT-TYPE
+       SYNTAX      Counter32
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Number of requests which originated from friends that
+               were referred to other servers.  The definition of
+               friends is a locally defined matter."
+       ::= { dnsServOptCounter 17 }
+
+   dnsServOptCounterFriendsErrors OBJECT-TYPE
+       SYNTAX      Counter32
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Number of requests the server has processed which
+               originated from friends and were answered with errors
+               (RCODE values other than 0 and 3).  The definition of
+               friends is a locally defined matter."
+       REFERENCE
+               "RFC-1035 section 4.1.1."
+       ::= { dnsServOptCounter 18 }
+
+   dnsServOptCounterFriendsRelNames OBJECT-TYPE
+       SYNTAX      Counter32
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Number of requests received for names from friends that
+               are only 1 label long (text form - no internal dots) the
+               server has processed."
+       ::= { dnsServOptCounter 19 }
+
+   dnsServOptCounterFriendsReqRefusals OBJECT-TYPE
+       SYNTAX      Counter32
+       MAX-ACCESS  read-only
+
+
+
+Austein & Saperia                                              [Page 19]
+
+RFC 1611               DNS Server MIB Extensions                May 1994
+
+
+       STATUS      current
+       DESCRIPTION
+               "Number of DNS requests refused by the server which were
+               received from `friends'."
+       ::= { dnsServOptCounter 20 }
+
+   dnsServOptCounterFriendsReqUnparses OBJECT-TYPE
+       SYNTAX      Counter32
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Number of requests received which were unparseable and
+               which originated from `friends'."
+       ::= { dnsServOptCounter 21 }
+
+   dnsServOptCounterFriendsOtherErrors OBJECT-TYPE
+       SYNTAX      Counter32
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Number of requests which were aborted for other (local)
+               server errors and which originated from `friends'."
+       ::= { dnsServOptCounter 22 }
+
+
+   -- Server Zone Group
+
+   -- DNS Management Zone Configuration Table
+
+   -- This table contains zone configuration information.
+
+   dnsServZoneTable OBJECT-TYPE
+       SYNTAX      SEQUENCE OF DnsServZoneEntry
+       MAX-ACCESS  not-accessible
+       STATUS      current
+       DESCRIPTION
+               "Table of zones for which this name server provides
+               information.  Each of the zones may be loaded from stable
+               storage via an implementation-specific mechanism or may
+               be obtained from another name server via a zone transfer.
+
+               If name server doesn't load any zones, this table is
+               empty."
+       ::= { dnsServZone 1 }
+
+   dnsServZoneEntry OBJECT-TYPE
+       SYNTAX      DnsServZoneEntry
+       MAX-ACCESS  not-accessible
+
+
+
+Austein & Saperia                                              [Page 20]
+
+RFC 1611               DNS Server MIB Extensions                May 1994
+
+
+       STATUS      current
+       DESCRIPTION
+               "An entry in the name server zone table.  New rows may be
+               added either via SNMP or by the name server itself."
+       INDEX     { dnsServZoneName,
+                   dnsServZoneClass }
+       ::= { dnsServZoneTable 1 }
+
+   DnsServZoneEntry ::=
+       SEQUENCE {
+           dnsServZoneName
+               DnsNameAsIndex,
+           dnsServZoneClass
+               DnsClass,
+           dnsServZoneLastReloadSuccess
+               DnsTime,
+           dnsServZoneLastReloadAttempt
+               DnsTime,
+           dnsServZoneLastSourceAttempt
+               IpAddress,
+           dnsServZoneStatus
+               RowStatus,
+           dnsServZoneSerial
+               Counter32,
+           dnsServZoneCurrent
+               TruthValue,
+           dnsServZoneLastSourceSuccess
+               IpAddress
+       }
+
+   dnsServZoneName OBJECT-TYPE
+       SYNTAX      DnsNameAsIndex
+       MAX-ACCESS  not-accessible
+       STATUS      current
+       DESCRIPTION
+               "DNS name of the zone described by this row of the table.
+               This is the owner name of the SOA RR that defines the
+               top of the zone. This is name is in uppercase:
+               characters 'a' through 'z' are mapped to 'A' through 'Z'
+               in order to make the lexical ordering useful."
+       ::= { dnsServZoneEntry 1 }
+
+   dnsServZoneClass OBJECT-TYPE
+       SYNTAX      DnsClass
+       MAX-ACCESS  not-accessible
+       STATUS      current
+       DESCRIPTION
+               "DNS class of the RRs in this zone."
+
+
+
+Austein & Saperia                                              [Page 21]
+
+RFC 1611               DNS Server MIB Extensions                May 1994
+
+
+       ::= { dnsServZoneEntry 2 }
+
+   dnsServZoneLastReloadSuccess OBJECT-TYPE
+       SYNTAX      DnsTime
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Elapsed time in seconds since last successful reload of
+               this zone."
+       ::= { dnsServZoneEntry 3 }
+
+   dnsServZoneLastReloadAttempt OBJECT-TYPE
+       SYNTAX      DnsTime
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Elapsed time in seconds since last attempted reload of
+               this zone."
+       ::= { dnsServZoneEntry 4 }
+
+   dnsServZoneLastSourceAttempt OBJECT-TYPE
+       SYNTAX      IpAddress
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "IP address of host from which most recent zone transfer
+               of this zone was attempted.  This value should match the
+               value of dnsServZoneSourceSuccess if the attempt was
+               succcessful.  If zone transfer has not been attempted
+               within the memory of this name server, this value should
+               be 0.0.0.0."
+       ::= { dnsServZoneEntry 5 }
+
+   dnsServZoneStatus OBJECT-TYPE
+       SYNTAX      RowStatus
+       MAX-ACCESS  read-create
+       STATUS      current
+       DESCRIPTION
+               "The status of the information represented in this row of
+               the table."
+       ::= { dnsServZoneEntry 6 }
+
+   dnsServZoneSerial OBJECT-TYPE
+       SYNTAX      Counter32
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Zone serial number (from the SOA RR) of the zone
+
+
+
+Austein & Saperia                                              [Page 22]
+
+RFC 1611               DNS Server MIB Extensions                May 1994
+
+
+               represented by this row of the table.  If the zone has
+               not been successfully loaded within the memory of this
+               name server, the value of this variable is zero."
+       ::= { dnsServZoneEntry 7 }
+
+   dnsServZoneCurrent OBJECT-TYPE
+       SYNTAX      TruthValue
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Whether the server's copy of the zone represented by
+               this row of the table is currently valid.  If the zone
+               has never been successfully loaded or has expired since
+               it was last succesfully loaded, this variable will have
+               the value false(2), otherwise this variable will have
+               the value true(1)."
+       ::= { dnsServZoneEntry 8 }
+
+   dnsServZoneLastSourceSuccess OBJECT-TYPE
+       SYNTAX      IpAddress
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "IP address of host which was the source of the most
+               recent successful zone transfer for this zone.  If
+               unknown (e.g., zone has never been successfully
+               transfered) or irrelevant (e.g., zone was loaded from
+               stable storage), this value should be 0.0.0.0."
+       ::= { dnsServZoneEntry 9 }
+
+   -- DNS Zone Source Table
+
+   dnsServZoneSrcTable OBJECT-TYPE
+       SYNTAX      SEQUENCE OF DnsServZoneSrcEntry
+       MAX-ACCESS  not-accessible
+       STATUS      current
+       DESCRIPTION
+               "This table is a list of IP addresses from which the
+               server will attempt to load zone information using DNS
+               zone transfer operations.  A reload may occur due to SNMP
+               operations that create a row in dnsServZoneTable or a
+               SET to object dnsServZoneReload.  This table is only
+               used when the zone is loaded via zone transfer."
+       ::= { dnsServZone 2 }
+
+   dnsServZoneSrcEntry OBJECT-TYPE
+       SYNTAX      DnsServZoneSrcEntry
+       MAX-ACCESS  not-accessible
+
+
+
+Austein & Saperia                                              [Page 23]
+
+RFC 1611               DNS Server MIB Extensions                May 1994
+
+
+       STATUS      current
+       DESCRIPTION
+               "An entry in the name server zone source table."
+       INDEX     { dnsServZoneSrcName,
+                   dnsServZoneSrcClass,
+                   dnsServZoneSrcAddr }
+       ::= { dnsServZoneSrcTable 1 }
+
+   DnsServZoneSrcEntry ::=
+       SEQUENCE {
+           dnsServZoneSrcName
+               DnsNameAsIndex,
+           dnsServZoneSrcClass
+               DnsClass,
+           dnsServZoneSrcAddr
+               IpAddress,
+           dnsServZoneSrcStatus
+               RowStatus
+       }
+
+   dnsServZoneSrcName OBJECT-TYPE
+       SYNTAX      DnsNameAsIndex
+       MAX-ACCESS  not-accessible
+       STATUS      current
+       DESCRIPTION
+               "DNS name of the zone to which this entry applies."
+       ::= { dnsServZoneSrcEntry 1 }
+
+   dnsServZoneSrcClass OBJECT-TYPE
+       SYNTAX      DnsClass
+       MAX-ACCESS  not-accessible
+       STATUS      current
+       DESCRIPTION
+               "DNS class of zone to which this entry applies."
+       ::= { dnsServZoneSrcEntry 2 }
+
+   dnsServZoneSrcAddr OBJECT-TYPE
+       SYNTAX      IpAddress
+       MAX-ACCESS  not-accessible
+       STATUS      current
+       DESCRIPTION
+               "IP address of name server host from which this zone
+               might be obtainable."
+       ::= { dnsServZoneSrcEntry 3 }
+
+   dnsServZoneSrcStatus OBJECT-TYPE
+       SYNTAX      RowStatus
+       MAX-ACCESS  read-create
+
+
+
+Austein & Saperia                                              [Page 24]
+
+RFC 1611               DNS Server MIB Extensions                May 1994
+
+
+       STATUS      current
+       DESCRIPTION
+               "The status of the information represented in this row of
+               the table."
+       ::= { dnsServZoneSrcEntry 4 }
+
+
+   -- SNMPv2 groups.
+
+   dnsServMIBGroups        OBJECT IDENTIFIER ::= { dnsServMIB 2 }
+
+   dnsServConfigGroup OBJECT-GROUP
+       OBJECTS   { dnsServConfigImplementIdent,
+                   dnsServConfigRecurs,
+                   dnsServConfigUpTime,
+                   dnsServConfigResetTime,
+                   dnsServConfigReset }
+       STATUS      current
+       DESCRIPTION
+               "A collection of objects providing basic configuration
+               control of a DNS name server."
+       ::= { dnsServMIBGroups 1 }
+
+   dnsServCounterGroup OBJECT-GROUP
+       OBJECTS   { dnsServCounterAuthAns,
+                   dnsServCounterAuthNoNames,
+                   dnsServCounterAuthNoDataResps,
+                   dnsServCounterNonAuthDatas,
+                   dnsServCounterNonAuthNoDatas,
+                   dnsServCounterReferrals,
+                   dnsServCounterErrors,
+                   dnsServCounterRelNames,
+                   dnsServCounterReqRefusals,
+                   dnsServCounterReqUnparses,
+                   dnsServCounterOtherErrors,
+                   dnsServCounterOpCode,
+                   dnsServCounterQClass,
+                   dnsServCounterQType,
+                   dnsServCounterTransport,
+                   dnsServCounterRequests,
+                   dnsServCounterResponses }
+       STATUS      current
+       DESCRIPTION
+               "A collection of objects providing basic instrumentation
+               of a DNS name server."
+       ::= { dnsServMIBGroups 2 }
+
+
+
+
+
+Austein & Saperia                                              [Page 25]
+
+RFC 1611               DNS Server MIB Extensions                May 1994
+
+
+   dnsServOptCounterGroup OBJECT-GROUP
+       OBJECTS   { dnsServOptCounterSelfAuthAns,
+                   dnsServOptCounterSelfAuthNoNames,
+                   dnsServOptCounterSelfAuthNoDataResps,
+                   dnsServOptCounterSelfNonAuthDatas,
+                   dnsServOptCounterSelfNonAuthNoDatas,
+                   dnsServOptCounterSelfReferrals,
+                   dnsServOptCounterSelfErrors,
+                   dnsServOptCounterSelfRelNames,
+                   dnsServOptCounterSelfReqRefusals,
+                   dnsServOptCounterSelfReqUnparses,
+                   dnsServOptCounterSelfOtherErrors,
+                   dnsServOptCounterFriendsAuthAns,
+                   dnsServOptCounterFriendsAuthNoNames,
+                   dnsServOptCounterFriendsAuthNoDataResps,
+                   dnsServOptCounterFriendsNonAuthDatas,
+                   dnsServOptCounterFriendsNonAuthNoDatas,
+                   dnsServOptCounterFriendsReferrals,
+                   dnsServOptCounterFriendsErrors,
+                   dnsServOptCounterFriendsRelNames,
+                   dnsServOptCounterFriendsReqRefusals,
+                   dnsServOptCounterFriendsReqUnparses,
+                   dnsServOptCounterFriendsOtherErrors }
+       STATUS      current
+       DESCRIPTION
+               "A collection of objects providing extended
+               instrumentation of a DNS name server."
+       ::= { dnsServMIBGroups 3 }
+
+   dnsServZoneGroup OBJECT-GROUP
+       OBJECTS   { dnsServZoneName,
+                   dnsServZoneClass,
+                   dnsServZoneLastReloadSuccess,
+                   dnsServZoneLastReloadAttempt,
+                   dnsServZoneLastSourceAttempt,
+                   dnsServZoneLastSourceSuccess,
+                   dnsServZoneStatus,
+                   dnsServZoneSerial,
+                   dnsServZoneCurrent,
+                   dnsServZoneSrcName,
+                   dnsServZoneSrcClass,
+                   dnsServZoneSrcAddr,
+                   dnsServZoneSrcStatus }
+       STATUS      current
+       DESCRIPTION
+               "A collection of objects providing configuration control
+               of a DNS name server which loads authoritative zones."
+       ::= { dnsServMIBGroups 4 }
+
+
+
+Austein & Saperia                                              [Page 26]
+
+RFC 1611               DNS Server MIB Extensions                May 1994
+
+
+   -- Compliances.
+
+   dnsServMIBCompliances OBJECT IDENTIFIER ::= { dnsServMIB 3 }
+
+   dnsServMIBCompliance MODULE-COMPLIANCE
+       STATUS      current
+       DESCRIPTION
+               "The compliance statement for agents implementing the DNS
+               name server MIB extensions."
+       MODULE -- This MIB module
+           MANDATORY-GROUPS { dnsServConfigGroup, dnsServCounterGroup }
+           GROUP   dnsServOptCounterGroup
+           DESCRIPTION
+               "The server optional counter group is unconditionally
+               optional."
+           GROUP   dnsServZoneGroup
+           DESCRIPTION
+               "The server zone group is mandatory for any name server
+               that acts as an authoritative server for any DNS zone."
+           OBJECT  dnsServConfigRecurs
+           MIN-ACCESS      read-only
+           DESCRIPTION
+               "This object need not be writable."
+           OBJECT  dnsServConfigReset
+           MIN-ACCESS      read-only
+           DESCRIPTION
+               "This object need not be writable."
+       ::= { dnsServMIBCompliances 1 }
+
+   END
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Austein & Saperia                                              [Page 27]
+
+RFC 1611               DNS Server MIB Extensions                May 1994
+
+
+5.  Acknowledgements
+
+   This document is the result of work undertaken the by DNS working
+   group.  The authors would particularly like to thank the following
+   people for their contributions to this document: Philip Almquist,
+   Frank Kastenholz (FTP Software), Joe Peck (DEC), Dave Perkins
+   (SynOptics), Win Treese (DEC), and Mimi Zohar (IBM).
+
+6.  References
+
+   [1] Mockapetris, P., "Domain Names -- Concepts and Facilities", STD
+       13, RFC 1034, USC/Information Sciences Institute, November 1987.
+
+   [2] Mockapetris, P., "Domain Names -- Implementation and
+       Specification", STD 13, RFC 1035, USC/Information Sciences
+       Institute, November 1987.
+
+   [3] Braden, R., Editor, "Requirements for Internet Hosts --
+       Application and Support, STD 3, RFC 1123, USC/Information
+       Sciences Institute, October 1989.
+
+   [4] Rose, M., and K. McCloghrie, "Structure and Identification of
+       Management Information for TCP/IP-based internets", STD 16, RFC
+       1155, Performance Systems International, Hughes LAN Systems, May
+       1990.
+
+   [5] McCloghrie, K., and M. Rose, "Management Information Base for
+       Network Management of TCP/IP-based internets", RFC 1156, Hughes
+       LAN Systems, Performance Systems International, May 1990.
+
+   [6] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple
+       Network Management Protocol", STD 15, RFC 1157, SNMP Research,
+       Performance Systems International, Performance Systems
+       International, MIT Laboratory for Computer Science, May 1990.
+
+   [7] Rose, M., and K. McCloghrie, Editors, "Concise MIB Definitions",
+       STD 16, RFC 1212, Performance Systems International, Hughes LAN
+       Systems, March 1991.
+
+   [8] McCloghrie, K., and M. Rose, Editors, "Management Information
+       Base for Network Management of TCP/IP-based internets: MIB-II",
+       STD 17, RFC 1213, Hughes LAN Systems, Performance Systems
+       International, March 1991.
+
+   [9] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure
+       of Management Information for version 2 of the Simple Network
+       Management Protocol (SNMPv2)", RFC 1442, SNMP Research, Inc.,
+       Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon
+
+
+
+Austein & Saperia                                              [Page 28]
+
+RFC 1611               DNS Server MIB Extensions                May 1994
+
+
+       University, April 1993.
+
+  [10] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Textual
+       Conventions for version 2 of the the Simple Network Management
+       Protocol (SNMPv2)", RFC 1443, SNMP Research, Inc., Hughes LAN
+       Systems, Dover Beach Consulting, Inc., Carnegie Mellon
+       University, April 1993.
+
+  [11] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser,
+       "Conformance Statements for version 2 of the the Simple Network
+       Management Protocol (SNMPv2)", RFC 1444, SNMP Research, Inc.,
+       Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon
+       University, April 1993.
+
+  [12] Galvin, J., and K. McCloghrie, "Administrative Model for version
+       2 of the Simple Network Management Protocol (SNMPv2)", RFC 1445,
+       Trusted Information Systems, Hughes LAN Systems, April 1993.
+
+  [13] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol
+       Operations for version 2 of the Simple Network Management
+       Protocol (SNMPv2)", RFC 1448, SNMP Research, Inc., Hughes LAN
+       Systems, Dover Beach Consulting, Inc., Carnegie Mellon
+       University, April 1993.
+
+  [14] "Information processing systems - Open Systems Interconnection -
+       Specification of Abstract Syntax Notation One (ASN.1)",
+       International Organization for Standardization, International
+       Standard 8824, December 1987.
+
+7.  Security Considerations
+
+   Security issues are not discussed in this memo.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Austein & Saperia                                              [Page 29]
+
+RFC 1611               DNS Server MIB Extensions                May 1994
+
+
+8.  Authors' Addresses
+
+   Rob Austein
+   Epilogue Technology Corporation
+   268 Main Street, Suite 283
+   North Reading, MA 01864
+   USA
+
+   Phone: +1-617-245-0804
+   Fax:   +1-617-245-8122
+   EMail: sra@epilogue.com
+
+
+   Jon Saperia
+   Digital Equipment Corporation
+   110 Spit Brook Road
+   ZKO1-3/H18
+   Nashua, NH 03062-2698
+   USA
+
+   Phone: +1-603-881-0480
+   Fax:   +1-603-881-0120
+   EMail: saperia@zko.dec.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Austein & Saperia                                              [Page 30]
+
diff --git a/doc/rfc/rfc1612.txt b/doc/rfc/rfc1612.txt
new file mode 100644
index 0000000..4ef23b0
--- /dev/null
+++ b/doc/rfc/rfc1612.txt
@@ -0,0 +1,1795 @@
+
+
+
+
+
+
+Network Working Group                                         R. Austein
+Request for Comments: 1612               Epilogue Technology Corporation
+Category: Standards Track                                     J. Saperia
+                                           Digital Equipment Corporation
+                                                                May 1994
+
+
+                      DNS Resolver MIB Extensions
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Table of Contents
+
+   1. Introduction ..............................................    1
+   2. The SNMPv2 Network Management Framework ...................    2
+   2.1 Object Definitions .......................................    2
+   3. Overview ..................................................    2
+   3.1 Resolvers ................................................    3
+   3.2 Name Servers .............................................    3
+   3.3 Selected Objects .........................................    4
+   3.4 Textual Conventions ......................................    4
+   4. Definitions ...............................................    5
+   5. Acknowledgements ..........................................   30
+   6. References ................................................   30
+   7. Security Considerations ...................................   32
+   8. Authors' Addresses ........................................   32
+
+1.  Introduction
+
+   This memo defines a portion of the Management Information Base (MIB)
+   for use with network management protocols in the Internet community.
+   In particular, it describes a set of extensions which instrument DNS
+   resolver functions.  This memo was produced by the DNS working group.
+
+   With the adoption of the Internet-standard Network Management
+   Framework [4,5,6,7], and with a large number of vendor
+   implementations of these standards in commercially available
+   products, it became possible to provide a higher level of effective
+   network management in TCP/IP-based internets than was previously
+   available.  With the growth in the use of these standards, it has
+   become possible to consider the management of other elements of the
+   infrastructure beyond the basic TCP/IP protocols.  A key element of
+
+
+
+Austein & Saperia                                               [Page 1]
+
+RFC 1612                    DNS Resolver MIB                    May 1994
+
+
+   the TCP/IP infrastructure is the DNS.
+
+   Up to this point there has been no mechanism to integrate the
+   management of the DNS with SNMP-based managers.  This memo provides
+   the mechanisms by which IP-based management stations can effectively
+   manage DNS resolver software in an integrated fashion.
+
+   We have defined DNS MIB objects to be used in conjunction with the
+   Internet MIB to allow access to and control of DNS resolver software
+   via SNMP by the Internet community.
+
+2.  The SNMPv2 Network Management Framework
+
+   The SNMPv2 Network Management Framework consists of four major
+   components.  They are:
+
+      o  RFC 1442 which defines the SMI, the mechanisms used for
+         describing and naming objects for the purpose of management.
+
+      o  STD 17, RFC 1213 defines MIB-II, the core set of managed
+         objects for the Internet suite of protocols.
+
+      o  RFC 1445 which defines the administrative and other
+         architectural aspects of the framework.
+
+      o  RFC 1448 which defines the protocol used for network access to
+         managed objects.
+
+   The Framework permits new objects to be defined for the purpose of
+   experimentation and evaluation.
+
+2.1.  Object Definitions
+
+   Managed objects are accessed via a virtual information store, termed
+   the Management Information Base or MIB.  Objects in the MIB are
+   defined using the subset of Abstract Syntax Notation One (ASN.1)
+   defined in the SMI.  In particular, each object object type is named
+   by an OBJECT IDENTIFIER, an administratively assigned name.  The
+   object type together with an object instance serves to uniquely
+   identify a specific instantiation of the object.  For human
+   convenience, we often use a textual string, termed the descriptor, to
+   refer to the object type.
+
+3.  Overview
+
+   In theory, the DNS world is pretty simple.  There are two kinds of
+   entities: resolvers and name servers.  Resolvers ask questions.  Name
+   servers answer them.  The real world, however, is not so simple.
+
+
+
+Austein & Saperia                                               [Page 2]
+
+RFC 1612                    DNS Resolver MIB                    May 1994
+
+
+   Implementors have made widely differing choices about how to divide
+   DNS functions between resolvers and servers.  They have also
+   constructed various sorts of exotic hybrids.  The most difficult task
+   in defining this MIB was to accommodate this wide range of entities
+   without having to come up with a separate MIB for each.
+
+   We divided up the various DNS functions into two, non-overlapping
+   classes, called "resolver functions" and "name server functions."  A
+   DNS entity that performs what we define as resolver functions
+   contains a resolver, and therefore must implement the MIB groups
+   required of all resolvers which are defined in this module.  Some
+   resolvers also implement "optional" functions such as a cache, in
+   which case they must also implement the cache group contained in this
+   MIB.  A DNS entity which implements name server functions is
+   considered to be a name server, and must implement the MIB groups
+   required for name servers which are defined in a separate module.  If
+   the same piece of software performs both resolver and server
+   functions, we imagine that it contains both a resolver and a server
+   and would thus implement both the DNS Server and DNS Resolver MIBs.
+
+3.1.  Resolvers
+
+   In our model, a resolver is a program (or piece thereof) which
+   obtains resource records from servers.  Normally it does so at the
+   behest of an application, but may also do so as part of its own
+   operation.  A resolver sends DNS protocol queries and receives DNS
+   protocol replies.  A resolver neither receives queries nor sends
+   replies.  A full service resolver is one that knows how to resolve
+   queries: it obtains the needed resource records by contacting a
+   server authoritative for the records desired.  A stub resolver does
+   not know how to resolve queries: it sends all queries to a local name
+   server, setting the "recursion desired" flag to indicate that it
+   hopes that the name server will be willing to resolve the query.  A
+   resolver may (optionally) have a cache for remembering previously
+   acquired resource records.  It may also have a negative cache for
+   remembering names or data that have been determined not to exist.
+
+3.2.  Name Servers
+
+   A name server is a program (or piece thereof) that provides resource
+   records to resolvers.  All references in this document to "a name
+   server" imply "the name server's role"; in some cases the name
+   server's role and the resolver's role might be combined into a single
+   program.  A name server receives DNS protocol queries and sends DNS
+   protocol replies.  A name server neither sends queries nor receives
+   replies.  As a consequence, name servers do not have caches.
+   Normally, a name server would expect to receive only those queries to
+   which it could respond with authoritative information.  However, if a
+
+
+
+Austein & Saperia                                               [Page 3]
+
+RFC 1612                    DNS Resolver MIB                    May 1994
+
+
+   name server receives a query that it cannot respond to with purely
+   authoritative information, it may choose to try to obtain the
+   necessary additional information from a resolver which may or may not
+   be a separate process.
+
+3.3.  Selected Objects
+
+   Many of the objects included in this memo have been created from
+   information contained in the DNS specifications [1,2], as amended and
+   clarified by subsequent host requirements documents [3].  Other
+   objects have been created based on experience with existing DNS
+   management tools, expected operational needs, the statistics
+   generated by existing DNS implementations, and the configuration
+   files used by existing DNS implementations.  These objects have been
+   ordered into groups as follows:
+
+         o  Resolver Configuration Group
+
+         o  Resolver Counter Group
+
+         o  Resolver Lame Delegation Group
+
+         o  Resolver Cache Group
+
+         o  Resolver Negative Cache Group
+
+         o  Resolver Optional Counter Group
+
+   This information has been converted into a standard form using the
+   SNMPv2 SMI defined in [9].  For the most part, the descriptions are
+   influenced by the DNS related RFCs noted above.  For example, the
+   descriptions for counters used for the various types of queries of
+   DNS records are influenced by the definitions used for the various
+   record types found in [2].
+
+3.4.  Textual Conventions
+
+   Several conceptual data types have been introduced as a textual
+   conventions in the DNS Server MIB document and have been imported
+   into this MIB module.  These additions will facilitate the common
+   understanding of information used by the DNS.  No changes to the SMI
+   or the SNMP are necessary to support these conventions.
+
+   Readers familiar with MIBs designed to manage entities in the lower
+   layers of the Internet protocol suite may be surprised at the number
+   of non-enumerated integers used in this MIB to represent values such
+   as DNS RR class and type numbers.  The reason for this choice is
+   simple: the DNS itself is designed as an extensible protocol,
+
+
+
+Austein & Saperia                                               [Page 4]
+
+RFC 1612                    DNS Resolver MIB                    May 1994
+
+
+   allowing new classes and types of resource records to be added to the
+   protocol without recoding the core DNS software.  Using non-
+   enumerated integers to represent these data types in this MIB allows
+   the MIB to accommodate these changes as well.
+
+4.  Definitions
+
+   DNS-RESOLVER-MIB DEFINITIONS ::= BEGIN
+
+   IMPORTS
+       MODULE-IDENTITY, OBJECT-TYPE, IpAddress, Counter32, Integer32
+           FROM SNMPv2-SMI
+       TEXTUAL-CONVENTION, RowStatus, DisplayString
+           FROM SNMPv2-TC
+       MODULE-COMPLIANCE, OBJECT-GROUP
+           FROM SNMPv2-CONF
+       dns, DnsName, DnsNameAsIndex, DnsClass, DnsType, DnsQClass,
+       DnsQType, DnsTime, DnsOpCode, DnsRespCode
+           FROM DNS-SERVER-MIB;
+
+   -- DNS Resolver MIB
+
+   dnsResMIB MODULE-IDENTITY
+       LAST-UPDATED "9401282250Z"
+       ORGANIZATION "IETF DNS Working Group"
+       CONTACT-INFO
+               "       Rob Austein
+               Postal: Epilogue Technology Corporation
+                       268 Main Street, Suite 283
+                       North Reading, MA 10864
+                       US
+                  Tel: +1 617 245 0804
+                  Fax: +1 617 245 8122
+               E-Mail: sra@epilogue.com
+
+                       Jon Saperia
+               Postal: Digital Equipment Corporation
+                       110 Spit Brook Road
+                       ZKO1-3/H18
+                       Nashua, NH 03062-2698
+                       US
+                  Tel: +1 603 881 0480
+                  Fax: +1 603 881 0120
+               E-mail: saperia@zko.dec.com"
+       DESCRIPTION
+               "The MIB module for entities implementing the client
+               (resolver) side of the Domain Name System (DNS)
+               protocol."
+
+
+
+Austein & Saperia                                               [Page 5]
+
+RFC 1612                    DNS Resolver MIB                    May 1994
+
+
+       ::= { dns 2 }
+
+   dnsResMIBObjects        OBJECT IDENTIFIER ::= { dnsResMIB 1 }
+
+   -- (Old-style) groups in the DNS resolver MIB.
+
+   dnsResConfig            OBJECT IDENTIFIER ::= { dnsResMIBObjects 1 }
+   dnsResCounter           OBJECT IDENTIFIER ::= { dnsResMIBObjects 2 }
+   dnsResLameDelegation    OBJECT IDENTIFIER ::= { dnsResMIBObjects 3 }
+   dnsResCache             OBJECT IDENTIFIER ::= { dnsResMIBObjects 4 }
+   dnsResNCache            OBJECT IDENTIFIER ::= { dnsResMIBObjects 5 }
+   dnsResOptCounter        OBJECT IDENTIFIER ::= { dnsResMIBObjects 6 }
+
+
+   -- Resolver Configuration Group
+
+   dnsResConfigImplementIdent OBJECT-TYPE
+       SYNTAX      DisplayString
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "The implementation identification string for the
+               resolver software in use on the system, for example;
+               `RES-2.1'"
+       ::= { dnsResConfig 1 }
+
+   dnsResConfigService OBJECT-TYPE
+       SYNTAX      INTEGER { recursiveOnly(1),
+                             iterativeOnly(2),
+                             recursiveAndIterative(3) }
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Kind of DNS resolution service provided:
+
+               recursiveOnly(1) indicates a stub resolver.
+
+               iterativeOnly(2) indicates a normal full service
+               resolver.
+
+               recursiveAndIterative(3) indicates a full-service
+               resolver which performs a mix of recursive and iterative
+               queries."
+        ::= { dnsResConfig 2 }
+
+   dnsResConfigMaxCnames OBJECT-TYPE
+       SYNTAX      INTEGER (0..2147483647)
+       MAX-ACCESS  read-write
+
+
+
+Austein & Saperia                                               [Page 6]
+
+RFC 1612                    DNS Resolver MIB                    May 1994
+
+
+       STATUS      current
+       DESCRIPTION
+               "Limit on how many CNAMEs the resolver should allow
+               before deciding that there's a CNAME loop.  Zero means
+               that resolver has no explicit CNAME limit."
+       REFERENCE
+               "RFC-1035 section 7.1."
+       ::= { dnsResConfig 3 }
+
+   -- DNS Resolver Safety Belt Table
+
+   dnsResConfigSbeltTable OBJECT-TYPE
+       SYNTAX      SEQUENCE OF DnsResConfigSbeltEntry
+       MAX-ACCESS  not-accessible
+       STATUS      current
+       DESCRIPTION
+               "Table of safety belt information used by the resolver
+               when it hasn't got any better idea of where to send a
+               query, such as when the resolver is booting or is a stub
+               resolver."
+       ::= { dnsResConfig 4 }
+
+   dnsResConfigSbeltEntry OBJECT-TYPE
+       SYNTAX      DnsResConfigSbeltEntry
+       MAX-ACCESS  not-accessible
+       STATUS      current
+       DESCRIPTION
+               "An entry in the resolver's Sbelt table.
+               Rows may be created or deleted at any time by the DNS
+               resolver and by SNMP SET requests.  Whether the values
+               changed via SNMP are saved in stable storage across
+               `reset' operations is implementation-specific."
+       INDEX     { dnsResConfigSbeltAddr,
+                   dnsResConfigSbeltSubTree,
+                   dnsResConfigSbeltClass }
+       ::= { dnsResConfigSbeltTable 1 }
+
+   DnsResConfigSbeltEntry ::=
+       SEQUENCE {
+           dnsResConfigSbeltAddr
+               IpAddress,
+           dnsResConfigSbeltName
+               DnsName,
+           dnsResConfigSbeltRecursion
+               INTEGER,
+           dnsResConfigSbeltPref
+               INTEGER,
+           dnsResConfigSbeltSubTree
+
+
+
+Austein & Saperia                                               [Page 7]
+
+RFC 1612                    DNS Resolver MIB                    May 1994
+
+
+               DnsNameAsIndex,
+           dnsResConfigSbeltClass
+               DnsClass,
+           dnsResConfigSbeltStatus
+               RowStatus
+       }
+
+   dnsResConfigSbeltAddr OBJECT-TYPE
+       SYNTAX      IpAddress
+       MAX-ACCESS  not-accessible
+       STATUS      current
+       DESCRIPTION
+               "The IP address of the Sbelt name server identified by
+               this row of the table."
+       ::= { dnsResConfigSbeltEntry 1 }
+
+   dnsResConfigSbeltName OBJECT-TYPE
+       SYNTAX      DnsName
+       MAX-ACCESS  read-create
+       STATUS      current
+       DESCRIPTION
+               "The DNS name of a Sbelt nameserver identified by this
+               row of the table.  A zero-length string indicates that
+               the name is not known by the resolver."
+       ::= { dnsResConfigSbeltEntry 2 }
+
+   dnsResConfigSbeltRecursion OBJECT-TYPE
+       SYNTAX      INTEGER { iterative(1),
+                             recursive(2),
+                             recursiveAndIterative(3) }
+       MAX-ACCESS  read-create
+       STATUS      current
+       DESCRIPTION
+               "Kind of queries resolver will be sending to the name
+               server identified in this row of the table:
+
+               iterative(1) indicates that resolver will be directing
+               iterative queries to this name server (RD bit turned
+               off).
+
+               recursive(2) indicates that resolver will be directing
+               recursive queries to this name server (RD bit turned
+               on).
+
+               recursiveAndIterative(3) indicates that the resolver
+               will be directing both recursive and iterative queries
+               to the server identified in this row of the table."
+        ::= { dnsResConfigSbeltEntry 3 }
+
+
+
+Austein & Saperia                                               [Page 8]
+
+RFC 1612                    DNS Resolver MIB                    May 1994
+
+
+   dnsResConfigSbeltPref OBJECT-TYPE
+       SYNTAX      INTEGER (0..2147483647)
+       MAX-ACCESS  read-create
+       STATUS      current
+       DESCRIPTION
+               "This value identifies the preference for the name server
+               identified in this row of the table.  The lower the
+               value, the more desirable the resolver considers this
+               server."
+        ::= { dnsResConfigSbeltEntry 4 }
+
+   dnsResConfigSbeltSubTree OBJECT-TYPE
+       SYNTAX      DnsNameAsIndex
+       MAX-ACCESS  not-accessible
+       STATUS      current
+       DESCRIPTION
+               "Queries sent to the name server identified by this row
+               of the table are limited to those for names in the name
+               subtree identified by this variable.  If no such
+               limitation applies, the value of this variable is the
+               name of the root domain (a DNS name consisting of a
+               single zero octet)."
+       ::= { dnsResConfigSbeltEntry 5 }
+
+   dnsResConfigSbeltClass OBJECT-TYPE
+       SYNTAX      DnsClass
+       MAX-ACCESS  not-accessible
+       STATUS      current
+       DESCRIPTION
+               "The class of DNS queries that will be sent to the server
+               identified by this row of the table."
+       ::= { dnsResConfigSbeltEntry 6 }
+
+   dnsResConfigSbeltStatus OBJECT-TYPE
+       SYNTAX      RowStatus
+       MAX-ACCESS  read-create
+       STATUS      current
+       DESCRIPTION
+               "Row status column for this row of the Sbelt table."
+       ::= { dnsResConfigSbeltEntry 7 }
+
+   dnsResConfigUpTime OBJECT-TYPE
+       SYNTAX      DnsTime
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "If the resolver has a persistent state (e.g., a
+               process), this value will be the time elapsed since it
+
+
+
+Austein & Saperia                                               [Page 9]
+
+RFC 1612                    DNS Resolver MIB                    May 1994
+
+
+               started.  For software without persistant state, this
+               value will be 0."
+       ::= { dnsResConfig 5 }
+
+   dnsResConfigResetTime OBJECT-TYPE
+       SYNTAX      DnsTime
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "If the resolver has a persistent state (e.g., a process)
+               and supports a `reset' operation (e.g., can be told to
+               re-read configuration files), this value will be the
+               time elapsed since the last time the resolver was
+               `reset.'  For software that does not have persistence or
+               does not support a `reset' operation, this value will be
+               zero."
+       ::= { dnsResConfig 6 }
+
+   dnsResConfigReset OBJECT-TYPE
+       SYNTAX      INTEGER { other(1),
+                             reset(2),
+                             initializing(3),
+                             running(4) }
+       MAX-ACCESS  read-write
+       STATUS      current
+       DESCRIPTION
+               "Status/action object to reinitialize any persistant
+               resolver state.  When set to reset(2), any persistant
+               resolver state (such as a process) is reinitialized as if
+               the resolver had just been started.  This value will
+               never be returned by a read operation.  When read, one of
+               the following values will be returned:
+                   other(1) - resolver in some unknown state;
+                   initializing(3) - resolver (re)initializing;
+                   running(4) - resolver currently running."
+       ::= { dnsResConfig 7 }
+
+
+   -- Resolver Counters Group
+
+   -- Resolver Counter Table
+
+   dnsResCounterByOpcodeTable OBJECT-TYPE
+       SYNTAX      SEQUENCE OF DnsResCounterByOpcodeEntry
+       MAX-ACCESS  not-accessible
+       STATUS      current
+       DESCRIPTION
+               "Table of the current count of resolver queries and
+
+
+
+Austein & Saperia                                              [Page 10]
+
+RFC 1612                    DNS Resolver MIB                    May 1994
+
+
+               answers."
+       ::= { dnsResCounter 3 }
+
+   dnsResCounterByOpcodeEntry OBJECT-TYPE
+       SYNTAX      DnsResCounterByOpcodeEntry
+       MAX-ACCESS  not-accessible
+       STATUS      current
+       DESCRIPTION
+               "Entry in the resolver counter table.  Entries are
+               indexed by DNS OpCode."
+       INDEX     { dnsResCounterByOpcodeCode }
+       ::= { dnsResCounterByOpcodeTable 1 }
+
+   DnsResCounterByOpcodeEntry ::=
+       SEQUENCE {
+           dnsResCounterByOpcodeCode
+               DnsOpCode,
+           dnsResCounterByOpcodeQueries
+               Counter32,
+           dnsResCounterByOpcodeResponses
+               Counter32
+       }
+
+   dnsResCounterByOpcodeCode OBJECT-TYPE
+       SYNTAX      DnsOpCode
+       MAX-ACCESS  not-accessible
+       STATUS      current
+       DESCRIPTION
+               "The index to this table.  The OpCodes that have already
+               been defined are found in RFC-1035."
+       REFERENCE
+               "RFC-1035 section 4.1.1."
+       ::= { dnsResCounterByOpcodeEntry 1 }
+
+   dnsResCounterByOpcodeQueries OBJECT-TYPE
+       SYNTAX      Counter32
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Total number of queries that have sent out by the
+               resolver since initialization for the OpCode which is
+               the index to this row of the table."
+       ::= { dnsResCounterByOpcodeEntry 2 }
+
+   dnsResCounterByOpcodeResponses OBJECT-TYPE
+       SYNTAX      Counter32
+       MAX-ACCESS  read-only
+       STATUS      current
+
+
+
+Austein & Saperia                                              [Page 11]
+
+RFC 1612                    DNS Resolver MIB                    May 1994
+
+
+       DESCRIPTION
+               "Total number of responses that have been received by the
+               resolver since initialization for the OpCode which is
+               the index to this row of the table."
+       ::= { dnsResCounterByOpcodeEntry 3 }
+
+   -- Resolver Response Code Counter Table
+
+   dnsResCounterByRcodeTable OBJECT-TYPE
+       SYNTAX      SEQUENCE OF DnsResCounterByRcodeEntry
+       MAX-ACCESS  not-accessible
+       STATUS      current
+       DESCRIPTION
+               "Table of the current count of responses to resolver
+               queries."
+       ::= { dnsResCounter 4 }
+
+   dnsResCounterByRcodeEntry OBJECT-TYPE
+       SYNTAX      DnsResCounterByRcodeEntry
+       MAX-ACCESS  not-accessible
+       STATUS      current
+       DESCRIPTION
+               "Entry in the resolver response table.  Entries are
+               indexed by DNS response code."
+       INDEX     { dnsResCounterByRcodeCode }
+       ::= { dnsResCounterByRcodeTable 1 }
+
+   DnsResCounterByRcodeEntry ::=
+       SEQUENCE {
+           dnsResCounterByRcodeCode
+               DnsRespCode,
+           dnsResCounterByRcodeResponses
+               Counter32
+       }
+
+   dnsResCounterByRcodeCode OBJECT-TYPE
+       SYNTAX      DnsRespCode
+       MAX-ACCESS  not-accessible
+       STATUS      current
+       DESCRIPTION
+               "The index to this table.  The Response Codes that have
+               already been defined are found in RFC-1035."
+       REFERENCE
+               "RFC-1035 section 4.1.1."
+       ::= { dnsResCounterByRcodeEntry 1 }
+
+
+
+
+
+
+Austein & Saperia                                              [Page 12]
+
+RFC 1612                    DNS Resolver MIB                    May 1994
+
+
+   dnsResCounterByRcodeResponses OBJECT-TYPE
+       SYNTAX      Counter32
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Number of responses the resolver has received for the
+               response code value which identifies this row of the
+               table."
+       ::= { dnsResCounterByRcodeEntry 2 }
+
+   -- Additional DNS Resolver Counter Objects
+
+   dnsResCounterNonAuthDataResps OBJECT-TYPE
+       SYNTAX      Counter32
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Number of requests made by the resolver for which a
+               non-authoritative answer (cached data) was received."
+       ::= { dnsResCounter 5 }
+
+   dnsResCounterNonAuthNoDataResps OBJECT-TYPE
+       SYNTAX      Counter32
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Number of requests made by the resolver for which a
+               non-authoritative answer - no such data response (empty
+               answer) was received."
+       ::= { dnsResCounter 6 }
+
+   dnsResCounterMartians OBJECT-TYPE
+       SYNTAX      Counter32
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Number of responses received which were received from
+               servers that the resolver does not think it asked."
+       ::= { dnsResCounter 7 }
+
+   dnsResCounterRecdResponses OBJECT-TYPE
+       SYNTAX      Counter32
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Number of responses received to all queries."
+       ::= { dnsResCounter 8 }
+
+
+
+
+Austein & Saperia                                              [Page 13]
+
+RFC 1612                    DNS Resolver MIB                    May 1994
+
+
+   dnsResCounterUnparseResps OBJECT-TYPE
+       SYNTAX      Counter32
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Number of responses received which were unparseable."
+       ::= { dnsResCounter 9 }
+
+   dnsResCounterFallbacks OBJECT-TYPE
+       SYNTAX      Counter32
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Number of times the resolver had to fall back to its
+               seat belt information."
+       ::= { dnsResCounter 10 }
+
+
+   -- Lame Delegation Group
+
+   dnsResLameDelegationOverflows OBJECT-TYPE
+       SYNTAX      Counter32
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Number of times the resolver attempted to add an entry
+               to the Lame Delegation table but was unable to for some
+               reason such as space constraints."
+       ::= { dnsResLameDelegation 1 }
+
+   -- Lame Delegation Table
+
+   dnsResLameDelegationTable OBJECT-TYPE
+       SYNTAX      SEQUENCE OF DnsResLameDelegationEntry
+       MAX-ACCESS  not-accessible
+       STATUS      current
+       DESCRIPTION
+               "Table of name servers returning lame delegations.
+
+               A lame delegation has occured when a parent zone
+               delegates authority for a child zone to a server that
+               appears not to think that it is authoritative for the
+               child zone in question."
+       ::= { dnsResLameDelegation 2 }
+
+   dnsResLameDelegationEntry OBJECT-TYPE
+       SYNTAX      DnsResLameDelegationEntry
+       MAX-ACCESS  not-accessible
+
+
+
+Austein & Saperia                                              [Page 14]
+
+RFC 1612                    DNS Resolver MIB                    May 1994
+
+
+       STATUS      current
+       DESCRIPTION
+               "Entry in lame delegation table.  Only the resolver may
+               create rows in this table.  SNMP SET requests may be used
+               to delete rows."
+       INDEX     { dnsResLameDelegationSource,
+                   dnsResLameDelegationName,
+                   dnsResLameDelegationClass }
+       ::= { dnsResLameDelegationTable 1 }
+
+   DnsResLameDelegationEntry ::=
+       SEQUENCE {
+           dnsResLameDelegationSource
+               IpAddress,
+           dnsResLameDelegationName
+               DnsNameAsIndex,
+           dnsResLameDelegationClass
+               DnsClass,
+           dnsResLameDelegationCounts
+               Counter32,
+           dnsResLameDelegationStatus
+               RowStatus
+       }
+
+   dnsResLameDelegationSource OBJECT-TYPE
+       SYNTAX      IpAddress
+       MAX-ACCESS  not-accessible
+       STATUS      current
+       DESCRIPTION
+               "Source of lame delegation."
+       ::= { dnsResLameDelegationEntry 1 }
+
+   dnsResLameDelegationName OBJECT-TYPE
+       SYNTAX      DnsNameAsIndex
+       MAX-ACCESS  not-accessible
+       STATUS      current
+       DESCRIPTION
+               "DNS name for which lame delegation was received."
+       ::= { dnsResLameDelegationEntry 2 }
+
+   dnsResLameDelegationClass OBJECT-TYPE
+       SYNTAX      DnsClass
+       MAX-ACCESS  not-accessible
+       STATUS      current
+       DESCRIPTION
+               "DNS class of received lame delegation."
+       ::= { dnsResLameDelegationEntry 3 }
+
+
+
+
+Austein & Saperia                                              [Page 15]
+
+RFC 1612                    DNS Resolver MIB                    May 1994
+
+
+   dnsResLameDelegationCounts OBJECT-TYPE
+       SYNTAX      Counter32
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "How many times this lame delegation has been received."
+       ::= { dnsResLameDelegationEntry 4 }
+
+   dnsResLameDelegationStatus OBJECT-TYPE
+       SYNTAX      RowStatus
+       MAX-ACCESS  read-write
+       STATUS      current
+       DESCRIPTION
+               "Status column for the lame delegation table.  Since only
+               the agent (DNS resolver) creates rows in this table, the
+               only values that a manager may write to this variable
+               are active(1) and destroy(6)."
+       ::= { dnsResLameDelegationEntry 5 }
+
+
+   -- Resolver Cache Group
+
+   dnsResCacheStatus OBJECT-TYPE
+       SYNTAX      INTEGER { enabled(1), disabled(2), clear(3) }
+       MAX-ACCESS  read-write
+       STATUS      current
+       DESCRIPTION
+               "Status/action for the resolver's cache.
+
+               enabled(1) means that the use of the cache is allowed.
+               Query operations can return this state.
+
+               disabled(2) means that the cache is not being used.
+               Query operations can return this state.
+
+               Setting this variable to clear(3) deletes the entire
+               contents of the resolver's cache, but does not otherwise
+               change the resolver's state.  The status will retain its
+               previous value from before the clear operation (i.e.,
+               enabled(1) or disabled(2)).  The value of clear(3) can
+               NOT be returned by a query operation."
+       ::= { dnsResCache 1 }
+
+   dnsResCacheMaxTTL OBJECT-TYPE
+       SYNTAX      DnsTime
+       MAX-ACCESS  read-write
+       STATUS      current
+       DESCRIPTION
+
+
+
+Austein & Saperia                                              [Page 16]
+
+RFC 1612                    DNS Resolver MIB                    May 1994
+
+
+               "Maximum Time-To-Live for RRs in this cache.  If the
+               resolver does not implement a TTL ceiling, the value of
+               this field should be zero."
+       ::= { dnsResCache 2 }
+
+   dnsResCacheGoodCaches OBJECT-TYPE
+       SYNTAX      Counter32
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Number of RRs the resolver has cached successfully."
+       ::= { dnsResCache 3 }
+
+   dnsResCacheBadCaches OBJECT-TYPE
+       SYNTAX      Counter32
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Number of RRs the resolver has refused to cache because
+               they appear to be dangerous or irrelevant.  E.g., RRs
+               with suspiciously high TTLs, unsolicited root
+               information, or that just don't appear to be relevant to
+               the question the resolver asked."
+       ::= { dnsResCache 4 }
+
+   -- Resolver Cache Table
+
+   dnsResCacheRRTable OBJECT-TYPE
+       SYNTAX      SEQUENCE OF DnsResCacheRREntry
+       MAX-ACCESS  not-accessible
+       STATUS      current
+       DESCRIPTION
+               "This table contains information about all the resource
+               records currently in the resolver's cache."
+       ::= { dnsResCache 5 }
+
+   dnsResCacheRREntry OBJECT-TYPE
+       SYNTAX      DnsResCacheRREntry
+       MAX-ACCESS  not-accessible
+       STATUS      current
+       DESCRIPTION
+               "An entry in the resolvers's cache.  Rows may be created
+               only by the resolver.  SNMP SET requests may be used to
+               delete rows."
+       INDEX     { dnsResCacheRRName,
+                   dnsResCacheRRClass,
+                   dnsResCacheRRType,
+                   dnsResCacheRRIndex }
+
+
+
+Austein & Saperia                                              [Page 17]
+
+RFC 1612                    DNS Resolver MIB                    May 1994
+
+
+       ::= { dnsResCacheRRTable 1 }
+
+   DnsResCacheRREntry ::=
+       SEQUENCE {
+           dnsResCacheRRName
+               DnsNameAsIndex,
+           dnsResCacheRRClass
+               DnsClass,
+           dnsResCacheRRType
+               DnsType,
+           dnsResCacheRRTTL
+               DnsTime,
+           dnsResCacheRRElapsedTTL
+               DnsTime,
+           dnsResCacheRRSource
+               IpAddress,
+           dnsResCacheRRData
+               OCTET STRING,
+           dnsResCacheRRStatus
+               RowStatus,
+           dnsResCacheRRIndex
+               Integer32,
+           dnsResCacheRRPrettyName
+               DnsName
+       }
+
+   dnsResCacheRRName OBJECT-TYPE
+       SYNTAX      DnsNameAsIndex
+       MAX-ACCESS  not-accessible
+       STATUS      current
+       DESCRIPTION
+               "Owner name of the Resource Record in the cache which is
+               identified in this row of the table.  As described in
+               RFC-1034, the owner of the record is the domain name
+               were the RR is found."
+       REFERENCE
+               "RFC-1034 section 3.6."
+       ::= { dnsResCacheRREntry 1 }
+
+   dnsResCacheRRClass OBJECT-TYPE
+       SYNTAX      DnsClass
+       MAX-ACCESS  not-accessible
+       STATUS      current
+       DESCRIPTION
+               "DNS class of the Resource Record in the cache which is
+               identified in this row of the table."
+       ::= { dnsResCacheRREntry 2 }
+
+
+
+
+Austein & Saperia                                              [Page 18]
+
+RFC 1612                    DNS Resolver MIB                    May 1994
+
+
+   dnsResCacheRRType OBJECT-TYPE
+       SYNTAX      DnsType
+       MAX-ACCESS  not-accessible
+       STATUS      current
+       DESCRIPTION
+               "DNS type of the Resource Record in the cache which is
+               identified in this row of the table."
+       ::= { dnsResCacheRREntry 3 }
+
+   dnsResCacheRRTTL OBJECT-TYPE
+       SYNTAX      DnsTime
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Time-To-Live of RR in DNS cache.  This is the initial
+               TTL value which was received with the RR when it was
+               originally received."
+       ::= { dnsResCacheRREntry 4 }
+
+   dnsResCacheRRElapsedTTL OBJECT-TYPE
+       SYNTAX      DnsTime
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Elapsed seconds since RR was received."
+       ::= { dnsResCacheRREntry 5 }
+
+   dnsResCacheRRSource OBJECT-TYPE
+       SYNTAX      IpAddress
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Host from which RR was received, 0.0.0.0 if unknown."
+       ::= { dnsResCacheRREntry 6 }
+
+   dnsResCacheRRData OBJECT-TYPE
+       SYNTAX      OCTET STRING
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "RDATA portion of a cached RR.  The value is in the
+               format defined for the particular DNS class and type of
+               the resource record."
+       REFERENCE
+               "RFC-1035 section 3.2.1."
+       ::= { dnsResCacheRREntry 7 }
+
+
+
+
+
+Austein & Saperia                                              [Page 19]
+
+RFC 1612                    DNS Resolver MIB                    May 1994
+
+
+   dnsResCacheRRStatus OBJECT-TYPE
+       SYNTAX      RowStatus
+       MAX-ACCESS  read-write
+       STATUS      current
+       DESCRIPTION
+               "Status column for the resolver cache table.  Since only
+               the agent (DNS resolver) creates rows in this table, the
+               only values that a manager may write to this variable
+               are active(1) and destroy(6)."
+       ::= { dnsResCacheRREntry 8 }
+
+   dnsResCacheRRIndex OBJECT-TYPE
+       SYNTAX      Integer32
+       MAX-ACCESS  not-accessible
+       STATUS      current
+       DESCRIPTION
+               "A value which makes entries in the table unique when the
+               other index values (dnsResCacheRRName,
+               dnsResCacheRRClass, and dnsResCacheRRType) do not
+               provide a unique index."
+       ::= { dnsResCacheRREntry 9 }
+
+   dnsResCacheRRPrettyName OBJECT-TYPE
+       SYNTAX      DnsName
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Name of the RR at this row in the table.  This is
+               identical to the dnsResCacheRRName variable, except that
+               character case is preserved in this variable, per DNS
+               conventions."
+       REFERENCE
+               "RFC-1035 section 2.3.3."
+       ::= { dnsResCacheRREntry 10 }
+
+   -- Resolver Negative Cache Group
+
+   dnsResNCacheStatus OBJECT-TYPE
+       SYNTAX      INTEGER { enabled(1), disabled(2), clear(3) }
+       MAX-ACCESS  read-write
+       STATUS      current
+       DESCRIPTION
+               "Status/action for the resolver's negative response
+               cache.
+
+               enabled(1) means that the use of the negative response
+               cache is allowed.  Query operations can return this
+               state.
+
+
+
+Austein & Saperia                                              [Page 20]
+
+RFC 1612                    DNS Resolver MIB                    May 1994
+
+
+               disabled(2) means that the negative response cache is
+               not being used.  Query operations can return this state.
+
+               Setting this variable to clear(3) deletes the entire
+               contents of the resolver's negative response cache.  The
+               status will retain its previous value from before the
+               clear operation (i.e., enabled(1) or disabled(2)).  The
+               value of clear(3) can NOT be returned by a query
+               operation."
+       ::= { dnsResNCache 1 }
+
+   dnsResNCacheMaxTTL OBJECT-TYPE
+       SYNTAX      DnsTime
+       MAX-ACCESS  read-write
+       STATUS      current
+       DESCRIPTION
+               "Maximum Time-To-Live for cached authoritative errors.
+               If the resolver does not implement a TTL ceiling, the
+               value of this field should be zero."
+       ::= { dnsResNCache 2 }
+
+   dnsResNCacheGoodNCaches OBJECT-TYPE
+       SYNTAX      Counter32
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Number of authoritative errors the resolver has cached
+               successfully."
+       ::= { dnsResNCache 3 }
+
+   dnsResNCacheBadNCaches OBJECT-TYPE
+       SYNTAX      Counter32
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Number of authoritative errors the resolver would have
+               liked to cache but was unable to because the appropriate
+               SOA RR was not supplied or looked suspicious."
+       REFERENCE
+               "RFC-1034 section 4.3.4."
+       ::= { dnsResNCache 4 }
+
+   -- Resolver Negative Cache Table
+
+   dnsResNCacheErrTable OBJECT-TYPE
+       SYNTAX      SEQUENCE OF DnsResNCacheErrEntry
+       MAX-ACCESS  not-accessible
+       STATUS      current
+
+
+
+Austein & Saperia                                              [Page 21]
+
+RFC 1612                    DNS Resolver MIB                    May 1994
+
+
+       DESCRIPTION
+               "The resolver's negative response cache.  This table
+               contains information about authoritative errors that
+               have been cached by the resolver."
+       ::= { dnsResNCache 5 }
+
+   dnsResNCacheErrEntry OBJECT-TYPE
+       SYNTAX      DnsResNCacheErrEntry
+       MAX-ACCESS  not-accessible
+       STATUS      current
+       DESCRIPTION
+               "An entry in the resolver's negative response cache
+               table.  Only the resolver can create rows.  SNMP SET
+               requests may be used to delete rows."
+       INDEX     { dnsResNCacheErrQName,
+                   dnsResNCacheErrQClass,
+                   dnsResNCacheErrQType,
+                   dnsResNCacheErrIndex }
+       ::= { dnsResNCacheErrTable 1 }
+
+   DnsResNCacheErrEntry ::=
+       SEQUENCE {
+           dnsResNCacheErrQName
+               DnsNameAsIndex,
+           dnsResNCacheErrQClass
+               DnsQClass,
+           dnsResNCacheErrQType
+               DnsQType,
+           dnsResNCacheErrTTL
+               DnsTime,
+           dnsResNCacheErrElapsedTTL
+               DnsTime,
+           dnsResNCacheErrSource
+               IpAddress,
+           dnsResNCacheErrCode
+               INTEGER,
+           dnsResNCacheErrStatus
+               RowStatus,
+           dnsResNCacheErrIndex
+               Integer32,
+           dnsResNCacheErrPrettyName
+               DnsName
+       }
+
+   dnsResNCacheErrQName OBJECT-TYPE
+       SYNTAX      DnsNameAsIndex
+       MAX-ACCESS  not-accessible
+       STATUS      current
+
+
+
+Austein & Saperia                                              [Page 22]
+
+RFC 1612                    DNS Resolver MIB                    May 1994
+
+
+       DESCRIPTION
+               "QNAME associated with a cached authoritative error."
+       REFERENCE
+               "RFC-1034 section 3.7.1."
+       ::= { dnsResNCacheErrEntry 1 }
+
+   dnsResNCacheErrQClass OBJECT-TYPE
+       SYNTAX      DnsQClass
+       MAX-ACCESS  not-accessible
+       STATUS      current
+       DESCRIPTION
+               "DNS QCLASS associated with a cached authoritative
+               error."
+       ::= { dnsResNCacheErrEntry 2 }
+
+   dnsResNCacheErrQType OBJECT-TYPE
+       SYNTAX      DnsQType
+       MAX-ACCESS  not-accessible
+       STATUS      current
+       DESCRIPTION
+               "DNS QTYPE associated with a cached authoritative error."
+       ::= { dnsResNCacheErrEntry 3 }
+
+   dnsResNCacheErrTTL OBJECT-TYPE
+       SYNTAX      DnsTime
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Time-To-Live of a cached authoritative error at the time
+               of the error, it should not be decremented by the number
+               of seconds since it was received.  This should be the
+               TTL as copied from the MINIMUM field of the SOA that
+               accompanied the authoritative error, or a smaller value
+               if the resolver implements a ceiling on negative
+               response cache TTLs."
+       REFERENCE
+               "RFC-1034 section 4.3.4."
+       ::= { dnsResNCacheErrEntry 4 }
+
+   dnsResNCacheErrElapsedTTL OBJECT-TYPE
+       SYNTAX      DnsTime
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Elapsed seconds since authoritative error was received."
+       ::= { dnsResNCacheErrEntry 5 }
+
+
+
+
+
+Austein & Saperia                                              [Page 23]
+
+RFC 1612                    DNS Resolver MIB                    May 1994
+
+
+   dnsResNCacheErrSource OBJECT-TYPE
+       SYNTAX      IpAddress
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Host which sent the authoritative error, 0.0.0.0 if
+               unknown."
+       ::= { dnsResNCacheErrEntry 6 }
+
+   dnsResNCacheErrCode OBJECT-TYPE
+       SYNTAX      INTEGER { nonexistantName(1), noData(2), other(3) }
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "The authoritative error that has been cached:
+
+               nonexistantName(1) indicates an authoritative name error
+               (RCODE = 3).
+
+               noData(2) indicates an authoritative response with no
+               error (RCODE = 0) and no relevant data.
+
+               other(3) indicates some other cached authoritative
+               error.  At present, no such errors are known to exist."
+       ::= { dnsResNCacheErrEntry 7 }
+
+   dnsResNCacheErrStatus OBJECT-TYPE
+       SYNTAX      RowStatus
+       MAX-ACCESS  read-write
+       STATUS      current
+       DESCRIPTION
+               "Status column for the resolver negative response cache
+               table.  Since only the agent (DNS resolver) creates rows
+               in this table, the only values that a manager may write
+               to this variable are active(1) and destroy(6)."
+       ::= { dnsResNCacheErrEntry 8 }
+
+   dnsResNCacheErrIndex OBJECT-TYPE
+       SYNTAX      Integer32
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "A value which makes entries in the table unique when the
+               other index values (dnsResNCacheErrQName,
+               dnsResNCacheErrQClass, and dnsResNCacheErrQType) do not
+               provide a unique index."
+       ::= { dnsResNCacheErrEntry 9 }
+
+
+
+
+Austein & Saperia                                              [Page 24]
+
+RFC 1612                    DNS Resolver MIB                    May 1994
+
+
+   dnsResNCacheErrPrettyName OBJECT-TYPE
+       SYNTAX      DnsName
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "QNAME associated with this row in the table.  This is
+               identical to the dnsResNCacheErrQName variable, except
+               that character case is preserved in this variable, per
+               DNS conventions."
+       REFERENCE
+               "RFC-1035 section 2.3.3."
+       ::= { dnsResNCacheErrEntry 10 }
+
+
+   -- Resolver Optional Counters Group
+
+   dnsResOptCounterReferals OBJECT-TYPE
+       SYNTAX      Counter32
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Number of responses which were received from servers
+               redirecting query to another server."
+       ::= { dnsResOptCounter 1 }
+
+   dnsResOptCounterRetrans OBJECT-TYPE
+       SYNTAX      Counter32
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Number requests retransmitted for all reasons."
+       ::= { dnsResOptCounter 2 }
+
+   dnsResOptCounterNoResponses OBJECT-TYPE
+       SYNTAX      Counter32
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Number of queries that were retransmitted because of no
+               response."
+       ::= { dnsResOptCounter 3 }
+
+   dnsResOptCounterRootRetrans OBJECT-TYPE
+       SYNTAX      Counter32
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Number of queries that were retransmitted that were to
+
+
+
+Austein & Saperia                                              [Page 25]
+
+RFC 1612                    DNS Resolver MIB                    May 1994
+
+
+               root servers."
+       ::= { dnsResOptCounter 4 }
+
+   dnsResOptCounterInternals OBJECT-TYPE
+       SYNTAX      Counter32
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Number of requests internally generated by the
+               resolver."
+       ::= { dnsResOptCounter 5 }
+
+   dnsResOptCounterInternalTimeOuts OBJECT-TYPE
+       SYNTAX      Counter32
+       MAX-ACCESS  read-only
+       STATUS      current
+       DESCRIPTION
+               "Number of requests internally generated which timed
+               out."
+       ::= { dnsResOptCounter 6 }
+
+
+   -- SNMPv2 groups.
+
+   dnsResMIBGroups         OBJECT IDENTIFIER ::= { dnsResMIB 2 }
+
+   dnsResConfigGroup OBJECT-GROUP
+       OBJECTS   { dnsResConfigImplementIdent,
+                   dnsResConfigService,
+                   dnsResConfigMaxCnames,
+                   dnsResConfigSbeltAddr,
+                   dnsResConfigSbeltName,
+                   dnsResConfigSbeltRecursion,
+                   dnsResConfigSbeltPref,
+                   dnsResConfigSbeltSubTree,
+                   dnsResConfigSbeltClass,
+                   dnsResConfigSbeltStatus,
+                   dnsResConfigUpTime,
+                   dnsResConfigResetTime }
+       STATUS      current
+       DESCRIPTION
+               "A collection of objects providing basic configuration
+               information for a DNS resolver implementation."
+       ::= { dnsResMIBGroups 1 }
+
+   dnsResCounterGroup OBJECT-GROUP
+       OBJECTS   { dnsResCounterByOpcodeCode,
+                   dnsResCounterByOpcodeQueries,
+
+
+
+Austein & Saperia                                              [Page 26]
+
+RFC 1612                    DNS Resolver MIB                    May 1994
+
+
+                   dnsResCounterByOpcodeResponses,
+                   dnsResCounterByRcodeCode,
+                   dnsResCounterByRcodeResponses,
+                   dnsResCounterNonAuthDataResps,
+                   dnsResCounterNonAuthNoDataResps,
+                   dnsResCounterMartians,
+                   dnsResCounterRecdResponses,
+                   dnsResCounterUnparseResps,
+                   dnsResCounterFallbacks }
+       STATUS      current
+       DESCRIPTION
+               "A collection of objects providing basic instrumentation
+               of a DNS resolver implementation."
+       ::= { dnsResMIBGroups 2 }
+
+   dnsResLameDelegationGroup OBJECT-GROUP
+       OBJECTS   { dnsResLameDelegationOverflows,
+                   dnsResLameDelegationSource,
+                   dnsResLameDelegationName,
+                   dnsResLameDelegationClass,
+                   dnsResLameDelegationCounts,
+                   dnsResLameDelegationStatus }
+       STATUS      current
+       DESCRIPTION
+               "A collection of objects providing instrumentation of
+               `lame delegation' failures."
+       ::= { dnsResMIBGroups 3 }
+
+
+   dnsResCacheGroup OBJECT-GROUP
+       OBJECTS   { dnsResCacheStatus,
+                   dnsResCacheMaxTTL,
+                   dnsResCacheGoodCaches,
+                   dnsResCacheBadCaches,
+                   dnsResCacheRRName,
+                   dnsResCacheRRClass,
+                   dnsResCacheRRType,
+                   dnsResCacheRRTTL,
+                   dnsResCacheRRElapsedTTL,
+                   dnsResCacheRRSource,
+                   dnsResCacheRRData,
+                   dnsResCacheRRStatus,
+                   dnsResCacheRRIndex,
+                   dnsResCacheRRPrettyName }
+       STATUS      current
+       DESCRIPTION
+               "A collection of objects providing access to and control
+               of a DNS resolver's cache."
+
+
+
+Austein & Saperia                                              [Page 27]
+
+RFC 1612                    DNS Resolver MIB                    May 1994
+
+
+       ::= { dnsResMIBGroups 4 }
+
+   dnsResNCacheGroup OBJECT-GROUP
+       OBJECTS   { dnsResNCacheStatus,
+                   dnsResNCacheMaxTTL,
+                   dnsResNCacheGoodNCaches,
+                   dnsResNCacheBadNCaches,
+                   dnsResNCacheErrQName,
+                   dnsResNCacheErrQClass,
+                   dnsResNCacheErrQType,
+                   dnsResNCacheErrTTL,
+                   dnsResNCacheErrElapsedTTL,
+                   dnsResNCacheErrSource,
+                   dnsResNCacheErrCode,
+                   dnsResNCacheErrStatus,
+                   dnsResNCacheErrIndex,
+                   dnsResNCacheErrPrettyName }
+       STATUS      current
+       DESCRIPTION
+               "A collection of objects providing access to and control
+               of a DNS resolver's negative response cache."
+       ::= { dnsResMIBGroups 5 }
+
+   dnsResOptCounterGroup OBJECT-GROUP
+       OBJECTS   { dnsResOptCounterReferals,
+                   dnsResOptCounterRetrans,
+                   dnsResOptCounterNoResponses,
+                   dnsResOptCounterRootRetrans,
+                   dnsResOptCounterInternals,
+                   dnsResOptCounterInternalTimeOuts }
+       STATUS      current
+       DESCRIPTION
+               "A collection of objects providing further
+               instrumentation applicable to many but not all DNS
+               resolvers."
+       ::= { dnsResMIBGroups 6 }
+
+
+   -- Compliances.
+
+   dnsResMIBCompliances OBJECT IDENTIFIER ::= { dnsResMIB 3 }
+
+   dnsResMIBCompliance MODULE-COMPLIANCE
+       STATUS      current
+       DESCRIPTION
+               "The compliance statement for agents implementing the DNS
+               resolver MIB extensions."
+       MODULE -- This MIB module
+
+
+
+Austein & Saperia                                              [Page 28]
+
+RFC 1612                    DNS Resolver MIB                    May 1994
+
+
+           MANDATORY-GROUPS { dnsResConfigGroup, dnsResCounterGroup }
+           GROUP   dnsResCacheGroup
+           DESCRIPTION
+               "The resolver cache group is mandatory for resolvers that
+               implement a cache."
+           GROUP   dnsResNCacheGroup
+           DESCRIPTION
+               "The resolver negative cache group is mandatory for
+               resolvers that implement a negative response cache."
+           GROUP   dnsResLameDelegationGroup
+           DESCRIPTION
+               "The lame delegation group is unconditionally optional."
+           GROUP   dnsResOptCounterGroup
+           DESCRIPTION
+               "The optional counters group is unconditionally
+               optional."
+           OBJECT  dnsResConfigMaxCnames
+           MIN-ACCESS      read-only
+           DESCRIPTION
+               "This object need not be writable."
+           OBJECT  dnsResConfigSbeltName
+           MIN-ACCESS      read-only
+           DESCRIPTION
+               "This object need not be writable."
+           OBJECT  dnsResConfigSbeltRecursion
+           MIN-ACCESS      read-only
+           DESCRIPTION
+               "This object need not be writable."
+           OBJECT  dnsResConfigSbeltPref
+           MIN-ACCESS      read-only
+           DESCRIPTION
+               "This object need not be writable."
+           OBJECT  dnsResConfigReset
+           MIN-ACCESS      read-only
+           DESCRIPTION
+               "This object need not be writable."
+           OBJECT  dnsResCacheStatus
+           MIN-ACCESS      read-only
+           DESCRIPTION
+               "This object need not be writable."
+           OBJECT  dnsResCacheMaxTTL
+           MIN-ACCESS      read-only
+           DESCRIPTION
+               "This object need not be writable."
+           OBJECT  dnsResNCacheStatus
+           MIN-ACCESS      read-only
+           DESCRIPTION
+               "This object need not be writable."
+
+
+
+Austein & Saperia                                              [Page 29]
+
+RFC 1612                    DNS Resolver MIB                    May 1994
+
+
+           OBJECT  dnsResNCacheMaxTTL
+           MIN-ACCESS      read-only
+           DESCRIPTION
+               "This object need not be writable."
+       ::= { dnsResMIBCompliances 1 }
+
+   END
+
+5.  Acknowledgements
+
+   This document is the result of work undertaken the by DNS working
+   group.  The authors would particularly like to thank the following
+   people for their contributions to this document: Philip Almquist,
+   Frank Kastenholz (FTP Software), Joe Peck (DEC), Dave Perkins
+   (SynOptics), Win Treese (DEC), and Mimi Zohar (IBM).
+
+6.  References
+
+   [1] Mockapetris, P., "Domain Names -- Concepts and Facilities", STD
+       13, RFC 1034, USC/Information Sciences Institute, November 1987.
+
+   [2] Mockapetris, P., "Domain Names -- Implementation and
+       Specification", STD 13, RFC 1035, USC/Information Sciences
+       Institute, November 1987.
+
+   [3] Braden, R., Editor, "Requirements for Internet Hosts --
+       Application and Support, STD 3, RFC 1123, USC/Information
+       Sciences Institute, October 1989.
+
+   [4] Rose, M., and K. McCloghrie, "Structure and Identification of
+       Management Information for TCP/IP-based internets", STD 16, RFC
+       1155, Performance Systems International, Hughes LAN Systems, May
+       1990.
+
+   [5] McCloghrie, K., and M. Rose, "Management Information Base for
+       Network Management of TCP/IP-based internets", RFC 1156, Hughes
+       LAN Systems, Performance Systems International, May 1990.
+
+   [6] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple
+       Network Management Protocol", STD 15, RFC 1157, SNMP Research,
+       Performance Systems International, Performance Systems
+       International, MIT Laboratory for Computer Science, May 1990.
+
+   [7] Rose, M., and K. McCloghrie, Editors, "Concise MIB Definitions",
+       STD 16, RFC 1212, Performance Systems International, Hughes LAN
+       Systems, March 1991.
+
+
+
+
+
+Austein & Saperia                                              [Page 30]
+
+RFC 1612                    DNS Resolver MIB                    May 1994
+
+
+   [8] McCloghrie, K., and M. Rose, "Management Information Base for
+       Network Management of TCP/IP-based internets: MIB-II", STD 17,
+       RFC 1213, Hughes LAN Systems, Performance Systems International,
+       March 1991.
+
+   [9] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure
+       of Management Information for version 2 of the Simple Network
+       Management Protocol (SNMPv2)", RFC 1442, SNMP Research, Inc.,
+       Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon
+       University, April 1993.
+
+  [10] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Textual
+       Conventions for version 2 of the the Simple Network Management
+       Protocol (SNMPv2)", RFC 1443, SNMP Research, Inc., Hughes LAN
+       Systems, Dover Beach Consulting, Inc., Carnegie Mellon
+       University, April 1993.
+
+  [11] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser,
+       "Conformance Statements for version 2 of the the Simple Network
+       Management Protocol (SNMPv2)", RFC 1444, SNMP Research, Inc.,
+       Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie Mellon
+       University, April 1993.
+
+  [12] Galvin, J., and K. McCloghrie, "Administrative Model for version
+       2 of the Simple Network Management Protocol (SNMPv2)", RFC 1445,
+       Trusted Information Systems, Hughes LAN Systems, April 1993.
+
+  [13] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol
+       Operations for version 2 of the Simple Network Management
+       Protocol (SNMPv2)", RFC 1448, SNMP Research, Inc., Hughes LAN
+       Systems, Dover Beach Consulting, Inc., Carnegie Mellon
+       University, April 1993.
+
+  [14] "Information processing systems - Open Systems Interconnection -
+       Specification of Abstract Syntax Notation One (ASN.1)",
+       International Organization for Standardization, International
+       Standard 8824, December 1987.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Austein & Saperia                                              [Page 31]
+
+RFC 1612                    DNS Resolver MIB                    May 1994
+
+
+7.  Security Considerations
+
+   Security issues are not discussed in this memo.
+
+8.  Authors' Addresses
+
+   Rob Austein
+   Epilogue Technology Corporation
+   268 Main Street, Suite 283
+   North Reading, MA 01864
+   USA
+
+   Phone: +1-617-245-0804
+   Fax:   +1-617-245-8122
+   EMail: sra@epilogue.com
+
+
+   Jon Saperia
+   Digital Equipment Corporation
+   110 Spit Brook Road
+   ZKO1-3/H18
+   Nashua, NH 03062-2698
+   USA
+
+   Phone: +1-603-881-0480
+   Fax:   +1-603-881-0120
+   EMail: saperia@zko.dec.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Austein & Saperia                                              [Page 32]
+
diff --git a/doc/rfc/rfc1706.txt b/doc/rfc/rfc1706.txt
new file mode 100644
index 0000000..5b5d821
--- /dev/null
+++ b/doc/rfc/rfc1706.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+Network Working Group                                         B. Manning
+Request for Comments: 1706                                           ISI
+Obsoletes: 1637, 1348                                         R. Colella
+Category: Informational                                             NIST
+                                                            October 1994
+
+
+                       DNS NSAP Resource Records
+
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  This memo
+   does not specify an Internet standard of any kind.  Distribution of
+   this memo is unlimited.
+
+Abstract
+
+   OSI lower layer protocols, comprising the connectionless network
+   protocol (CLNP) and supporting routing protocols, are deployed in
+   some parts of the global Internet.  Maintenance and debugging of CLNP
+   connectivity is greatly aided by support in the Domain Name System
+   (DNS) for mapping between names and NSAP addresses.
+
+   This document defines the format of one new Resource Record (RR) for
+   the DNS for domain name-to-NSAP mapping. The RR may be used with any
+   NSAP address format.
+
+   NSAP-to-name translation is accomplished through use of the PTR RR
+   (see STD 13, RFC 1035 for a description of the PTR RR). This paper
+   describes how PTR RRs are used to support this translation.
+
+   This document obsoletes RFC 1348 and RFC 1637.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Manning & Colella                                               [Page 1]
+
+RFC 1706                      DNS NSAP RRs                  October 1994
+
+
+1.  Introduction
+
+   OSI lower layer protocols, comprising the connectionless network
+   protocol (CLNP) [5] and supporting routing protocols, are deployed in
+   some parts of the global Internet.  Maintenance and debugging of CLNP
+   connectivity is greatly aided by support in the Domain Name System
+   (DNS) [7] [8] for mapping between names and NSAP (network service
+   access point) addresses [6] [Note: NSAP and NSAP address are used
+   interchangeably throughout this memo].
+
+   This document defines the format of one new Resource Record (RR) for
+   the DNS for domain name-to-NSAP mapping. The RR may be used with any
+   NSAP address format.
+
+   NSAP-to-name translation is accomplished through use of the PTR RR
+   (see RFC 1035 for a description of the PTR RR). This paper describes
+   how PTR RRs are used to support this translation.
+
+   This memo assumes that the reader is familiar with the DNS. Some
+   familiarity with NSAPs is useful; see [1] or Annex A of [6] for
+   additional information.
+
+2.  Background
+
+   The reason for defining DNS mappings for NSAPs is to support the
+   existing CLNP deployment in the Internet.  Debugging with CLNP ping
+   and traceroute has become more difficult with only numeric NSAPs as
+   the scale of deployment has increased. Current debugging is supported
+   by maintaining and exchanging a configuration file with name/NSAP
+   mappings similar in function to hosts.txt. This suffers from the lack
+   of a central coordinator for this file and also from the perspective
+   of scaling.  The former describes the most serious short-term
+   problem. Scaling of a hosts.txt-like solution has well-known long-
+   term scaling difficiencies.
+
+3.  Scope
+
+   The methods defined in this paper are applicable to all NSAP formats.
+
+   As a point of reference, there is a distinction between registration
+   and publication of addresses. For IP addresses, the IANA is the root
+   registration authority and the DNS a publication method. For NSAPs,
+   Annex A of the network service definition, ISO8348 [6], describes the
+   root registration authority and this memo defines how the DNS is used
+   as a publication method.
+
+
+
+
+
+
+Manning & Colella                                               [Page 2]
+
+RFC 1706                      DNS NSAP RRs                  October 1994
+
+
+4.  Structure of NSAPs
+
+   NSAPs are hierarchically structured to allow distributed
+   administration and efficient routing. Distributed administration
+   permits subdelegated addressing authorities to, as allowed by the
+   delegator, further structure the portion of the NSAP space under
+   their delegated control.  Accomodating this distributed authority
+   requires that there be little or no a priori knowledge of the
+   structure of NSAPs built into DNS resolvers and servers.
+
+   For the purposes of this memo, NSAPs can be thought of as a tree of
+   identifiers. The root of the tree is ISO8348 [6], and has as its
+   immediately registered subordinates the one-octet Authority and
+   Format Identifiers (AFIs) defined there. The size of subsequently-
+   defined fields depends on which branch of the tree is taken. The
+   depth of the tree varies according to the authority responsible for
+   defining subsequent fields.
+
+   An example is the authority under which U.S. GOSIP defines NSAPs [2].
+   Under the AFI of 47, NIST (National Institute of Standards and
+   Technology) obtained a value of 0005 (the AFI of 47 defines the next
+   field as being two octets consisting of four BCD digits from the
+   International Code Designator space [3]). NIST defined the subsequent
+   fields in [2], as shown in Figure 1. The field immediately following
+   0005 is a format identifier for the rest of the U.S. GOSIP NSAP
+   structure, with a hex value of 80. Following this is the three-octet
+   field, values for which are allocated to network operators; the
+   registration authority for this field is delegated to GSA (General
+   Services Administration).
+
+   The last octet of the NSAP is the NSelector (NSel). In practice, the
+   NSAP minus the NSel identifies the CLNP protocol machine on a given
+   system, and the NSel identifies the CLNP user. Since there can be
+   more than one CLNP user (meaning multiple NSel values for a given
+   "base" NSAP), the representation of the NSAP should be CLNP-user
+   independent. To achieve this, an NSel value of zero shall be used
+   with all NSAP values stored in the DNS. An NSAP with NSel=0
+   identifies the network layer itself. It is left to the application
+   retrieving the NSAP to determine the appropriate value to use in that
+   instance of communication.
+
+   When CLNP is used to support TCP and UDP services, the NSel value
+   used is the appropriate IP PROTO value as registered with the IANA.
+   For "standard" OSI, the selection of NSel values is left as a matter
+   of local administration. Administrators of systems that support the
+   OSI transport protocol [4] in addition to TCP/UDP must select NSels
+   for use by OSI Transport that do not conflict with the IP PROTO
+   values.
+
+
+
+Manning & Colella                                               [Page 3]
+
+RFC 1706                      DNS NSAP RRs                  October 1994
+
+
+              |--------------|
+              | <-- IDP -->  |
+              |--------------|-------------------------------------|
+              | AFI |  IDI   |            <-- DSP -->              |
+              |-----|--------|-------------------------------------|
+              | 47  |  0005  | DFI | AA |Rsvd | RD |Area | ID |Sel |
+              |-----|--------|-----|----|-----|----|-----|----|----|
+       octets |  1  |   2    |  1  | 3  |  2  | 2  |  2  | 6  | 1  |
+              |-----|--------|-----|----|-----|----|-----|----|----|
+
+                    IDP    Initial Domain Part
+                    AFI    Authority and Format Identifier
+                    IDI    Initial Domain Identifier
+                    DSP    Domain Specific Part
+                    DFI    DSP Format Identifier
+                    AA     Administrative Authority
+                    Rsvd   Reserved
+                    RD     Routing Domain Identifier
+                    Area   Area Identifier
+                    ID     System Identifier
+                    SEL    NSAP Selector
+
+                  Figure 1: GOSIP Version 2 NSAP structure.
+
+
+   In the NSAP RRs in Master Files and in the printed text in this memo,
+   NSAPs are often represented as a string of "."-separated hex values.
+   The values correspond to convenient divisions of the NSAP to make it
+   more readable. For example, the "."-separated fields might correspond
+   to the NSAP fields as defined by the appropriate authority (RARE,
+   U.S. GOSIP, ANSI, etc.). The use of this notation is strictly for
+   readability. The "."s do not appear in DNS packets and DNS servers
+   can ignore them when reading Master Files. For example, a printable
+   representation of the first four fields of a U.S. GOSIP NSAP might
+   look like
+
+                             47.0005.80.005a00
+
+   and a full U.S. GOSIP NSAP might appear as
+
+             47.0005.80.005a00.0000.1000.0020.00800a123456.00.
+
+   Other NSAP formats have different lengths and different
+   administratively defined field widths to accomodate different
+   requirements. For more information on NSAP formats in use see RFC
+   1629 [1].
+
+
+
+
+
+Manning & Colella                                               [Page 4]
+
+RFC 1706                      DNS NSAP RRs                  October 1994
+
+
+5.  The NSAP RR
+
+   The NSAP RR is defined with mnemonic "NSAP" and TYPE code 22
+   (decimal) and is used to map from domain names to NSAPs. Name-to-NSAP
+   mapping in the DNS using the NSAP RR operates analogously to IP
+   address lookup. A query is generated by the resolver requesting an
+   NSAP RR for a provided domain name.
+
+   NSAP RRs conform to the top level RR format and semantics as defined
+   in Section 3.2.1 of RFC 1035.
+
+                                            1  1  1  1  1  1
+              0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
+           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+           |                                               |
+           /                                               /
+           /                        NAME                   /
+           |                                               |
+           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+           |                    TYPE = NSAP                |
+           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+           |                    CLASS = IN                 |
+           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+           |                        TTL                    |
+           |                                               |
+           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+           |                      RDLENGTH                 |
+           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+           /                       RDATA                   /
+           /                                               /
+           +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+   where:
+
+   *  NAME: an owner name, i.e., the name of the node to which this
+      resource record pertains.
+
+   *  TYPE: two octets containing the NSAP RR TYPE code of 22 (decimal).
+
+   *  CLASS: two octets containing the RR IN CLASS code of 1.
+
+   *  TTL: a 32 bit signed integer that specifies the time interval in
+      seconds that the resource record may be cached before the source
+      of the information should again be consulted. Zero values are
+      interpreted to mean that the RR can only be used for the
+      transaction in progress, and should not be cached. For example,
+      SOA records are always distributed with a zero TTL to prohibit
+      caching. Zero values can also be used for extremely volatile data.
+
+
+
+Manning & Colella                                               [Page 5]
+
+RFC 1706                      DNS NSAP RRs                  October 1994
+
+
+   *  RDLENGTH: an unsigned 16 bit integer that specifies the length in
+      octets of the RDATA field.
+
+   *  RDATA: a variable length string of octets containing the NSAP.
+      The value is the binary encoding of the NSAP as it would appear in
+      the CLNP source or destination address field. A typical example of
+      such an NSAP (in hex) is shown below. For this NSAP, RDLENGTH is
+      20 (decimal); "."s have been omitted to emphasize that they don't
+      appear in the DNS packets.
+
+                 39840f80005a0000000001e13708002010726e00
+
+   NSAP RRs cause no additional section processing.
+
+6.  NSAP-to-name Mapping Using the PTR RR
+
+   The PTR RR is defined in RFC 1035. This RR is typically used under
+   the "IN-ADDR.ARPA" domain to map from IPv4 addresses to domain names.
+
+   Similarly, the PTR RR is used to map from NSAPs to domain names under
+   the "NSAP.INT" domain. A domain name is generated from the NSAP
+   according to the rules described below. A query is sent by the
+   resolver requesting a PTR RR for the provided domain name.
+
+   A domain name is generated from an NSAP by reversing the hex nibbles
+   of the NSAP, treating each nibble as a separate subdomain, and
+   appending the top-level subdomain name "NSAP.INT" to it. For example,
+   the domain name used in the reverse lookup for the NSAP
+
+             47.0005.80.005a00.0000.0001.e133.ffffff000162.00
+
+   would appear as
+
+     0.0.2.6.1.0.0.0.f.f.f.f.f.f.3.3.1.e.1.0.0.0.0.0.0.0.0.0.a.5.0.0. \
+                         0.8.5.0.0.0.7.4.NSAP.INT.
+
+   [Implementation note: For sanity's sake user interfaces should be
+   designed to allow users to enter NSAPs using their natural order,
+   i.e., as they are typically written on paper. Also, arbitrary "."s
+   should be allowed (and ignored) on input.]
+
+7.  Master File Format
+
+   The format of NSAP RRs (and NSAP-related PTR RRs) in Master Files
+   conforms to Section 5, "Master Files," of RFC 1035. Below are
+   examples of the use of these RRs in Master Files to support name-to-
+   NSAP and NSAP-to-name mapping.
+
+
+
+
+Manning & Colella                                               [Page 6]
+
+RFC 1706                      DNS NSAP RRs                  October 1994
+
+
+   The NSAP RR introduces a new hex string format for the RDATA field.
+   The format is "0x" (i.e., a zero followed by an 'x' character)
+   followed by a variable length string of hex characters (0 to 9, a to
+   f). The hex string is case-insensitive. "."s (i.e., periods) may be
+   inserted in the hex string anywhere after the "0x" for readability.
+   The "."s have no significance other than for readability and are not
+   propagated in the protocol (e.g., queries or zone transfers).
+
+
+   ;;;;;;
+   ;;;;;; Master File for domain nsap.nist.gov.
+   ;;;;;;
+
+
+   @      IN     SOA    emu.ncsl.nist.gov.  root.emu.ncsl.nist.gov. (
+                                     1994041800   ; Serial  - date
+                                     1800         ; Refresh - 30 minutes
+                                     300          ; Retry   - 5 minutes
+                                     604800       ; Expire  - 7 days
+                                     3600 )       ; Minimum - 1 hour
+          IN     NS     emu.ncsl.nist.gov.
+          IN     NS     tuba.nsap.lanl.gov.
+   ;
+   ;
+   $ORIGIN nsap.nist.gov.
+   ;
+   ;     hosts
+   ;
+   bsdi1    IN  NSAP  0x47.0005.80.005a00.0000.0001.e133.ffffff000161.00
+            IN  A     129.6.224.161
+            IN  HINFO PC_486    BSDi1.1
+   ;
+   bsdi2    IN  NSAP  0x47.0005.80.005a00.0000.0001.e133.ffffff000162.00
+            IN  A     129.6.224.162
+            IN  HINFO PC_486    BSDi1.1
+   ;
+   cursive  IN  NSAP  0x47.0005.80.005a00.0000.0001.e133.ffffff000171.00
+            IN  A     129.6.224.171
+            IN  HINFO PC_386    DOS_5.0/NCSA_Telnet(TUBA)
+   ;
+   infidel  IN  NSAP  0x47.0005.80.005a00.0000.0001.e133.ffffff000164.00
+            IN  A     129.6.55.164
+            IN  HINFO PC/486    BSDi1.0(TUBA)
+   ;
+   ;     routers
+   ;
+   cisco1   IN  NSAP  0x47.0005.80.005a00.0000.0001.e133.aaaaaa000151.00
+            IN  A     129.6.224.151
+
+
+
+Manning & Colella                                               [Page 7]
+
+RFC 1706                      DNS NSAP RRs                  October 1994
+
+
+            IN  A     129.6.225.151
+            IN  A     129.6.229.151
+   ;
+   3com1    IN  NSAP  0x47.0005.80.005a00.0000.0001.e133.aaaaaa000111.00
+            IN  A     129.6.224.111
+            IN  A     129.6.225.111
+            IN  A     129.6.228.111
+
+
+
+
+   ;;;;;;
+   ;;;;;; Master File for reverse mapping of NSAPs under the
+   ;;;;;;     NSAP prefix:
+   ;;;;;;
+   ;;;;;;          47.0005.80.005a00.0000.0001.e133
+   ;;;;;;
+
+
+   @      IN     SOA    emu.ncsl.nist.gov.  root.emu.ncsl.nist.gov. (
+                                     1994041800   ; Serial  - date
+                                     1800         ; Refresh - 30 minutes
+                                     300          ; Retry   - 5 minutes
+                                     604800       ; Expire  - 7 days
+                                     3600 )       ; Minimum - 1 hour
+          IN     NS     emu.ncsl.nist.gov.
+          IN     NS     tuba.nsap.lanl.gov.
+   ;
+   ;
+   $ORIGIN 3.3.1.e.1.0.0.0.0.0.0.0.0.0.a.5.0.0.0.8.5.0.0.0.7.4.NSAP.INT.
+   ;
+   0.0.1.6.1.0.0.0.f.f.f.f.f.f  IN    PTR  bsdi1.nsap.nist.gov.
+   ;
+   0.0.2.6.1.0.0.0.f.f.f.f.f.f  IN    PTR  bsdi2.nsap.nist.gov.
+   ;
+   0.0.1.7.1.0.0.0.f.f.f.f.f.f  IN    PTR  cursive.nsap.nist.gov.
+   ;
+   0.0.4.6.1.0.0.0.f.f.f.f.f.f  IN    PTR  infidel.nsap.nist.gov.
+   ;
+   0.0.1.5.1.0.0.0.a.a.a.a.a.a  IN    PTR  cisco1.nsap.nist.gov.
+   ;
+   0.0.1.1.1.0.0.0.a.a.a.a.a.a  IN    PTR  3com1.nsap.nist.gov.
+
+8.  Security Considerations
+
+   Security issues are not discussed in this memo.
+
+
+
+
+
+Manning & Colella                                               [Page 8]
+
+RFC 1706                      DNS NSAP RRs                  October 1994
+
+
+9.  Authors' Addresses
+
+   Bill Manning
+   USC/Information Sciences Institute
+   4676 Admiralty Way
+   Marina del Rey, CA. 90292
+   USA
+
+   Phone: +1.310.822.1511
+   EMail: bmanning@isi.edu
+
+
+   Richard Colella
+   National Institute of Standards and Technology
+   Technology/B217
+   Gaithersburg, MD 20899
+   USA
+
+   Phone: +1 301-975-3627
+   Fax: +1 301 590-0932
+   EMail: colella@nist.gov
+
+10.  References
+
+   [1] Colella, R., Gardner, E., Callon, R., and Y. Rekhter, "Guidelines
+       for OSI NSAP Allocation inh the Internet", RFC 1629, NIST,
+       Wellfleet, Mitre, T.J. Watson Research Center, IBM Corp., May
+       1994.
+
+   [2] GOSIP Advanced Requirements Group.  Government Open Systems
+       Interconnection Profile (GOSIP) Version 2. Federal Information
+       Processing Standard 146-1, U.S. Department of Commerce, National
+       Institute of Standards and Technology, Gaithersburg, MD, April
+       1991.
+
+   [3] ISO/IEC.  Data interchange - structures for the identification of
+       organization.  International Standard 6523, ISO/IEC JTC 1,
+       Switzerland, 1984.
+
+   [4] ISO/IEC. Connection oriented transport protocol specification.
+       International Standard 8073, ISO/IEC JTC 1, Switzerland, 1986.
+
+   [5] ISO/IEC.  Protocol for Providing the Connectionless-mode Network
+       Service.  International Standard 8473, ISO/IEC JTC 1,
+       Switzerland, 1986.
+
+
+
+
+
+
+Manning & Colella                                               [Page 9]
+
+RFC 1706                      DNS NSAP RRs                  October 1994
+
+
+   [6] ISO/IEC. Information Processing Systems -- Data Communications --
+       Network Service Definition.  International Standard 8348, ISO/IEC
+       JTC 1, Switzerland, 1993.
+
+   [7] Mockapetris, P., "Domain Names -- Concepts and Facilities", STD
+       13, RFC 1034, USC/Information Sciences Institute, November 1987.
+
+   [8] Mockapetris, P., "Domain Names -- Implementation and
+       Specification", STD 13, RFC 1035, USC/Information Sciences
+       Institute, November 1987.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Manning & Colella                                              [Page 10]
+
diff --git a/doc/rfc/rfc1712.txt b/doc/rfc/rfc1712.txt
new file mode 100644
index 0000000..40d8857
--- /dev/null
+++ b/doc/rfc/rfc1712.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Network Working Group                                         C. Farrell
+Request for Comments: 1712                                    M. Schulze
+Category: Experimental                                       S. Pleitner
+                                                              D. Baldoni
+                                         Curtin University of Technology
+                                                           November 1994
+
+
+                 DNS Encoding of Geographical Location
+
+Status of this Memo
+
+   This memo defines an Experimental Protocol for the Internet
+   community.  This memo does not specify an Internet standard of any
+   kind.  Discussion and suggestions for improvement are requested.
+   Distribution of this memo is unlimited.
+
+Abstract
+
+   This document defines the format of a new Resource Record (RR) for
+   the Domain Naming System (DNS), and reserves a corresponding DNS type
+   mnemonic and numerical code.  This definition deals with associating
+   geographical host location mappings to host names within a domain.
+   The data shown in this document is fictitious and does not
+   necessarily reflect the real Internet.
+
+1. Introduction
+
+   It has been a long standing problem to relate IP numbers to
+   geographical locations. The availability of Geographical location
+   information has immediate applications in network management.  Such
+   information can be used to supplement the data already provided by
+   utilities such as whois [Har85], traceroute [VJ89], and nslookup
+   [UCB89].  The usefulness and functionality of these already widely
+   used tools would be greatly enhanced by the provision of reliable
+   geographical location information.
+
+   The ideal way to manage and maintain a database of information, such
+   as geographical location of internet hosts, is to delegate
+   responsibility to local domain administrators. A large distributed
+   database could be implemented with a simple mechanism for updating
+   the local information.  A query mechanism also has to be available
+   for checking local entries, as well as inquiring about data from
+   non-local domains.
+
+
+
+
+
+
+
+Farrell, Schulze, Pleitner & Baldoni                            [Page 1]
+
+RFC 1712         DNS Encoding of Geographical Location     November 1994
+
+
+2. Background
+
+   The Internet continues to grow at an ever increasing rate with IP
+   numbers allocated on a first-come-first-serve basis.  Deciding when
+   and how to setup a database of geographical information about
+   internet hosts presented a number of options.  The uumap project
+   [UU85] was the first serious attempt to collect geographical location
+   data from sites and store it centrally.  This project met with
+   limited success because of the difficulty in maintaining and updating
+   a large central database.  Another problem was the lack of tools for
+   the checking the data supplied, this problem resulted in some
+   erroneous data entering the database.
+
+2.1 SNMP:
+
+   Using an SNMP get request on the sysLocation MIB (Management
+   Information Base) variable was also an option, however this would
+   require the host to be running an appropriate agent with public read
+   access.  It was also felt that MIB data should reflect local
+   management data (e.g., "this" host is on level 5 room 74) rather than
+   a hosts geographical position.  This view is supported in the
+   examples given in literature in this area [ROSE91].
+
+2.2 X500:
+
+   The X.500 Directory service [X.500.88] defined as part of the ISO
+   standards also appears as a potential provider of geographical
+   location data. However due to the limited implementations of this
+   service it was decided to defer this until this service gains wider
+   use and acceptance within the Internet community.
+
+2.3 BIND:
+
+   The DNS [Mock87a][Mock87b] represents an existing system ideally
+   suited to the provision of host specific information. The DNS is a
+   widely used and well-understood mechanism for providing a distributed
+   database of such information and its extensible nature allows it to
+   be used to disseminate virtually any information.  The most commonly
+   used DNS implementation is the Berkeley Internet Name Domain server
+   BIND [UCB89].  The information we wished to make available needed to
+   be updated locally but available globally; a perfect match with the
+   services provided by the DNS. Current DNS servers provide a variety
+   of useful information about hosts in their domain but lack the
+   ability to report a host's geographical location.
+
+
+
+
+
+
+
+Farrell, Schulze, Pleitner & Baldoni                            [Page 2]
+
+RFC 1712         DNS Encoding of Geographical Location     November 1994
+
+
+3. RDATA Format
+
+        MSB                                        LSB
+        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+        /                 LONGITUDE                  /
+        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+        /                  LATITUDE                  /
+        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+        /                  ALTITUDE                  /
+        +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+   where:
+
+   LONGITUDE The real number describing the longitude encoded as a
+             printable string. The precision is limited by 256 charcters
+             within the range -90..90 degrees. Positive numbers
+             indicate locations north of the equator.
+
+   LATITUDE The real number describing the latitude encoded as a
+            printable string. The precision is limited by 256 charcters
+            within the range -180..180 degrees. Positive numbers
+            indicate locations east of the prime meridian.
+
+   ALTITUDE The real number describing the altitude (in meters) from
+            mean sea-level encoded as a printable string. The precision
+            is limited by 256 charcters. Positive numbers indicate
+            locations above mean sea-level.
+
+   Latitude/Longitude/Altitude values are encoded as strings as to avoid
+   the precision limitations imposed by encoding as unsigned integers.
+   Although this might not be considered optimal, it allows for a very
+   high degree of precision with an acceptable average encoded record
+   length.
+
+4. The GPOS RR
+
+   The geographical location is defined with the mnemonic GPOS and type
+   code 27.
+
+   GPOS has the following format:
+           <owner> <ttl> <class> GPOS <longitude> <latitude> <altitude>
+
+   A floating point format was chosen to specify geographical locations
+   for reasons of simplicity.  This also guarantees a concise
+   unambiguous description of a location by enforcing three compulsory
+   numerical values to be specified.
+
+
+
+
+
+Farrell, Schulze, Pleitner & Baldoni                            [Page 3]
+
+RFC 1712         DNS Encoding of Geographical Location     November 1994
+
+
+   The owner, ttl, and class fields are optional and default to the last
+   defined value if omitted. The longitude is a floating point number
+   ranging from -90 to 90 with positive values indicating locations
+   north of the equator.  For example Perth, Western Australia is
+   located at 32^ 7` 19" south of the equator which would be specified
+   as -32.68820.  The latitude is a number ranging from -180.0 to 180.0.
+   For example Perth, Western Australia is located at 116^ 2' 25" east
+   of the prime meridian which would be specified as 116.86520.  Curtin
+   University, Perth is also 10 meters above sea-level.
+
+   The valid GPOS record for a host at Curtin University in  Perth
+   Western Australia would therefore be:
+
+                GPOS -32.6882 116.8652 10.0
+
+   There is no limit imposed on the number of decimal places, although
+   the length of the encoded string is limited to 256 characters for
+   each field. It is also suggested that administrators limit their
+   entries to the minimum number of necessary characters in each field.
+
+5. Master File Format
+
+   Each host requires its own GPOS field in the corresponding  DNS RR to
+   explicitly specify its geographical location and altitude.  If the
+   GPOS field is omitted, a DNS enquiry will return no position
+   information for that host.
+
+   Consider the following example:
+
+; Authoritative data for cs.curtin.edu.au.
+;
+@     IN    SOA     marsh.cs.curtin.edu.au. postmaster.cs.curtin.edu.au.
+                (
+                        94070503        ; Serial (yymmddnn)
+                        10800           ; Refresh (3 hours)
+                        3600            ; Retry (1 hour)
+                        3600000         ; Expire (1000 hours)
+                        86400           ; Minimum (24 hours)
+                )
+
+                IN      NS      marsh.cs.curtin.edu.au.
+
+marsh           IN      A       134.7.1.1
+                IN      MX      0       marsh
+                IN      HINFO   SGI-Indigo IRIX-4.0.5F
+                IN      GPOS    -32.6882 116.8652 10.0
+ftp             IN      CNAME   marsh
+
+
+
+
+Farrell, Schulze, Pleitner & Baldoni                            [Page 4]
+
+RFC 1712         DNS Encoding of Geographical Location     November 1994
+
+
+lillee          IN      A       134.7.1.2
+                IN      MX      0       marsh
+                IN      HINFO   SGI-Indigo IRIX-4.0.5F
+                IN      GPOS    -32.6882 116.8652 10.0
+
+hinault         IN      A       134.7.1.23
+                IN      MX      0       marsh
+                IN      HINFO   SUN-IPC SunOS-4.1.3
+                IN      GPOS    -22.6882 116.8652 250.0
+
+merckx          IN      A       134.7.1.24
+                IN      MX      0       marsh
+                IN      HINFO   SUN-IPC SunOS-4.1.1
+
+ambrose         IN      A       134.7.1.99
+                IN      MX      0       marsh
+                IN      HINFO   SGI-CHALLENGE_L IRIX-5.2
+                IN      GPOS    -32.6882 116.8652 10.0
+
+   The hosts marsh, lillee, and ambrose are all at the same geographical
+   location, Perth Western Australia (-32.68820 116.86520). The host
+   hinault is at a different geographical location, 10 degrees north of
+   Perth in the mountains (-22.6882 116.8652 250.0). For security
+   reasons we do not wish to give the location of the host merckx.
+
+   Although the GPOS clause is not a standard entry within BIND
+   configuration files, most vendor implementations seem to ignore
+   whatever is not understood upon startup of the DNS.  Usually this
+   will result in a number of warnings appearing in system log files,
+   but in no way alters naming information or impedes the DNS from
+   performing its normal duties.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Farrell, Schulze, Pleitner & Baldoni                            [Page 5]
+
+RFC 1712         DNS Encoding of Geographical Location     November 1994
+
+
+7. References
+
+   [ROSE91]        Rose M., "The Simple Book: An Introduction to
+                   Management of TCP/IP-based Internets", Prentice-Hall,
+                   Englewood Cliffs, New Jersey, 1991.
+
+   [X.500.88]      CCITT: The Directory - Overview of Concepts, Models
+                   and Services", Recommendations X.500 - X.521.
+
+   [Har82]         Harrenstein K, Stahl M., and E. Feinler,
+                   "NICNAME/WHOIS" RFC 812, SRI NIC, March 1982.
+
+   [Mock87a]       Mockapetris P., "Domain Names - Concepts and
+                   Facilities", STD 13, RFC 1034, USC/Information
+                   Sciences Institute, November 1987.
+
+   [Mock87b]       Mockapetris P., "Domain Names - Implementation and
+                   Specification", STD 13, RFC 1035, USC/Information
+                   Sciences Institute, November 1987.
+
+   [FRB93]         Ford P., Rekhter Y., and H-W. Braun, "Improving the
+                   Routing and Addressing of IP", IEEE Network
+                   Vol.7, No. 3, pp. 11-15, May 1993.
+
+   [VJ89]          Jacobsen V., "The Traceroute(8) Manual Page",
+                   Lawrence Berkeley Laboratory, Berkeley,
+                   CA, February 1989.
+
+   [UCB89]         University of California, "BIND: Berkeley Internet
+                   Name Domain Server", 1989.
+   [UU85]          UUCP Mapping Project, Software available via
+                   anonymous FTP from ftp.uu.net., 1985.
+
+8. Security Considerations
+
+   Once information has been entered into the DNS, it is considered
+   public.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Farrell, Schulze, Pleitner & Baldoni                            [Page 6]
+
+RFC 1712         DNS Encoding of Geographical Location     November 1994
+
+
+9. Authors' Addresses
+
+   Craig Farrell
+   Department of Computer Science
+   Curtin University of technology
+   GPO Box U1987 Perth,
+   Western Australia
+
+   EMail: craig@cs.curtin.edu.au
+
+
+   Mike Schulze
+   Department of Computer Science
+   Curtin University of technology
+   GPO Box U1987 Perth,
+   Western Australia
+
+   EMail: mike@cs.curtin.edu.au
+
+
+   Scott Pleitner
+   Department of Computer Science
+   Curtin University of technology
+   GPO Box U1987 Perth,
+   Western Australia
+
+   EMail: pleitner@cs.curtin.edu.au
+
+
+   Daniel Baldoni
+   Department of Computer Science
+   Curtin University of technology
+   GPO Box U1987 Perth,
+   Western Australia
+
+   EMail: flint@cs.curtin.edu.au
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Farrell, Schulze, Pleitner & Baldoni                            [Page 7]
+
diff --git a/doc/rfc/rfc1750.txt b/doc/rfc/rfc1750.txt
new file mode 100644
index 0000000..56d478c
--- /dev/null
+++ b/doc/rfc/rfc1750.txt
@@ -0,0 +1,1683 @@
+
+
+
+
+
+
+Network Working Group                                   D. Eastlake, 3rd
+Request for Comments: 1750                                           DEC
+Category: Informational                                       S. Crocker
+                                                               Cybercash
+                                                             J. Schiller
+                                                                     MIT
+                                                           December 1994
+
+
+                Randomness Recommendations for Security
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  This memo
+   does not specify an Internet standard of any kind.  Distribution of
+   this memo is unlimited.
+
+Abstract
+
+   Security systems today are built on increasingly strong cryptographic
+   algorithms that foil pattern analysis attempts. However, the security
+   of these systems is dependent on generating secret quantities for
+   passwords, cryptographic keys, and similar quantities.  The use of
+   pseudo-random processes to generate secret quantities can result in
+   pseudo-security.  The sophisticated attacker of these security
+   systems may find it easier to reproduce the environment that produced
+   the secret quantities, searching the resulting small set of
+   possibilities, than to locate the quantities in the whole of the
+   number space.
+
+   Choosing random quantities to foil a resourceful and motivated
+   adversary is surprisingly difficult.  This paper points out many
+   pitfalls in using traditional pseudo-random number generation
+   techniques for choosing such quantities.  It recommends the use of
+   truly random hardware techniques and shows that the existing hardware
+   on many systems can be used for this purpose.  It provides
+   suggestions to ameliorate the problem when a hardware solution is not
+   available.  And it gives examples of how large such quantities need
+   to be for some particular applications.
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake, Crocker & Schiller                                    [Page 1]
+
+RFC 1750        Randomness Recommendations for Security    December 1994
+
+
+Acknowledgements
+
+   Comments on this document that have been incorporated were received
+   from (in alphabetic order) the following:
+
+        David M. Balenson (TIS)
+        Don Coppersmith (IBM)
+        Don T. Davis (consultant)
+        Carl Ellison (Stratus)
+        Marc Horowitz (MIT)
+        Christian Huitema (INRIA)
+        Charlie Kaufman (IRIS)
+        Steve Kent (BBN)
+        Hal Murray (DEC)
+        Neil Haller (Bellcore)
+        Richard Pitkin (DEC)
+        Tim Redmond (TIS)
+        Doug Tygar (CMU)
+
+Table of Contents
+
+   1. Introduction........................................... 3
+   2. Requirements........................................... 4
+   3. Traditional Pseudo-Random Sequences.................... 5
+   4. Unpredictability....................................... 7
+   4.1 Problems with Clocks and Serial Numbers............... 7
+   4.2 Timing and Content of External Events................  8
+   4.3 The Fallacy of Complex Manipulation..................  8
+   4.4 The Fallacy of Selection from a Large Database.......  9
+   5. Hardware for Randomness............................... 10
+   5.1 Volume Required...................................... 10
+   5.2 Sensitivity to Skew.................................. 10
+   5.2.1 Using Stream Parity to De-Skew..................... 11
+   5.2.2 Using Transition Mappings to De-Skew............... 12
+   5.2.3 Using FFT to De-Skew............................... 13
+   5.2.4 Using Compression to De-Skew....................... 13
+   5.3 Existing Hardware Can Be Used For Randomness......... 14
+   5.3.1 Using Existing Sound/Video Input................... 14
+   5.3.2 Using Existing Disk Drives......................... 14
+   6. Recommended Non-Hardware Strategy..................... 14
+   6.1 Mixing Functions..................................... 15
+   6.1.1 A Trivial Mixing Function.......................... 15
+   6.1.2 Stronger Mixing Functions.......................... 16
+   6.1.3 Diff-Hellman as a Mixing Function.................. 17
+   6.1.4 Using a Mixing Function to Stretch Random Bits..... 17
+   6.1.5 Other Factors in Choosing a Mixing Function........ 18
+   6.2 Non-Hardware Sources of Randomness................... 19
+   6.3 Cryptographically Strong Sequences................... 19
+
+
+
+Eastlake, Crocker & Schiller                                    [Page 2]
+
+RFC 1750        Randomness Recommendations for Security    December 1994
+
+
+   6.3.1 Traditional Strong Sequences....................... 20
+   6.3.2 The Blum Blum Shub Sequence Generator.............. 21
+   7. Key Generation Standards.............................. 22
+   7.1 US DoD Recommendations for Password Generation....... 23
+   7.2 X9.17 Key Generation................................. 23
+   8. Examples of Randomness Required....................... 24
+   8.1  Password Generation................................. 24
+   8.2 A Very High Security Cryptographic Key............... 25
+   8.2.1 Effort per Key Trial............................... 25
+   8.2.2 Meet in the Middle Attacks......................... 26
+   8.2.3 Other Considerations............................... 26
+   9. Conclusion............................................ 27
+   10. Security Considerations.............................. 27
+   References............................................... 28
+   Authors' Addresses....................................... 30
+
+1. Introduction
+
+   Software cryptography is coming into wider use.  Systems like
+   Kerberos, PEM, PGP, etc. are maturing and becoming a part of the
+   network landscape [PEM].  These systems provide substantial
+   protection against snooping and spoofing.  However, there is a
+   potential flaw.  At the heart of all cryptographic systems is the
+   generation of secret, unguessable (i.e., random) numbers.
+
+   For the present, the lack of generally available facilities for
+   generating such unpredictable numbers is an open wound in the design
+   of cryptographic software.  For the software developer who wants to
+   build a key or password generation procedure that runs on a wide
+   range of hardware, the only safe strategy so far has been to force
+   the local installation to supply a suitable routine to generate
+   random numbers.  To say the least, this is an awkward, error-prone
+   and unpalatable solution.
+
+   It is important to keep in mind that the requirement is for data that
+   an adversary has a very low probability of guessing or determining.
+   This will fail if pseudo-random data is used which only meets
+   traditional statistical tests for randomness or which is based on
+   limited range sources, such as clocks.  Frequently such random
+   quantities are determinable by an adversary searching through an
+   embarrassingly small space of possibilities.
+
+   This informational document suggests techniques for producing random
+   quantities that will be resistant to such attack.  It recommends that
+   future systems include hardware random number generation or provide
+   access to existing hardware that can be used for this purpose.  It
+   suggests methods for use if such hardware is not available.  And it
+   gives some estimates of the number of random bits required for sample
+
+
+
+Eastlake, Crocker & Schiller                                    [Page 3]
+
+RFC 1750        Randomness Recommendations for Security    December 1994
+
+
+   applications.
+
+2. Requirements
+
+   Probably the most commonly encountered randomness requirement today
+   is the user password. This is usually a simple character string.
+   Obviously, if a password can be guessed, it does not provide
+   security.  (For re-usable passwords, it is desirable that users be
+   able to remember the password.  This may make it advisable to use
+   pronounceable character strings or phrases composed on ordinary
+   words.  But this only affects the format of the password information,
+   not the requirement that the password be very hard to guess.)
+
+   Many other requirements come from the cryptographic arena.
+   Cryptographic techniques can be used to provide a variety of services
+   including confidentiality and authentication.  Such services are
+   based on quantities, traditionally called "keys", that are unknown to
+   and unguessable by an adversary.
+
+   In some cases, such as the use of symmetric encryption with the one
+   time pads [CRYPTO*] or the US Data Encryption Standard [DES], the
+   parties who wish to communicate confidentially and/or with
+   authentication must all know the same secret key.  In other cases,
+   using what are called asymmetric or "public key" cryptographic
+   techniques, keys come in pairs.  One key of the pair is private and
+   must be kept secret by one party, the other is public and can be
+   published to the world.  It is computationally infeasible to
+   determine the private key from the public key [ASYMMETRIC, CRYPTO*].
+
+   The frequency and volume of the requirement for random quantities
+   differs greatly for different cryptographic systems.  Using pure RSA
+   [CRYPTO*], random quantities are required when the key pair is
+   generated, but thereafter any number of messages can be signed
+   without any further need for randomness.  The public key Digital
+   Signature Algorithm that has been proposed by the US National
+   Institute of Standards and Technology (NIST) requires good random
+   numbers for each signature.  And encrypting with a one time pad, in
+   principle the strongest possible encryption technique, requires a
+   volume of randomness equal to all the messages to be processed.
+
+   In most of these cases, an adversary can try to determine the
+   "secret" key by trial and error.  (This is possible as long as the
+   key is enough smaller than the message that the correct key can be
+   uniquely identified.)  The probability of an adversary succeeding at
+   this must be made acceptably low, depending on the particular
+   application.  The size of the space the adversary must search is
+   related to the amount of key "information" present in the information
+   theoretic sense [SHANNON].  This depends on the number of different
+
+
+
+Eastlake, Crocker & Schiller                                    [Page 4]
+
+RFC 1750        Randomness Recommendations for Security    December 1994
+
+
+   secret values possible and the probability of each value as follows:
+
+                      -----
+                       \
+        Bits-of-info =  \  - p   * log  ( p  )
+                        /     i       2    i
+                       /
+                      -----
+
+   where i varies from 1 to the number of possible secret values and p
+   sub i is the probability of the value numbered i.  (Since p sub i is
+   less than one, the log will be negative so each term in the sum will
+   be non-negative.)
+
+   If there are 2^n different values of equal probability, then n bits
+   of information are present and an adversary would, on the average,
+   have to try half of the values, or 2^(n-1) , before guessing the
+   secret quantity.  If the probability of different values is unequal,
+   then there is less information present and fewer guesses will, on
+   average, be required by an adversary.  In particular, any values that
+   the adversary can know are impossible, or are of low probability, can
+   be initially ignored by an adversary, who will search through the
+   more probable values first.
+
+   For example, consider a cryptographic system that uses 56 bit keys.
+   If these 56 bit keys are derived by using a fixed pseudo-random
+   number generator that is seeded with an 8 bit seed, then an adversary
+   needs to search through only 256 keys (by running the pseudo-random
+   number generator with every possible seed), not the 2^56 keys that
+   may at first appear to be the case. Only 8 bits of "information" are
+   in these 56 bit keys.
+
+3. Traditional Pseudo-Random Sequences
+
+   Most traditional sources of random numbers use deterministic sources
+   of "pseudo-random" numbers.  These typically start with a "seed"
+   quantity and use numeric or logical operations to produce a sequence
+   of values.
+
+   [KNUTH] has a classic exposition on pseudo-random numbers.
+   Applications he mentions are simulation of natural phenomena,
+   sampling, numerical analysis, testing computer programs, decision
+   making, and games.  None of these have the same characteristics as
+   the sort of security uses we are talking about.  Only in the last two
+   could there be an adversary trying to find the random quantity.
+   However, in these cases, the adversary normally has only a single
+   chance to use a guessed value.  In guessing passwords or attempting
+   to break an encryption scheme, the adversary normally has many,
+
+
+
+Eastlake, Crocker & Schiller                                    [Page 5]
+
+RFC 1750        Randomness Recommendations for Security    December 1994
+
+
+   perhaps unlimited, chances at guessing the correct value and should
+   be assumed to be aided by a computer.
+
+   For testing the "randomness" of numbers, Knuth suggests a variety of
+   measures including statistical and spectral.  These tests check
+   things like autocorrelation between different parts of a "random"
+   sequence or distribution of its values.  They could be met by a
+   constant stored random sequence, such as the "random" sequence
+   printed in the CRC Standard Mathematical Tables [CRC].
+
+   A typical pseudo-random number generation technique, known as a
+   linear congruence pseudo-random number generator, is modular
+   arithmetic where the N+1th value is calculated from the Nth value by
+
+        V    = ( V  * a + b )(Mod c)
+         N+1      N
+
+   The above technique has a strong relationship to linear shift
+   register pseudo-random number generators, which are well understood
+   cryptographically [SHIFT*].  In such generators bits are introduced
+   at one end of a shift register as the Exclusive Or (binary sum
+   without carry) of bits from selected fixed taps into the register.
+
+   For example:
+
+      +----+     +----+     +----+                      +----+
+      | B  | <-- | B  | <-- | B  | <--  . . . . . . <-- | B  | <-+
+      |  0 |     |  1 |     |  2 |                      |  n |   |
+      +----+     +----+     +----+                      +----+   |
+        |                     |            |                     |
+        |                     |            V                  +-----+
+        |                     V            +----------------> |     |
+        V                     +-----------------------------> | XOR |
+        +---------------------------------------------------> |     |
+                                                              +-----+
+
+
+       V    = ( ( V  * 2 ) + B .xor. B ... )(Mod 2^n)
+        N+1         N         0       2
+
+   The goodness of traditional pseudo-random number generator algorithms
+   is measured by statistical tests on such sequences.  Carefully chosen
+   values of the initial V and a, b, and c or the placement of shift
+   register tap in the above simple processes can produce excellent
+   statistics.
+
+
+
+
+
+
+Eastlake, Crocker & Schiller                                    [Page 6]
+
+RFC 1750        Randomness Recommendations for Security    December 1994
+
+
+   These sequences may be adequate in simulations (Monte Carlo
+   experiments) as long as the sequence is orthogonal to the structure
+   of the space being explored.  Even there, subtle patterns may cause
+   problems.  However, such sequences are clearly bad for use in
+   security applications.  They are fully predictable if the initial
+   state is known.  Depending on the form of the pseudo-random number
+   generator, the sequence may be determinable from observation of a
+   short portion of the sequence [CRYPTO*, STERN].  For example, with
+   the generators above, one can determine V(n+1) given knowledge of
+   V(n).  In fact, it has been shown that with these techniques, even if
+   only one bit of the pseudo-random values is released, the seed can be
+   determined from short sequences.
+
+   Not only have linear congruent generators been broken, but techniques
+   are now known for breaking all polynomial congruent generators
+   [KRAWCZYK].
+
+4. Unpredictability
+
+   Randomness in the traditional sense described in section 3 is NOT the
+   same as the unpredictability required for security use.
+
+   For example, use of a widely available constant sequence, such as
+   that from the CRC tables, is very weak against an adversary. Once
+   they learn of or guess it, they can easily break all security, future
+   and past, based on the sequence [CRC].  Yet the statistical
+   properties of these tables are good.
+
+   The following sections describe the limitations of some randomness
+   generation techniques and sources.
+
+4.1 Problems with Clocks and Serial Numbers
+
+   Computer clocks, or similar operating system or hardware values,
+   provide significantly fewer real bits of unpredictability than might
+   appear from their specifications.
+
+   Tests have been done on clocks on numerous systems and it was found
+   that their behavior can vary widely and in unexpected ways.  One
+   version of an operating system running on one set of hardware may
+   actually provide, say, microsecond resolution in a clock while a
+   different configuration of the "same" system may always provide the
+   same lower bits and only count in the upper bits at much lower
+   resolution.  This means that successive reads on the clock may
+   produce identical values even if enough time has passed that the
+   value "should" change based on the nominal clock resolution. There
+   are also cases where frequently reading a clock can produce
+   artificial sequential values because of extra code that checks for
+
+
+
+Eastlake, Crocker & Schiller                                    [Page 7]
+
+RFC 1750        Randomness Recommendations for Security    December 1994
+
+
+   the clock being unchanged between two reads and increases it by one!
+   Designing portable application code to generate unpredictable numbers
+   based on such system clocks is particularly challenging because the
+   system designer does not always know the properties of the system
+   clocks that the code will execute on.
+
+   Use of a hardware serial number such as an Ethernet address may also
+   provide fewer bits of uniqueness than one would guess.  Such
+   quantities are usually heavily structured and subfields may have only
+   a limited range of possible values or values easily guessable based
+   on approximate date of manufacture or other data.  For example, it is
+   likely that most of the Ethernet cards installed on Digital Equipment
+   Corporation (DEC) hardware within DEC were manufactured by DEC
+   itself, which significantly limits the range of built in addresses.
+
+   Problems such as those described above related to clocks and serial
+   numbers make code to produce unpredictable quantities difficult if
+   the code is to be ported across a variety of computer platforms and
+   systems.
+
+4.2 Timing and Content of External Events
+
+   It is possible to measure the timing and content of mouse movement,
+   key strokes, and similar user events.  This is a reasonable source of
+   unguessable data with some qualifications.  On some machines, inputs
+   such as key strokes are buffered.  Even though the user's inter-
+   keystroke timing may have sufficient variation and unpredictability,
+   there might not be an easy way to access that variation.  Another
+   problem is that no standard method exists to sample timing details.
+   This makes it hard to build standard software intended for
+   distribution to a large range of machines based on this technique.
+
+   The amount of mouse movement or the keys actually hit are usually
+   easier to access than timings but may yield less unpredictability as
+   the user may provide highly repetitive input.
+
+   Other external events, such as network packet arrival times, can also
+   be used with care.  In particular, the possibility of manipulation of
+   such times by an adversary must be considered.
+
+4.3 The Fallacy of Complex Manipulation
+
+   One strategy which may give a misleading appearance of
+   unpredictability is to take a very complex algorithm (or an excellent
+   traditional pseudo-random number generator with good statistical
+   properties) and calculate a cryptographic key by starting with the
+   current value of a computer system clock as the seed.  An adversary
+   who knew roughly when the generator was started would have a
+
+
+
+Eastlake, Crocker & Schiller                                    [Page 8]
+
+RFC 1750        Randomness Recommendations for Security    December 1994
+
+
+   relatively small number of seed values to test as they would know
+   likely values of the system clock.  Large numbers of pseudo-random
+   bits could be generated but the search space an adversary would need
+   to check could be quite small.
+
+   Thus very strong and/or complex manipulation of data will not help if
+   the adversary can learn what the manipulation is and there is not
+   enough unpredictability in the starting seed value.  Even if they can
+   not learn what the manipulation is, they may be able to use the
+   limited number of results stemming from a limited number of seed
+   values to defeat security.
+
+   Another serious strategy error is to assume that a very complex
+   pseudo-random number generation algorithm will produce strong random
+   numbers when there has been no theory behind or analysis of the
+   algorithm.  There is a excellent example of this fallacy right near
+   the beginning of chapter 3 in [KNUTH] where the author describes a
+   complex algorithm.  It was intended that the machine language program
+   corresponding to the algorithm would be so complicated that a person
+   trying to read the code without comments wouldn't know what the
+   program was doing.  Unfortunately, actual use of this algorithm
+   showed that it almost immediately converged to a single repeated
+   value in one case and a small cycle of values in another case.
+
+   Not only does complex manipulation not help you if you have a limited
+   range of seeds but blindly chosen complex manipulation can destroy
+   the randomness in a good seed!
+
+4.4 The Fallacy of Selection from a Large Database
+
+   Another strategy that can give a misleading appearance of
+   unpredictability is selection of a quantity randomly from a database
+   and assume that its strength is related to the total number of bits
+   in the database.  For example, typical USENET servers as of this date
+   process over 35 megabytes of information per day.  Assume a random
+   quantity was selected by fetching 32 bytes of data from a random
+   starting point in this data.  This does not yield 32*8 = 256 bits
+   worth of unguessability.  Even after allowing that much of the data
+   is human language and probably has more like 2 or 3 bits of
+   information per byte, it doesn't yield 32*2.5 = 80 bits of
+   unguessability.  For an adversary with access to the same 35
+   megabytes the unguessability rests only on the starting point of the
+   selection.  That is, at best, about 25 bits of unguessability in this
+   case.
+
+   The same argument applies to selecting sequences from the data on a
+   CD ROM or Audio CD recording or any other large public database.  If
+   the adversary has access to the same database, this "selection from a
+
+
+
+Eastlake, Crocker & Schiller                                    [Page 9]
+
+RFC 1750        Randomness Recommendations for Security    December 1994
+
+
+   large volume of data" step buys very little.  However, if a selection
+   can be made from data to which the adversary has no access, such as
+   system buffers on an active multi-user system, it may be of some
+   help.
+
+5. Hardware for Randomness
+
+   Is there any hope for strong portable randomness in the future?
+   There might be.  All that's needed is a physical source of
+   unpredictable numbers.
+
+   A thermal noise or radioactive decay source and a fast, free-running
+   oscillator would do the trick directly [GIFFORD].  This is a trivial
+   amount of hardware, and could easily be included as a standard part
+   of a computer system's architecture.  Furthermore, any system with a
+   spinning disk or the like has an adequate source of randomness
+   [DAVIS].  All that's needed is the common perception among computer
+   vendors that this small additional hardware and the software to
+   access it is necessary and useful.
+
+5.1 Volume Required
+
+   How much unpredictability is needed?  Is it possible to quantify the
+   requirement in, say, number of random bits per second?
+
+   The answer is not very much is needed.  For DES, the key is 56 bits
+   and, as we show in an example in Section 8, even the highest security
+   system is unlikely to require a keying material of over 200 bits.  If
+   a series of keys are needed, it can be generated from a strong random
+   seed using a cryptographically strong sequence as explained in
+   Section 6.3.  A few hundred random bits generated once a day would be
+   enough using such techniques.  Even if the random bits are generated
+   as slowly as one per second and it is not possible to overlap the
+   generation process, it should be tolerable in high security
+   applications to wait 200 seconds occasionally.
+
+   These numbers are trivial to achieve.  It could be done by a person
+   repeatedly tossing a coin.  Almost any hardware process is likely to
+   be much faster.
+
+5.2 Sensitivity to Skew
+
+   Is there any specific requirement on the shape of the distribution of
+   the random numbers?  The good news is the distribution need not be
+   uniform.  All that is needed is a conservative estimate of how non-
+   uniform it is to bound performance.  Two simple techniques to de-skew
+   the bit stream are given below and stronger techniques are mentioned
+   in Section 6.1.2 below.
+
+
+
+Eastlake, Crocker & Schiller                                   [Page 10]
+
+RFC 1750        Randomness Recommendations for Security    December 1994
+
+
+5.2.1 Using Stream Parity to De-Skew
+
+   Consider taking a sufficiently long string of bits and map the string
+   to "zero" or "one".  The mapping will not yield a perfectly uniform
+   distribution, but it can be as close as desired.  One mapping that
+   serves the purpose is to take the parity of the string.  This has the
+   advantages that it is robust across all degrees of skew up to the
+   estimated maximum skew and is absolutely trivial to implement in
+   hardware.
+
+   The following analysis gives the number of bits that must be sampled:
+
+   Suppose the ratio of ones to zeros is 0.5 + e : 0.5 - e, where e is
+   between 0 and 0.5 and is a measure of the "eccentricity" of the
+   distribution.  Consider the distribution of the parity function of N
+   bit samples.  The probabilities that the parity will be one or zero
+   will be the sum of the odd or even terms in the binomial expansion of
+   (p + q)^N, where p = 0.5 + e, the probability of a one, and q = 0.5 -
+   e, the probability of a zero.
+
+   These sums can be computed easily as
+
+                         N            N
+        1/2 * ( ( p + q )  + ( p - q )  )
+   and
+                         N            N
+        1/2 * ( ( p + q )  - ( p - q )  ).
+
+   (Which one corresponds to the probability the parity will be 1
+   depends on whether N is odd or even.)
+
+   Since p + q = 1 and p - q = 2e, these expressions reduce to
+
+                       N
+        1/2 * [1 + (2e) ]
+   and
+                       N
+        1/2 * [1 - (2e) ].
+
+   Neither of these will ever be exactly 0.5 unless e is zero, but we
+   can bring them arbitrarily close to 0.5.  If we want the
+   probabilities to be within some delta d of 0.5, i.e. then
+
+                            N
+        ( 0.5 + ( 0.5 * (2e)  ) )  <  0.5 + d.
+
+
+
+
+
+
+Eastlake, Crocker & Schiller                                   [Page 11]
+
+RFC 1750        Randomness Recommendations for Security    December 1994
+
+
+   Solving for N yields N > log(2d)/log(2e).  (Note that 2e is less than
+   1, so its log is negative.  Division by a negative number reverses
+   the sense of an inequality.)
+
+   The following table gives the length of the string which must be
+   sampled for various degrees of skew in order to come within 0.001 of
+   a 50/50 distribution.
+
+                       +---------+--------+-------+
+                       | Prob(1) |    e   |    N  |
+                       +---------+--------+-------+
+                       |   0.5   |  0.00  |    1  |
+                       |   0.6   |  0.10  |    4  |
+                       |   0.7   |  0.20  |    7  |
+                       |   0.8   |  0.30  |   13  |
+                       |   0.9   |  0.40  |   28  |
+                       |   0.95  |  0.45  |   59  |
+                       |   0.99  |  0.49  |  308  |
+                       +---------+--------+-------+
+
+   The last entry shows that even if the distribution is skewed 99% in
+   favor of ones, the parity of a string of 308 samples will be within
+   0.001 of a 50/50 distribution.
+
+5.2.2 Using Transition Mappings to De-Skew
+
+   Another technique, originally due to von Neumann [VON NEUMANN], is to
+   examine a bit stream as a sequence of non-overlapping pairs. You
+   could then discard any 00 or 11 pairs found, interpret 01 as a 0 and
+   10 as a 1.  Assume the probability of a 1 is 0.5+e and the
+   probability of a 0 is 0.5-e where e is the eccentricity of the source
+   and described in the previous section.  Then the probability of each
+   pair is as follows:
+
+            +------+-----------------------------------------+
+            | pair |            probability                  |
+            +------+-----------------------------------------+
+            |  00  | (0.5 - e)^2          =  0.25 - e + e^2  |
+            |  01  | (0.5 - e)*(0.5 + e)  =  0.25     - e^2  |
+            |  10  | (0.5 + e)*(0.5 - e)  =  0.25     - e^2  |
+            |  11  | (0.5 + e)^2          =  0.25 + e + e^2  |
+            +------+-----------------------------------------+
+
+   This technique will completely eliminate any bias but at the expense
+   of taking an indeterminate number of input bits for any particular
+   desired number of output bits.  The probability of any particular
+   pair being discarded is 0.5 + 2e^2 so the expected number of input
+   bits to produce X output bits is X/(0.25 - e^2).
+
+
+
+Eastlake, Crocker & Schiller                                   [Page 12]
+
+RFC 1750        Randomness Recommendations for Security    December 1994
+
+
+   This technique assumes that the bits are from a stream where each bit
+   has the same probability of being a 0 or 1 as any other bit in the
+   stream and that bits are not correlated, i.e., that the bits are
+   identical independent distributions.  If alternate bits were from two
+   correlated sources, for example, the above analysis breaks down.
+
+   The above technique also provides another illustration of how a
+   simple statistical analysis can mislead if one is not always on the
+   lookout for patterns that could be exploited by an adversary.  If the
+   algorithm were mis-read slightly so that overlapping successive bits
+   pairs were used instead of non-overlapping pairs, the statistical
+   analysis given is the same; however, instead of provided an unbiased
+   uncorrelated series of random 1's and 0's, it instead produces a
+   totally predictable sequence of exactly alternating 1's and 0's.
+
+5.2.3 Using FFT to De-Skew
+
+   When real world data consists of strongly biased or correlated bits,
+   it may still contain useful amounts of randomness.  This randomness
+   can be extracted through use of the discrete Fourier transform or its
+   optimized variant, the FFT.
+
+   Using the Fourier transform of the data, strong correlations can be
+   discarded.  If adequate data is processed and remaining correlations
+   decay, spectral lines approaching statistical independence and
+   normally distributed randomness can be produced [BRILLINGER].
+
+5.2.4 Using Compression to De-Skew
+
+   Reversible compression techniques also provide a crude method of de-
+   skewing a skewed bit stream.  This follows directly from the
+   definition of reversible compression and the formula in Section 2
+   above for the amount of information in a sequence.  Since the
+   compression is reversible, the same amount of information must be
+   present in the shorter output than was present in the longer input.
+   By the Shannon information equation, this is only possible if, on
+   average, the probabilities of the different shorter sequences are
+   more uniformly distributed than were the probabilities of the longer
+   sequences.  Thus the shorter sequences are de-skewed relative to the
+   input.
+
+   However, many compression techniques add a somewhat predicatable
+   preface to their output stream and may insert such a sequence again
+   periodically in their output or otherwise introduce subtle patterns
+   of their own.  They should be considered only a rough technique
+   compared with those described above or in Section 6.1.2.  At a
+   minimum, the beginning of the compressed sequence should be skipped
+   and only later bits used for applications requiring random bits.
+
+
+
+Eastlake, Crocker & Schiller                                   [Page 13]
+
+RFC 1750        Randomness Recommendations for Security    December 1994
+
+
+5.3 Existing Hardware Can Be Used For Randomness
+
+   As described below, many computers come with hardware that can, with
+   care, be used to generate truly random quantities.
+
+5.3.1 Using Existing Sound/Video Input
+
+   Increasingly computers are being built with inputs that digitize some
+   real world analog source, such as sound from a microphone or video
+   input from a camera.  Under appropriate circumstances, such input can
+   provide reasonably high quality random bits.  The "input" from a
+   sound digitizer with no source plugged in or a camera with the lens
+   cap on, if the system has enough gain to detect anything, is
+   essentially thermal noise.
+
+   For example, on a SPARCstation, one can read from the /dev/audio
+   device with nothing plugged into the microphone jack.  Such data is
+   essentially random noise although it should not be trusted without
+   some checking in case of hardware failure.  It will, in any case,
+   need to be de-skewed as described elsewhere.
+
+   Combining this with compression to de-skew one can, in UNIXese,
+   generate a huge amount of medium quality random data by doing
+
+        cat /dev/audio | compress - >random-bits-file
+
+5.3.2 Using Existing Disk Drives
+
+   Disk drives have small random fluctuations in their rotational speed
+   due to chaotic air turbulence [DAVIS].  By adding low level disk seek
+   time instrumentation to a system, a series of measurements can be
+   obtained that include this randomness. Such data is usually highly
+   correlated so that significant processing is needed, including FFT
+   (see section 5.2.3).  Nevertheless experimentation has shown that,
+   with such processing, disk drives easily produce 100 bits a minute or
+   more of excellent random data.
+
+   Partly offsetting this need for processing is the fact that disk
+   drive failure will normally be rapidly noticed.  Thus, problems with
+   this method of random number generation due to hardware failure are
+   very unlikely.
+
+6. Recommended Non-Hardware Strategy
+
+   What is the best overall strategy for meeting the requirement for
+   unguessable random numbers in the absence of a reliable hardware
+   source?  It is to obtain random input from a large number of
+   uncorrelated sources and to mix them with a strong mixing function.
+
+
+
+Eastlake, Crocker & Schiller                                   [Page 14]
+
+RFC 1750        Randomness Recommendations for Security    December 1994
+
+
+   Such a function will preserve the randomness present in any of the
+   sources even if other quantities being combined are fixed or easily
+   guessable.  This may be advisable even with a good hardware source as
+   hardware can also fail, though this should be weighed against any
+   increase in the chance of overall failure due to added software
+   complexity.
+
+6.1 Mixing Functions
+
+   A strong mixing function is one which combines two or more inputs and
+   produces an output where each output bit is a different complex non-
+   linear function of all the input bits.  On average, changing any
+   input bit will change about half the output bits.  But because the
+   relationship is complex and non-linear, no particular output bit is
+   guaranteed to change when any particular input bit is changed.
+
+   Consider the problem of converting a stream of bits that is skewed
+   towards 0 or 1 to a shorter stream which is more random, as discussed
+   in Section 5.2 above.  This is simply another case where a strong
+   mixing function is desired, mixing the input bits to produce a
+   smaller number of output bits.  The technique given in Section 5.2.1
+   of using the parity of a number of bits is simply the result of
+   successively Exclusive Or'ing them which is examined as a trivial
+   mixing function immediately below.  Use of stronger mixing functions
+   to extract more of the randomness in a stream of skewed bits is
+   examined in Section 6.1.2.
+
+6.1.1 A Trivial Mixing Function
+
+   A trivial example for single bit inputs is the Exclusive Or function,
+   which is equivalent to addition without carry, as show in the table
+   below.  This is a degenerate case in which the one output bit always
+   changes for a change in either input bit.  But, despite its
+   simplicity, it will still provide a useful illustration.
+
+                   +-----------+-----------+----------+
+                   |  input 1  |  input 2  |  output  |
+                   +-----------+-----------+----------+
+                   |     0     |     0     |     0    |
+                   |     0     |     1     |     1    |
+                   |     1     |     0     |     1    |
+                   |     1     |     1     |     0    |
+                   +-----------+-----------+----------+
+
+   If inputs 1 and 2 are uncorrelated and combined in this fashion then
+   the output will be an even better (less skewed) random bit than the
+   inputs.  If we assume an "eccentricity" e as defined in Section 5.2
+   above, then the output eccentricity relates to the input eccentricity
+
+
+
+Eastlake, Crocker & Schiller                                   [Page 15]
+
+RFC 1750        Randomness Recommendations for Security    December 1994
+
+
+   as follows:
+
+        e       = 2 * e        * e
+         output        input 1    input 2
+
+   Since e is never greater than 1/2, the eccentricity is always
+   improved except in the case where at least one input is a totally
+   skewed constant.  This is illustrated in the following table where
+   the top and left side values are the two input eccentricities and the
+   entries are the output eccentricity:
+
+     +--------+--------+--------+--------+--------+--------+--------+
+     |    e   |  0.00  |  0.10  |  0.20  |  0.30  |  0.40  |  0.50  |
+     +--------+--------+--------+--------+--------+--------+--------+
+     |  0.00  |  0.00  |  0.00  |  0.00  |  0.00  |  0.00  |  0.00  |
+     |  0.10  |  0.00  |  0.02  |  0.04  |  0.06  |  0.08  |  0.10  |
+     |  0.20  |  0.00  |  0.04  |  0.08  |  0.12  |  0.16  |  0.20  |
+     |  0.30  |  0.00  |  0.06  |  0.12  |  0.18  |  0.24  |  0.30  |
+     |  0.40  |  0.00  |  0.08  |  0.16  |  0.24  |  0.32  |  0.40  |
+     |  0.50  |  0.00  |  0.10  |  0.20  |  0.30  |  0.40  |  0.50  |
+     +--------+--------+--------+--------+--------+--------+--------+
+
+   However, keep in mind that the above calculations assume that the
+   inputs are not correlated.  If the inputs were, say, the parity of
+   the number of minutes from midnight on two clocks accurate to a few
+   seconds, then each might appear random if sampled at random intervals
+   much longer than a minute.  Yet if they were both sampled and
+   combined with xor, the result would be zero most of the time.
+
+6.1.2 Stronger Mixing Functions
+
+   The US Government Data Encryption Standard [DES] is an example of a
+   strong mixing function for multiple bit quantities.  It takes up to
+   120 bits of input (64 bits of "data" and 56 bits of "key") and
+   produces 64 bits of output each of which is dependent on a complex
+   non-linear function of all input bits.  Other strong encryption
+   functions with this characteristic can also be used by considering
+   them to mix all of their key and data input bits.
+
+   Another good family of mixing functions are the "message digest" or
+   hashing functions such as The US Government Secure Hash Standard
+   [SHS] and the MD2, MD4, MD5 [MD2, MD4, MD5] series.  These functions
+   all take an arbitrary amount of input and produce an output mixing
+   all the input bits. The MD* series produce 128 bits of output and SHS
+   produces 160 bits.
+
+
+
+
+
+
+Eastlake, Crocker & Schiller                                   [Page 16]
+
+RFC 1750        Randomness Recommendations for Security    December 1994
+
+
+   Although the message digest functions are designed for variable
+   amounts of input, DES and other encryption functions can also be used
+   to combine any number of inputs.  If 64 bits of output is adequate,
+   the inputs can be packed into a 64 bit data quantity and successive
+   56 bit keys, padding with zeros if needed, which are then used to
+   successively encrypt using DES in Electronic Codebook Mode [DES
+   MODES].  If more than 64 bits of output are needed, use more complex
+   mixing.  For example, if inputs are packed into three quantities, A,
+   B, and C, use DES to encrypt A with B as a key and then with C as a
+   key to produce the 1st part of the output, then encrypt B with C and
+   then A for more output and, if necessary, encrypt C with A and then B
+   for yet more output.  Still more output can be produced by reversing
+   the order of the keys given above to stretch things. The same can be
+   done with the hash functions by hashing various subsets of the input
+   data to produce multiple outputs.  But keep in mind that it is
+   impossible to get more bits of "randomness" out than are put in.
+
+   An example of using a strong mixing function would be to reconsider
+   the case of a string of 308 bits each of which is biased 99% towards
+   zero.  The parity technique given in Section 5.2.1 above reduced this
+   to one bit with only a 1/1000 deviance from being equally likely a
+   zero or one.  But, applying the equation for information given in
+   Section 2, this 308 bit sequence has 5 bits of information in it.
+   Thus hashing it with SHS or MD5 and taking the bottom 5 bits of the
+   result would yield 5 unbiased random bits as opposed to the single
+   bit given by calculating the parity of the string.
+
+6.1.3 Diffie-Hellman as a Mixing Function
+
+   Diffie-Hellman exponential key exchange is a technique that yields a
+   shared secret between two parties that can be made computationally
+   infeasible for a third party to determine even if they can observe
+   all the messages between the two communicating parties.  This shared
+   secret is a mixture of initial quantities generated by each of them
+   [D-H].  If these initial quantities are random, then the shared
+   secret contains the combined randomness of them both, assuming they
+   are uncorrelated.
+
+6.1.4 Using a Mixing Function to Stretch Random Bits
+
+   While it is not necessary for a mixing function to produce the same
+   or fewer bits than its inputs, mixing bits cannot "stretch" the
+   amount of random unpredictability present in the inputs.  Thus four
+   inputs of 32 bits each where there is 12 bits worth of
+   unpredicatability (such as 4,096 equally probable values) in each
+   input cannot produce more than 48 bits worth of unpredictable output.
+   The output can be expanded to hundreds or thousands of bits by, for
+   example, mixing with successive integers, but the clever adversary's
+
+
+
+Eastlake, Crocker & Schiller                                   [Page 17]
+
+RFC 1750        Randomness Recommendations for Security    December 1994
+
+
+   search space is still 2^48 possibilities.  Furthermore, mixing to
+   fewer bits than are input will tend to strengthen the randomness of
+   the output the way using Exclusive Or to produce one bit from two did
+   above.
+
+   The last table in Section 6.1.1 shows that mixing a random bit with a
+   constant bit with Exclusive Or will produce a random bit.  While this
+   is true, it does not provide a way to "stretch" one random bit into
+   more than one.  If, for example, a random bit is mixed with a 0 and
+   then with a 1, this produces a two bit sequence but it will always be
+   either 01 or 10.  Since there are only two possible values, there is
+   still only the one bit of original randomness.
+
+6.1.5 Other Factors in Choosing a Mixing Function
+
+   For local use, DES has the advantages that it has been widely tested
+   for flaws, is widely documented, and is widely implemented with
+   hardware and software implementations available all over the world
+   including source code available by anonymous FTP.  The SHS and MD*
+   family are younger algorithms which have been less tested but there
+   is no particular reason to believe they are flawed.  Both MD5 and SHS
+   were derived from the earlier MD4 algorithm.  They all have source
+   code available by anonymous FTP [SHS, MD2, MD4, MD5].
+
+   DES and SHS have been vouched for the the US National Security Agency
+   (NSA) on the basis of criteria that primarily remain secret.  While
+   this is the cause of much speculation and doubt, investigation of DES
+   over the years has indicated that NSA involvement in modifications to
+   its design, which originated with IBM, was primarily to strengthen
+   it.  No concealed or special weakness has been found in DES.  It is
+   almost certain that the NSA modification to MD4 to produce the SHS
+   similarly strengthened the algorithm, possibly against threats not
+   yet known in the public cryptographic community.
+
+   DES, SHS, MD4, and MD5 are royalty free for all purposes.  MD2 has
+   been freely licensed only for non-profit use in connection with
+   Privacy Enhanced Mail [PEM].  Between the MD* algorithms, some people
+   believe that, as with "Goldilocks and the Three Bears", MD2 is strong
+   but too slow, MD4 is fast but too weak, and MD5 is just right.
+
+   Another advantage of the MD* or similar hashing algorithms over
+   encryption algorithms is that they are not subject to the same
+   regulations imposed by the US Government prohibiting the unlicensed
+   export or import of encryption/decryption software and hardware.  The
+   same should be true of DES rigged to produce an irreversible hash
+   code but most DES packages are oriented to reversible encryption.
+
+
+
+
+
+Eastlake, Crocker & Schiller                                   [Page 18]
+
+RFC 1750        Randomness Recommendations for Security    December 1994
+
+
+6.2 Non-Hardware Sources of Randomness
+
+   The best source of input for mixing would be a hardware randomness
+   such as disk drive timing affected by air turbulence, audio input
+   with thermal noise, or radioactive decay.  However, if that is not
+   available there are other possibilities.  These include system
+   clocks, system or input/output buffers, user/system/hardware/network
+   serial numbers and/or addresses and timing, and user input.
+   Unfortunately, any of these sources can produce limited or
+   predicatable values under some circumstances.
+
+   Some of the sources listed above would be quite strong on multi-user
+   systems where, in essence, each user of the system is a source of
+   randomness.  However, on a small single user system, such as a
+   typical IBM PC or Apple Macintosh, it might be possible for an
+   adversary to assemble a similar configuration.  This could give the
+   adversary inputs to the mixing process that were sufficiently
+   correlated to those used originally as to make exhaustive search
+   practical.
+
+   The use of multiple random inputs with a strong mixing function is
+   recommended and can overcome weakness in any particular input.  For
+   example, the timing and content of requested "random" user keystrokes
+   can yield hundreds of random bits but conservative assumptions need
+   to be made.  For example, assuming a few bits of randomness if the
+   inter-keystroke interval is unique in the sequence up to that point
+   and a similar assumption if the key hit is unique but assuming that
+   no bits of randomness are present in the initial key value or if the
+   timing or key value duplicate previous values.  The results of mixing
+   these timings and characters typed could be further combined with
+   clock values and other inputs.
+
+   This strategy may make practical portable code to produce good random
+   numbers for security even if some of the inputs are very weak on some
+   of the target systems.  However, it may still fail against a high
+   grade attack on small single user systems, especially if the
+   adversary has ever been able to observe the generation process in the
+   past.  A hardware based random source is still preferable.
+
+6.3 Cryptographically Strong Sequences
+
+   In cases where a series of random quantities must be generated, an
+   adversary may learn some values in the sequence.  In general, they
+   should not be able to predict other values from the ones that they
+   know.
+
+
+
+
+
+
+Eastlake, Crocker & Schiller                                   [Page 19]
+
+RFC 1750        Randomness Recommendations for Security    December 1994
+
+
+   The correct technique is to start with a strong random seed, take
+   cryptographically strong steps from that seed [CRYPTO2, CRYPTO3], and
+   do not reveal the complete state of the generator in the sequence
+   elements.  If each value in the sequence can be calculated in a fixed
+   way from the previous value, then when any value is compromised, all
+   future values can be determined.  This would be the case, for
+   example, if each value were a constant function of the previously
+   used values, even if the function were a very strong, non-invertible
+   message digest function.
+
+   It should be noted that if your technique for generating a sequence
+   of key values is fast enough, it can trivially be used as the basis
+   for a confidentiality system.  If two parties use the same sequence
+   generating technique and start with the same seed material, they will
+   generate identical sequences.  These could, for example, be xor'ed at
+   one end with data being send, encrypting it, and xor'ed with this
+   data as received, decrypting it due to the reversible properties of
+   the xor operation.
+
+6.3.1 Traditional Strong Sequences
+
+   A traditional way to achieve a strong sequence has been to have the
+   values be produced by hashing the quantities produced by
+   concatenating the seed with successive integers or the like and then
+   mask the values obtained so as to limit the amount of generator state
+   available to the adversary.
+
+   It may also be possible to use an "encryption" algorithm with a
+   random key and seed value to encrypt and feedback some or all of the
+   output encrypted value into the value to be encrypted for the next
+   iteration.  Appropriate feedback techniques will usually be
+   recommended with the encryption algorithm.  An example is shown below
+   where shifting and masking are used to combine the cypher output
+   feedback.  This type of feedback is recommended by the US Government
+   in connection with DES [DES MODES].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake, Crocker & Schiller                                   [Page 20]
+
+RFC 1750        Randomness Recommendations for Security    December 1994
+
+
+      +---------------+
+      |       V       |
+      |  |     n      |
+      +--+------------+
+            |      |           +---------+
+            |      +---------> |         |      +-----+
+         +--+                  | Encrypt | <--- | Key |
+         |           +-------- |         |      +-----+
+         |           |         +---------+
+         V           V
+      +------------+--+
+      |      V     |  |
+      |       n+1     |
+      +---------------+
+
+   Note that if a shift of one is used, this is the same as the shift
+   register technique described in Section 3 above but with the all
+   important difference that the feedback is determined by a complex
+   non-linear function of all bits rather than a simple linear or
+   polynomial combination of output from a few bit position taps.
+
+   It has been shown by Donald W. Davies that this sort of shifted
+   partial output feedback significantly weakens an algorithm compared
+   will feeding all of the output bits back as input.  In particular,
+   for DES, repeated encrypting a full 64 bit quantity will give an
+   expected repeat in about 2^63 iterations.  Feeding back anything less
+   than 64 (and more than 0) bits will give an expected repeat in
+   between 2**31 and 2**32 iterations!
+
+   To predict values of a sequence from others when the sequence was
+   generated by these techniques is equivalent to breaking the
+   cryptosystem or inverting the "non-invertible" hashing involved with
+   only partial information available.  The less information revealed
+   each iteration, the harder it will be for an adversary to predict the
+   sequence.  Thus it is best to use only one bit from each value.  It
+   has been shown that in some cases this makes it impossible to break a
+   system even when the cryptographic system is invertible and can be
+   broken if all of each generated value was revealed.
+
+6.3.2 The Blum Blum Shub Sequence Generator
+
+   Currently the generator which has the strongest public proof of
+   strength is called the Blum Blum Shub generator after its inventors
+   [BBS].  It is also very simple and is based on quadratic residues.
+   It's only disadvantage is that is is computationally intensive
+   compared with the traditional techniques give in 6.3.1 above.  This
+   is not a serious draw back if it is used for moderately infrequent
+   purposes, such as generating session keys.
+
+
+
+Eastlake, Crocker & Schiller                                   [Page 21]
+
+RFC 1750        Randomness Recommendations for Security    December 1994
+
+
+   Simply choose two large prime numbers, say p and q, which both have
+   the property that you get a remainder of 3 if you divide them by 4.
+   Let n = p * q.  Then you choose a random number x relatively prime to
+   n.  The initial seed for the generator and the method for calculating
+   subsequent values are then
+
+                   2
+        s    =  ( x  )(Mod n)
+         0
+
+                   2
+        s    = ( s   )(Mod n)
+         i+1      i
+
+   You must be careful to use only a few bits from the bottom of each s.
+   It is always safe to use only the lowest order bit.  If you use no
+   more than the
+
+                  log  ( log  ( s  ) )
+                     2      2    i
+
+   low order bits, then predicting any additional bits from a sequence
+   generated in this manner is provable as hard as factoring n.  As long
+   as the initial x is secret, you can even make n public if you want.
+
+   An intersting characteristic of this generator is that you can
+   directly calculate any of the s values.  In particular
+
+                     i
+               ( ( 2  )(Mod (( p - 1 ) * ( q - 1 )) ) )
+      s  = ( s                                          )(Mod n)
+       i      0
+
+   This means that in applications where many keys are generated in this
+   fashion, it is not necessary to save them all.  Each key can be
+   effectively indexed and recovered from that small index and the
+   initial s and n.
+
+7. Key Generation Standards
+
+   Several public standards are now in place for the generation of keys.
+   Two of these are described below.  Both use DES but any equally
+   strong or stronger mixing function could be substituted.
+
+
+
+
+
+
+
+
+Eastlake, Crocker & Schiller                                   [Page 22]
+
+RFC 1750        Randomness Recommendations for Security    December 1994
+
+
+7.1 US DoD Recommendations for Password Generation
+
+   The United States Department of Defense has specific recommendations
+   for password generation [DoD].  They suggest using the US Data
+   Encryption Standard [DES] in Output Feedback Mode [DES MODES] as
+   follows:
+
+        use an initialization vector determined from
+             the system clock,
+             system ID,
+             user ID, and
+             date and time;
+        use a key determined from
+             system interrupt registers,
+             system status registers, and
+             system counters; and,
+        as plain text, use an external randomly generated 64 bit
+        quantity such as 8 characters typed in by a system
+        administrator.
+
+   The password can then be calculated from the 64 bit "cipher text"
+   generated in 64-bit Output Feedback Mode.  As many bits as are needed
+   can be taken from these 64 bits and expanded into a pronounceable
+   word, phrase, or other format if a human being needs to remember the
+   password.
+
+7.2 X9.17 Key Generation
+
+   The American National Standards Institute has specified a method for
+   generating a sequence of keys as follows:
+
+        s  is the initial 64 bit seed
+         0
+
+        g  is the sequence of generated 64 bit key quantities
+         n
+
+        k is a random key reserved for generating this key sequence
+
+        t is the time at which a key is generated to as fine a resolution
+            as is available (up to 64 bits).
+
+        DES ( K, Q ) is the DES encryption of quantity Q with key K
+
+
+
+
+
+
+
+
+Eastlake, Crocker & Schiller                                   [Page 23]
+
+RFC 1750        Randomness Recommendations for Security    December 1994
+
+
+        g    = DES ( k, DES ( k, t ) .xor. s  )
+         n                                  n
+
+        s    = DES ( k, DES ( k, t ) .xor. g  )
+         n+1                                n
+
+   If g sub n is to be used as a DES key, then every eighth bit should
+   be adjusted for parity for that use but the entire 64 bit unmodified
+   g should be used in calculating the next s.
+
+8. Examples of Randomness Required
+
+   Below are two examples showing rough calculations of needed
+   randomness for security.  The first is for moderate security
+   passwords while the second assumes a need for a very high security
+   cryptographic key.
+
+8.1  Password Generation
+
+   Assume that user passwords change once a year and it is desired that
+   the probability that an adversary could guess the password for a
+   particular account be less than one in a thousand.  Further assume
+   that sending a password to the system is the only way to try a
+   password.  Then the crucial question is how often an adversary can
+   try possibilities.  Assume that delays have been introduced into a
+   system so that, at most, an adversary can make one password try every
+   six seconds.  That's 600 per hour or about 15,000 per day or about
+   5,000,000 tries in a year.  Assuming any sort of monitoring, it is
+   unlikely someone could actually try continuously for a year.  In
+   fact, even if log files are only checked monthly, 500,000 tries is
+   more plausible before the attack is noticed and steps taken to change
+   passwords and make it harder to try more passwords.
+
+   To have a one in a thousand chance of guessing the password in
+   500,000 tries implies a universe of at least 500,000,000 passwords or
+   about 2^29.  Thus 29 bits of randomness are needed. This can probably
+   be achieved using the US DoD recommended inputs for password
+   generation as it has 8 inputs which probably average over 5 bits of
+   randomness each (see section 7.1).  Using a list of 1000 words, the
+   password could be expressed as a three word phrase (1,000,000,000
+   possibilities) or, using case insensitive letters and digits, six
+   would suffice ((26+10)^6 = 2,176,782,336 possibilities).
+
+   For a higher security password, the number of bits required goes up.
+   To decrease the probability by 1,000 requires increasing the universe
+   of passwords by the same factor which adds about 10 bits.  Thus to
+   have only a one in a million chance of a password being guessed under
+   the above scenario would require 39 bits of randomness and a password
+
+
+
+Eastlake, Crocker & Schiller                                   [Page 24]
+
+RFC 1750        Randomness Recommendations for Security    December 1994
+
+
+   that was a four word phrase from a 1000 word list or eight
+   letters/digits.  To go to a one in 10^9 chance, 49 bits of randomness
+   are needed implying a five word phrase or ten letter/digit password.
+
+   In a real system, of course, there are also other factors.  For
+   example, the larger and harder to remember passwords are, the more
+   likely users are to write them down resulting in an additional risk
+   of compromise.
+
+8.2 A Very High Security Cryptographic Key
+
+   Assume that a very high security key is needed for symmetric
+   encryption / decryption between two parties.  Assume an adversary can
+   observe communications and knows the algorithm being used.  Within
+   the field of random possibilities, the adversary can try key values
+   in hopes of finding the one in use.  Assume further that brute force
+   trial of keys is the best the adversary can do.
+
+8.2.1 Effort per Key Trial
+
+   How much effort will it take to try each key?  For very high security
+   applications it is best to assume a low value of effort.  Even if it
+   would clearly take tens of thousands of computer cycles or more to
+   try a single key, there may be some pattern that enables huge blocks
+   of key values to be tested with much less effort per key.  Thus it is
+   probably best to assume no more than a couple hundred cycles per key.
+   (There is no clear lower bound on this as computers operate in
+   parallel on a number of bits and a poor encryption algorithm could
+   allow many keys or even groups of keys to be tested in parallel.
+   However, we need to assume some value and can hope that a reasonably
+   strong algorithm has been chosen for our hypothetical high security
+   task.)
+
+   If the adversary can command a highly parallel processor or a large
+   network of work stations, 2*10^10 cycles per second is probably a
+   minimum assumption for availability today.  Looking forward just a
+   couple years, there should be at least an order of magnitude
+   improvement.  Thus assuming 10^9 keys could be checked per second or
+   3.6*10^11 per hour or 6*10^13 per week or 2.4*10^14 per month is
+   reasonable.  This implies a need for a minimum of 51 bits of
+   randomness in keys to be sure they cannot be found in a month.  Even
+   then it is possible that, a few years from now, a highly determined
+   and resourceful adversary could break the key in 2 weeks (on average
+   they need try only half the keys).
+
+
+
+
+
+
+
+Eastlake, Crocker & Schiller                                   [Page 25]
+
+RFC 1750        Randomness Recommendations for Security    December 1994
+
+
+8.2.2 Meet in the Middle Attacks
+
+   If chosen or known plain text and the resulting encrypted text are
+   available, a "meet in the middle" attack is possible if the structure
+   of the encryption algorithm allows it.  (In a known plain text
+   attack, the adversary knows all or part of the messages being
+   encrypted, possibly some standard header or trailer fields.  In a
+   chosen plain text attack, the adversary can force some chosen plain
+   text to be encrypted, possibly by "leaking" an exciting text that
+   would then be sent by the adversary over an encrypted channel.)
+
+   An oversimplified explanation of the meet in the middle attack is as
+   follows: the adversary can half-encrypt the known or chosen plain
+   text with all possible first half-keys, sort the output, then half-
+   decrypt the encoded text with all the second half-keys.  If a match
+   is found, the full key can be assembled from the halves and used to
+   decrypt other parts of the message or other messages.  At its best,
+   this type of attack can halve the exponent of the work required by
+   the adversary while adding a large but roughly constant factor of
+   effort.  To be assured of safety against this, a doubling of the
+   amount of randomness in the key to a minimum of 102 bits is required.
+
+   The meet in the middle attack assumes that the cryptographic
+   algorithm can be decomposed in this way but we can not rule that out
+   without a deep knowledge of the algorithm.  Even if a basic algorithm
+   is not subject to a meet in the middle attack, an attempt to produce
+   a stronger algorithm by applying the basic algorithm twice (or two
+   different algorithms sequentially) with different keys may gain less
+   added security than would be expected.  Such a composite algorithm
+   would be subject to a meet in the middle attack.
+
+   Enormous resources may be required to mount a meet in the middle
+   attack but they are probably within the range of the national
+   security services of a major nation.  Essentially all nations spy on
+   other nations government traffic and several nations are believed to
+   spy on commercial traffic for economic advantage.
+
+8.2.3 Other Considerations
+
+   Since we have not even considered the possibilities of special
+   purpose code breaking hardware or just how much of a safety margin we
+   want beyond our assumptions above, probably a good minimum for a very
+   high security cryptographic key is 128 bits of randomness which
+   implies a minimum key length of 128 bits.  If the two parties agree
+   on a key by Diffie-Hellman exchange [D-H], then in principle only
+   half of this randomness would have to be supplied by each party.
+   However, there is probably some correlation between their random
+   inputs so it is probably best to assume that each party needs to
+
+
+
+Eastlake, Crocker & Schiller                                   [Page 26]
+
+RFC 1750        Randomness Recommendations for Security    December 1994
+
+
+   provide at least 96 bits worth of randomness for very high security
+   if Diffie-Hellman is used.
+
+   This amount of randomness is beyond the limit of that in the inputs
+   recommended by the US DoD for password generation and could require
+   user typing timing, hardware random number generation, or other
+   sources.
+
+   It should be noted that key length calculations such at those above
+   are controversial and depend on various assumptions about the
+   cryptographic algorithms in use.  In some cases, a professional with
+   a deep knowledge of code breaking techniques and of the strength of
+   the algorithm in use could be satisfied with less than half of the
+   key size derived above.
+
+9. Conclusion
+
+   Generation of unguessable "random" secret quantities for security use
+   is an essential but difficult task.
+
+   We have shown that hardware techniques to produce such randomness
+   would be relatively simple.  In particular, the volume and quality
+   would not need to be high and existing computer hardware, such as
+   disk drives, can be used.  Computational techniques are available to
+   process low quality random quantities from multiple sources or a
+   larger quantity of such low quality input from one source and produce
+   a smaller quantity of higher quality, less predictable key material.
+   In the absence of hardware sources of randomness, a variety of user
+   and software sources can frequently be used instead with care;
+   however, most modern systems already have hardware, such as disk
+   drives or audio input, that could be used to produce high quality
+   randomness.
+
+   Once a sufficient quantity of high quality seed key material (a few
+   hundred bits) is available, strong computational techniques are
+   available to produce cryptographically strong sequences of
+   unpredicatable quantities from this seed material.
+
+10. Security Considerations
+
+   The entirety of this document concerns techniques and recommendations
+   for generating unguessable "random" quantities for use as passwords,
+   cryptographic keys, and similar security uses.
+
+
+
+
+
+
+
+
+Eastlake, Crocker & Schiller                                   [Page 27]
+
+RFC 1750        Randomness Recommendations for Security    December 1994
+
+
+References
+
+   [ASYMMETRIC] - Secure Communications and Asymmetric Cryptosystems,
+   edited by Gustavus J. Simmons, AAAS Selected Symposium 69, Westview
+   Press, Inc.
+
+   [BBS] - A Simple Unpredictable Pseudo-Random Number Generator, SIAM
+   Journal on Computing, v. 15, n. 2, 1986, L. Blum, M. Blum, & M. Shub.
+
+   [BRILLINGER] - Time Series: Data Analysis and Theory, Holden-Day,
+   1981, David Brillinger.
+
+   [CRC] - C.R.C. Standard Mathematical Tables, Chemical Rubber
+   Publishing Company.
+
+   [CRYPTO1] - Cryptography: A Primer, A Wiley-Interscience Publication,
+   John Wiley & Sons, 1981, Alan G. Konheim.
+
+   [CRYPTO2] - Cryptography:  A New Dimension in Computer Data Security,
+   A Wiley-Interscience Publication, John Wiley & Sons, 1982, Carl H.
+   Meyer & Stephen M. Matyas.
+
+   [CRYPTO3] - Applied Cryptography: Protocols, Algorithms, and Source
+   Code in C, John Wiley & Sons, 1994, Bruce Schneier.
+
+   [DAVIS] - Cryptographic Randomness from Air Turbulence in Disk
+   Drives, Advances in Cryptology - Crypto '94, Springer-Verlag Lecture
+   Notes in Computer Science #839, 1984, Don Davis, Ross Ihaka, and
+   Philip Fenstermacher.
+
+   [DES] -  Data Encryption Standard, United States of America,
+   Department of Commerce, National Institute of Standards and
+   Technology, Federal Information Processing Standard (FIPS) 46-1.
+   - Data Encryption Algorithm, American National Standards Institute,
+   ANSI X3.92-1981.
+   (See also FIPS 112, Password Usage, which includes FORTRAN code for
+   performing DES.)
+
+   [DES MODES] - DES Modes of Operation, United States of America,
+   Department of Commerce, National Institute of Standards and
+   Technology, Federal Information Processing Standard (FIPS) 81.
+   - Data Encryption Algorithm - Modes of Operation, American National
+   Standards Institute, ANSI X3.106-1983.
+
+   [D-H] - New Directions in Cryptography, IEEE Transactions on
+   Information Technology, November, 1976, Whitfield Diffie and Martin
+   E. Hellman.
+
+
+
+
+Eastlake, Crocker & Schiller                                   [Page 28]
+
+RFC 1750        Randomness Recommendations for Security    December 1994
+
+
+   [DoD] - Password Management Guideline, United States of America,
+   Department of Defense, Computer Security Center, CSC-STD-002-85.
+   (See also FIPS 112, Password Usage, which incorporates CSC-STD-002-85
+   as one of its appendices.)
+
+   [GIFFORD] - Natural Random Number, MIT/LCS/TM-371, September 1988,
+   David K. Gifford
+
+   [KNUTH] - The Art of Computer Programming, Volume 2: Seminumerical
+   Algorithms, Chapter 3: Random Numbers. Addison Wesley Publishing
+   Company, Second Edition 1982, Donald E. Knuth.
+
+   [KRAWCZYK] - How to Predict Congruential Generators, Journal of
+   Algorithms, V. 13, N. 4, December 1992, H. Krawczyk
+
+   [MD2] - The MD2 Message-Digest Algorithm, RFC1319, April 1992, B.
+   Kaliski
+   [MD4] - The MD4 Message-Digest Algorithm, RFC1320, April 1992, R.
+   Rivest
+   [MD5] - The MD5 Message-Digest Algorithm, RFC1321, April 1992, R.
+   Rivest
+
+   [PEM] - RFCs 1421 through 1424:
+   - RFC 1424, Privacy Enhancement for Internet Electronic Mail: Part
+   IV: Key Certification and Related Services, 02/10/1993, B. Kaliski
+   - RFC 1423, Privacy Enhancement for Internet Electronic Mail: Part
+   III: Algorithms, Modes, and Identifiers, 02/10/1993, D. Balenson
+   - RFC 1422, Privacy Enhancement for Internet Electronic Mail: Part
+   II: Certificate-Based Key Management, 02/10/1993, S. Kent
+   - RFC 1421, Privacy Enhancement for Internet Electronic Mail: Part I:
+   Message Encryption and Authentication Procedures, 02/10/1993, J. Linn
+
+   [SHANNON] - The Mathematical Theory of Communication, University of
+   Illinois Press, 1963, Claude E. Shannon.  (originally from:  Bell
+   System Technical Journal, July and October 1948)
+
+   [SHIFT1] - Shift Register Sequences, Aegean Park Press, Revised
+   Edition 1982, Solomon W. Golomb.
+
+   [SHIFT2] - Cryptanalysis of Shift-Register Generated Stream Cypher
+   Systems, Aegean Park Press, 1984, Wayne G. Barker.
+
+   [SHS] - Secure Hash Standard, United States of American, National
+   Institute of Science and Technology, Federal Information Processing
+   Standard (FIPS) 180, April 1993.
+
+   [STERN] - Secret Linear Congruential Generators are not
+   Cryptograhically Secure, Proceedings of IEEE STOC, 1987, J. Stern.
+
+
+
+Eastlake, Crocker & Schiller                                   [Page 29]
+
+RFC 1750        Randomness Recommendations for Security    December 1994
+
+
+   [VON NEUMANN] - Various techniques used in connection with random
+   digits, von Neumann's Collected Works, Vol. 5, Pergamon Press, 1963,
+   J. von Neumann.
+
+Authors' Addresses
+
+   Donald E. Eastlake 3rd
+   Digital Equipment Corporation
+   550 King Street, LKG2-1/BB3
+   Littleton, MA 01460
+
+   Phone:   +1 508 486 6577(w)  +1 508 287 4877(h)
+   EMail:   dee@lkg.dec.com
+
+
+   Stephen D. Crocker
+   CyberCash Inc.
+   2086 Hunters Crest Way
+   Vienna, VA 22181
+
+   Phone:   +1 703-620-1222(w)  +1 703-391-2651 (fax)
+   EMail:   crocker@cybercash.com
+
+
+   Jeffrey I. Schiller
+   Massachusetts Institute of Technology
+   77 Massachusetts Avenue
+   Cambridge, MA 02139
+
+   Phone:   +1 617 253 0161(w)
+   EMail:   jis@mit.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake, Crocker & Schiller                                   [Page 30]
+
diff --git a/doc/rfc/rfc1876.txt b/doc/rfc/rfc1876.txt
new file mode 100644
index 0000000..a289cff
--- /dev/null
+++ b/doc/rfc/rfc1876.txt
@@ -0,0 +1,1011 @@
+
+
+
+
+
+
+Network Working Group                                           C. Davis
+Request for Comments: 1876                             Kapor Enterprises
+Updates: 1034, 1035                                             P. Vixie
+Category: Experimental                                 Vixie Enterprises
+                                                              T. Goodwin
+                                                            FORE Systems
+                                                            I. Dickinson
+                                                   University of Warwick
+                                                            January 1996
+
+
+ A Means for Expressing Location Information in the Domain Name System
+
+Status of this Memo
+
+   This memo defines an Experimental Protocol for the Internet
+   community.  This memo does not specify an Internet standard of any
+   kind.  Discussion and suggestions for improvement are requested.
+   Distribution of this memo is unlimited.
+
+1. Abstract
+
+   This memo defines a new DNS RR type for experimental purposes.  This
+   RFC describes a mechanism to allow the DNS to carry location
+   information about hosts, networks, and subnets.  Such information for
+   a small subset of hosts is currently contained in the flat-file UUCP
+   maps.  However, just as the DNS replaced the use of HOSTS.TXT to
+   carry host and network address information, it is possible to replace
+   the UUCP maps as carriers of location information.
+
+   This RFC defines the format of a new Resource Record (RR) for the
+   Domain Name System (DNS), and reserves a corresponding DNS type
+   mnemonic (LOC) and numerical code (29).
+
+   This RFC assumes that the reader is familiar with the DNS [RFC 1034,
+   RFC 1035].  The data shown in our examples is for pedagogical use and
+   does not necessarily reflect the real Internet.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Davis, et al                  Experimental                      [Page 1]
+
+RFC 1876            Location Information in the DNS         January 1996
+
+
+2. RDATA Format
+
+       MSB                                           LSB
+       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+      0|        VERSION        |         SIZE          |
+       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+      2|       HORIZ PRE       |       VERT PRE        |
+       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+      4|                   LATITUDE                    |
+       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+      6|                   LATITUDE                    |
+       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+      8|                   LONGITUDE                   |
+       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+     10|                   LONGITUDE                   |
+       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+     12|                   ALTITUDE                    |
+       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+     14|                   ALTITUDE                    |
+       +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+   (octet)
+
+where:
+
+VERSION      Version number of the representation.  This must be zero.
+             Implementations are required to check this field and make
+             no assumptions about the format of unrecognized versions.
+
+SIZE         The diameter of a sphere enclosing the described entity, in
+             centimeters, expressed as a pair of four-bit unsigned
+             integers, each ranging from zero to nine, with the most
+             significant four bits representing the base and the second
+             number representing the power of ten by which to multiply
+             the base.  This allows sizes from 0e0 (<1cm) to 9e9
+             (90,000km) to be expressed.  This representation was chosen
+             such that the hexadecimal representation can be read by
+             eye; 0x15 = 1e5.  Four-bit values greater than 9 are
+             undefined, as are values with a base of zero and a non-zero
+             exponent.
+
+             Since 20000000m (represented by the value 0x29) is greater
+             than the equatorial diameter of the WGS 84 ellipsoid
+             (12756274m), it is therefore suitable for use as a
+             "worldwide" size.
+
+HORIZ PRE    The horizontal precision of the data, in centimeters,
+             expressed using the same representation as SIZE.  This is
+             the diameter of the horizontal "circle of error", rather
+
+
+
+Davis, et al                  Experimental                      [Page 2]
+
+RFC 1876            Location Information in the DNS         January 1996
+
+
+             than a "plus or minus" value.  (This was chosen to match
+             the interpretation of SIZE; to get a "plus or minus" value,
+             divide by 2.)
+
+VERT PRE     The vertical precision of the data, in centimeters,
+             expressed using the sane representation as for SIZE.  This
+             is the total potential vertical error, rather than a "plus
+             or minus" value.  (This was chosen to match the
+             interpretation of SIZE; to get a "plus or minus" value,
+             divide by 2.)  Note that if altitude above or below sea
+             level is used as an approximation for altitude relative to
+             the [WGS 84] ellipsoid, the precision value should be
+             adjusted.
+
+LATITUDE     The latitude of the center of the sphere described by the
+             SIZE field, expressed as a 32-bit integer, most significant
+             octet first (network standard byte order), in thousandths
+             of a second of arc.  2^31 represents the equator; numbers
+             above that are north latitude.
+
+LONGITUDE    The longitude of the center of the sphere described by the
+             SIZE field, expressed as a 32-bit integer, most significant
+             octet first (network standard byte order), in thousandths
+             of a second of arc, rounded away from the prime meridian.
+             2^31 represents the prime meridian; numbers above that are
+             east longitude.
+
+ALTITUDE     The altitude of the center of the sphere described by the
+             SIZE field, expressed as a 32-bit integer, most significant
+             octet first (network standard byte order), in centimeters,
+             from a base of 100,000m below the [WGS 84] reference
+             spheroid used by GPS (semimajor axis a=6378137.0,
+             reciprocal flattening rf=298.257223563).  Altitude above
+             (or below) sea level may be used as an approximation of
+             altitude relative to the the [WGS 84] spheroid, though due
+             to the Earth's surface not being a perfect spheroid, there
+             will be differences.  (For example, the geoid (which sea
+             level approximates) for the continental US ranges from 10
+             meters to 50 meters below the [WGS 84] spheroid.
+             Adjustments to ALTITUDE and/or VERT PRE will be necessary
+             in most cases.  The Defense Mapping Agency publishes geoid
+             height values relative to the [WGS 84] ellipsoid.
+
+
+
+
+
+
+
+
+
+Davis, et al                  Experimental                      [Page 3]
+
+RFC 1876            Location Information in the DNS         January 1996
+
+
+3. Master File Format
+
+   The LOC record is expressed in a master file in the following format:
+
+   <owner> <TTL> <class> LOC ( d1 [m1 [s1]] {"N"|"S"} d2 [m2 [s2]]
+                               {"E"|"W"} alt["m"] [siz["m"] [hp["m"]
+                               [vp["m"]]]] )
+
+   (The parentheses are used for multi-line data as specified in [RFC
+   1035] section 5.1.)
+
+   where:
+
+       d1:     [0 .. 90]            (degrees latitude)
+       d2:     [0 .. 180]           (degrees longitude)
+       m1, m2: [0 .. 59]            (minutes latitude/longitude)
+       s1, s2: [0 .. 59.999]        (seconds latitude/longitude)
+       alt:    [-100000.00 .. 42849672.95] BY .01 (altitude in meters)
+       siz, hp, vp: [0 .. 90000000.00] (size/precision in meters)
+
+   If omitted, minutes and seconds default to zero, size defaults to 1m,
+   horizontal precision defaults to 10000m, and vertical precision
+   defaults to 10m.  These defaults are chosen to represent typical
+   ZIP/postal code area sizes, since it is often easy to find
+   approximate geographical location by ZIP/postal code.
+
+4. Example Data
+
+;;;
+;;; note that these data would not all appear in one zone file
+;;;
+
+;; network LOC RR derived from ZIP data.  note use of precision defaults
+cambridge-net.kei.com.        LOC   42 21 54 N 71 06 18 W -24m 30m
+
+;; higher-precision host LOC RR.  note use of vertical precision default
+loiosh.kei.com.               LOC   42 21 43.952 N 71 5 6.344 W
+                                    -24m 1m 200m
+
+pipex.net.                    LOC   52 14 05 N 00 08 50 E 10m
+
+curtin.edu.au.                LOC   32 7 19 S 116 2 25 E 10m
+
+rwy04L.logan-airport.boston.  LOC   42 21 28.764 N 71 00 51.617 W
+                                    -44m 2000m
+
+
+
+
+
+
+Davis, et al                  Experimental                      [Page 4]
+
+RFC 1876            Location Information in the DNS         January 1996
+
+
+5. Application use of the LOC RR
+
+5.1 Suggested Uses
+
+   Some uses for the LOC RR have already been suggested, including the
+   USENET backbone flow maps, a "visual traceroute" application showing
+   the geographical path of an IP packet, and network management
+   applications that could use LOC RRs to generate a map of hosts and
+   routers being managed.
+
+5.2 Search Algorithms
+
+   This section specifies how to use the DNS to translate domain names
+   and/or IP addresses into location information.
+
+   If an application wishes to have a "fallback" behavior, displaying a
+   less precise or larger area when a host does not have an associated
+   LOC RR, it MAY support use of the algorithm in section 5.2.3, as
+   noted in sections 5.2.1 and 5.2.2.  If fallback is desired, this
+   behaviour is the RECOMMENDED default, but in some cases it may need
+   to be modified based on the specific requirements of the application
+   involved.
+
+   This search algorithm is designed to allow network administrators to
+   specify the location of a network or subnet without requiring LOC RR
+   data for each individual host.  For example, a computer lab with 24
+   workstations, all of which are on the same subnet and in basically
+   the same location, would only need a LOC RR for the subnet.
+   (However, if the file server's location has been more precisely
+   measured, a separate LOC RR for it can be placed in the DNS.)
+
+5.2.1 Searching by Name
+
+   If the application is beginning with a name, rather than an IP
+   address (as the USENET backbone flow maps do), it MUST check for a
+   LOC RR associated with that name.  (CNAME records should be followed
+   as for any other RR type.)
+
+   If there is no LOC RR for that name, all A records (if any)
+   associated with the name MAY be checked for network (or subnet) LOC
+   RRs using the "Searching by Network or Subnet" algorithm (5.2.3).  If
+   multiple A records exist and have associated network or subnet LOC
+   RRs, the application may choose to use any, some, or all of the LOC
+   RRs found, possibly in combination.  It is suggested that multi-homed
+   hosts have LOC RRs for their name in the DNS to avoid any ambiguity
+   in these cases.
+
+
+
+
+
+Davis, et al                  Experimental                      [Page 5]
+
+RFC 1876            Location Information in the DNS         January 1996
+
+
+   Note that domain names that do not have associated A records must
+   have a LOC RR associated with their name in order for location
+   information to be accessible.
+
+5.2.2 Searching by Address
+
+   If the application is beginning with an IP address (as a "visual
+   traceroute" application might be) it MUST first map the address to a
+   name using the IN-ADDR.ARPA namespace (see [RFC 1034], section
+   5.2.1), then check for a LOC RR associated with that name.
+
+   If there is no LOC RR for the name, the address MAY be checked for
+   network (or subnet) LOC RRs using the "Searching by Network or
+   Subnet" algorithm (5.2.3).
+
+5.2.3 Searching by Network or Subnet
+
+   Even if a host's name does not have any associated LOC RRs, the
+   network(s) or subnet(s) it is on may.  If the application wishes to
+   search for such less specific data, the following algorithm SHOULD be
+   followed to find a network or subnet LOC RR associated with the IP
+   address.  This algorithm is adapted slightly from that specified in
+   [RFC 1101], sections 4.3 and 4.4.
+
+   Since subnet LOC RRs are (if present) more specific than network LOC
+   RRs, it is best to use them if available.  In order to do so, we
+   build a stack of network and subnet names found while performing the
+   [RFC 1101] search, then work our way down the stack until a LOC RR is
+   found.
+
+   1. create a host-zero address using the network portion of the IP
+      address (one, two, or three bytes for class A, B, or C networks,
+      respectively).  For example, for the host 128.9.2.17, on the class
+      B network 128.9, this would result in the address "128.9.0.0".
+
+   2. Reverse the octets, suffix IN-ADDR.ARPA, and query for PTR and A
+      records.  Retrieve:
+
+               0.0.9.128.IN-ADDR.ARPA.  PTR    isi-net.isi.edu.
+                                        A      255.255.255.0
+
+      Push the name "isi-net.isi.edu" onto the stack of names to be
+      searched for LOC RRs later.
+
+
+
+
+
+
+
+
+Davis, et al                  Experimental                      [Page 6]
+
+RFC 1876            Location Information in the DNS         January 1996
+
+
+   3. Since an A RR was found, repeat using mask from RR
+      (255.255.255.0), constructing a query for 0.2.9.128.IN-ADDR.ARPA.
+      Retrieve:
+
+               0.2.9.128.IN-ADDR.ARPA.  PTR    div2-subnet.isi.edu.
+                                        A      255.255.255.240
+
+      Push the name "div2-subnet.isi.edu" onto the stack of names to be
+      searched for LOC RRs later.
+
+   4. Since another A RR was found, repeat using mask 255.255.255.240
+      (x'FFFFFFF0'), constructing a query for 16.2.9.128.IN-ADDR.ARPA.
+      Retrieve:
+
+               16.2.9.128.IN-ADDR.ARPA. PTR    inc-subsubnet.isi.edu.
+
+      Push the name "inc-subsubnet.isi.edu" onto the stack of names to
+      be searched for LOC RRs later.
+
+   5. Since no A RR is present at 16.2.9.128.IN-ADDR.ARPA., there are no
+      more subnet levels to search.  We now pop the top name from the
+      stack and check for an associated LOC RR.  Repeat until a LOC RR
+      is found.
+
+      In this case, assume that inc-subsubnet.isi.edu does not have an
+      associated LOC RR, but that div2-subnet.isi.edu does.  We will
+      then use div2-subnet.isi.edu's LOC RR as an approximation of this
+      host's location.  (Note that even if isi-net.isi.edu has a LOC RR,
+      it will not be used if a subnet also has a LOC RR.)
+
+5.3 Applicability to non-IN Classes and non-IP Addresses
+
+   The LOC record is defined for all RR classes, and may be used with
+   non-IN classes such as HS and CH.  The semantics of such use are not
+   defined by this memo.
+
+   The search algorithm in section 5.2.3 may be adapted to other
+   addressing schemes by extending [RFC 1101]'s encoding of network
+   names to cover those schemes.  Such extensions are not defined by
+   this memo.
+
+
+
+
+
+
+
+
+
+
+
+Davis, et al                  Experimental                      [Page 7]
+
+RFC 1876            Location Information in the DNS         January 1996
+
+
+6. References
+
+   [RFC 1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
+              STD 13, RFC 1034, USC/Information Sciences Institute,
+              November 1987.
+
+   [RFC 1035] Mockapetris, P., "Domain Names - Implementation and
+              Specification", STD 13, RFC 1035, USC/Information Sciences
+              Institute, November 1987.
+
+   [RFC 1101] Mockapetris, P., "DNS Encoding of Network Names and Other
+              Types", RFC 1101, USC/Information Sciences Institute,
+              April 1989.
+
+   [WGS 84] United States Department of Defense; DoD WGS-1984 - Its
+            Definition and Relationships with Local Geodetic Systems;
+            Washington, D.C.; 1985; Report AD-A188 815 DMA; 6127; 7-R-
+            138-R; CV, KV;
+
+7. Security Considerations
+
+   High-precision LOC RR information could be used to plan a penetration
+   of physical security, leading to potential denial-of-machine attacks.
+   To avoid any appearance of suggesting this method to potential
+   attackers, we declined the opportunity to name this RR "ICBM".
+
+8. Authors' Addresses
+
+   The authors as a group can be reached as <loc@pipex.net>.
+
+   Christopher Davis
+   Kapor Enterprises, Inc.
+   238 Main Street, Suite 400
+   Cambridge, MA 02142
+
+   Phone: +1 617 576 4532
+   EMail: ckd@kei.com
+
+
+   Paul Vixie
+   Vixie Enterprises
+   Star Route Box 159A
+   Woodside, CA 94062
+
+   Phone: +1 415 747 0204
+   EMail: paul@vix.com
+
+
+
+
+
+Davis, et al                  Experimental                      [Page 8]
+
+RFC 1876            Location Information in the DNS         January 1996
+
+
+   Tim Goodwin
+   Public IP Exchange Ltd (PIPEX)
+   216 The Science Park
+   Cambridge CB4 4WA
+   UK
+
+   Phone: +44 1223 250250
+   EMail: tim@pipex.net
+
+
+   Ian Dickinson
+   FORE Systems
+   2475 The Crescent
+   Solihull Parkway
+   Birmingham Business Park
+   B37 7YE
+   UK
+
+   Phone: +44 121 717 4444
+   EMail: idickins@fore.co.uk
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Davis, et al                  Experimental                      [Page 9]
+
+RFC 1876            Location Information in the DNS         January 1996
+
+
+Appendix A: Sample Conversion Routines
+
+/*
+ * routines to convert between on-the-wire RR format and zone file
+ * format.  Does not contain conversion to/from decimal degrees;
+ * divide or multiply by 60*60*1000 for that.
+ */
+
+static unsigned int poweroften[10] = {1, 10, 100, 1000, 10000, 100000,
+                                 1000000,10000000,100000000,1000000000};
+
+/* takes an XeY precision/size value, returns a string representation.*/
+static const char *
+precsize_ntoa(prec)
+        u_int8_t prec;
+{
+        static char retbuf[sizeof("90000000.00")];
+        unsigned long val;
+        int mantissa, exponent;
+
+        mantissa = (int)((prec >> 4) & 0x0f) % 10;
+        exponent = (int)((prec >> 0) & 0x0f) % 10;
+
+        val = mantissa * poweroften[exponent];
+
+        (void) sprintf(retbuf,"%d.%.2d", val/100, val%100);
+        return (retbuf);
+}
+
+/* converts ascii size/precision X * 10**Y(cm) to 0xXY. moves pointer.*/
+static u_int8_t
+precsize_aton(strptr)
+        char **strptr;
+{
+        unsigned int mval = 0, cmval = 0;
+        u_int8_t retval = 0;
+        register char *cp;
+        register int exponent;
+        register int mantissa;
+
+        cp = *strptr;
+
+        while (isdigit(*cp))
+                mval = mval * 10 + (*cp++ - '0');
+
+        if (*cp == '.') {               /* centimeters */
+                cp++;
+                if (isdigit(*cp)) {
+
+
+
+Davis, et al                  Experimental                     [Page 10]
+
+RFC 1876            Location Information in the DNS         January 1996
+
+
+                        cmval = (*cp++ - '0') * 10;
+                        if (isdigit(*cp)) {
+                                cmval += (*cp++ - '0');
+                        }
+                }
+        }
+        cmval = (mval * 100) + cmval;
+
+        for (exponent = 0; exponent < 9; exponent++)
+                if (cmval < poweroften[exponent+1])
+                        break;
+
+        mantissa = cmval / poweroften[exponent];
+        if (mantissa > 9)
+                mantissa = 9;
+
+        retval = (mantissa << 4) | exponent;
+
+        *strptr = cp;
+
+        return (retval);
+}
+
+/* converts ascii lat/lon to unsigned encoded 32-bit number.
+ *  moves pointer. */
+static u_int32_t
+latlon2ul(latlonstrptr,which)
+        char **latlonstrptr;
+        int *which;
+{
+        register char *cp;
+        u_int32_t retval;
+        int deg = 0, min = 0, secs = 0, secsfrac = 0;
+
+        cp = *latlonstrptr;
+
+        while (isdigit(*cp))
+                deg = deg * 10 + (*cp++ - '0');
+
+        while (isspace(*cp))
+                cp++;
+
+        if (!(isdigit(*cp)))
+                goto fndhemi;
+
+        while (isdigit(*cp))
+                min = min * 10 + (*cp++ - '0');
+
+
+
+
+Davis, et al                  Experimental                     [Page 11]
+
+RFC 1876            Location Information in the DNS         January 1996
+
+
+        while (isspace(*cp))
+                cp++;
+
+        if (!(isdigit(*cp)))
+                goto fndhemi;
+
+        while (isdigit(*cp))
+                secs = secs * 10 + (*cp++ - '0');
+
+        if (*cp == '.') {               /* decimal seconds */
+                cp++;
+                if (isdigit(*cp)) {
+                        secsfrac = (*cp++ - '0') * 100;
+                        if (isdigit(*cp)) {
+                                secsfrac += (*cp++ - '0') * 10;
+                                if (isdigit(*cp)) {
+                                        secsfrac += (*cp++ - '0');
+                                }
+                        }
+                }
+        }
+
+        while (!isspace(*cp))   /* if any trailing garbage */
+                cp++;
+
+        while (isspace(*cp))
+                cp++;
+
+ fndhemi:
+        switch (*cp) {
+        case 'N': case 'n':
+        case 'E': case 'e':
+                retval = ((unsigned)1<<31)
+                        + (((((deg * 60) + min) * 60) + secs) * 1000)
+                        + secsfrac;
+                break;
+        case 'S': case 's':
+        case 'W': case 'w':
+                retval = ((unsigned)1<<31)
+                        - (((((deg * 60) + min) * 60) + secs) * 1000)
+                        - secsfrac;
+                break;
+        default:
+                retval = 0;     /* invalid value -- indicates error */
+                break;
+        }
+
+        switch (*cp) {
+
+
+
+Davis, et al                  Experimental                     [Page 12]
+
+RFC 1876            Location Information in the DNS         January 1996
+
+
+        case 'N': case 'n':
+        case 'S': case 's':
+                *which = 1;     /* latitude */
+                break;
+        case 'E': case 'e':
+        case 'W': case 'w':
+                *which = 2;     /* longitude */
+                break;
+        default:
+                *which = 0;     /* error */
+                break;
+        }
+
+        cp++;                   /* skip the hemisphere */
+
+        while (!isspace(*cp))   /* if any trailing garbage */
+                cp++;
+
+        while (isspace(*cp))    /* move to next field */
+                cp++;
+
+        *latlonstrptr = cp;
+
+        return (retval);
+}
+
+/* converts a zone file representation in a string to an RDATA
+ * on-the-wire representation. */
+u_int32_t
+loc_aton(ascii, binary)
+        const char *ascii;
+        u_char *binary;
+{
+        const char *cp, *maxcp;
+        u_char *bcp;
+
+        u_int32_t latit = 0, longit = 0, alt = 0;
+        u_int32_t lltemp1 = 0, lltemp2 = 0;
+        int altmeters = 0, altfrac = 0, altsign = 1;
+        u_int8_t hp = 0x16;    /* default = 1e6 cm = 10000.00m = 10km */
+        u_int8_t vp = 0x13;    /* default = 1e3 cm = 10.00m */
+        u_int8_t siz = 0x12;   /* default = 1e2 cm = 1.00m */
+        int which1 = 0, which2 = 0;
+
+        cp = ascii;
+        maxcp = cp + strlen(ascii);
+
+        lltemp1 = latlon2ul(&cp, &which1);
+
+
+
+Davis, et al                  Experimental                     [Page 13]
+
+RFC 1876            Location Information in the DNS         January 1996
+
+
+        lltemp2 = latlon2ul(&cp, &which2);
+
+        switch (which1 + which2) {
+        case 3:                 /* 1 + 2, the only valid combination */
+                if ((which1 == 1) && (which2 == 2)) { /* normal case */
+                        latit = lltemp1;
+                        longit = lltemp2;
+                } else if ((which1 == 2) && (which2 == 1)) {/*reversed*/
+                        longit = lltemp1;
+                        latit = lltemp2;
+                } else {        /* some kind of brokenness */
+                        return 0;
+                }
+                break;
+        default:                /* we didn't get one of each */
+                return 0;
+        }
+
+        /* altitude */
+        if (*cp == '-') {
+                altsign = -1;
+                cp++;
+        }
+
+        if (*cp == '+')
+                cp++;
+
+        while (isdigit(*cp))
+                altmeters = altmeters * 10 + (*cp++ - '0');
+
+        if (*cp == '.') {               /* decimal meters */
+                cp++;
+                if (isdigit(*cp)) {
+                        altfrac = (*cp++ - '0') * 10;
+                        if (isdigit(*cp)) {
+                                altfrac += (*cp++ - '0');
+                        }
+                }
+        }
+
+        alt = (10000000 + (altsign * (altmeters * 100 + altfrac)));
+
+        while (!isspace(*cp) && (cp < maxcp))
+                                           /* if trailing garbage or m */
+                cp++;
+
+        while (isspace(*cp) && (cp < maxcp))
+                cp++;
+
+
+
+Davis, et al                  Experimental                     [Page 14]
+
+RFC 1876            Location Information in the DNS         January 1996
+
+
+        if (cp >= maxcp)
+                goto defaults;
+
+        siz = precsize_aton(&cp);
+
+        while (!isspace(*cp) && (cp < maxcp))/*if trailing garbage or m*/
+                cp++;
+
+        while (isspace(*cp) && (cp < maxcp))
+                cp++;
+
+        if (cp >= maxcp)
+                goto defaults;
+
+        hp = precsize_aton(&cp);
+
+        while (!isspace(*cp) && (cp < maxcp))/*if trailing garbage or m*/
+                cp++;
+
+        while (isspace(*cp) && (cp < maxcp))
+                cp++;
+
+        if (cp >= maxcp)
+                goto defaults;
+
+        vp = precsize_aton(&cp);
+
+ defaults:
+
+        bcp = binary;
+        *bcp++ = (u_int8_t) 0;  /* version byte */
+        *bcp++ = siz;
+        *bcp++ = hp;
+        *bcp++ = vp;
+        PUTLONG(latit,bcp);
+        PUTLONG(longit,bcp);
+        PUTLONG(alt,bcp);
+
+        return (16);            /* size of RR in octets */
+}
+
+/* takes an on-the-wire LOC RR and prints it in zone file
+ * (human readable) format. */
+char *
+loc_ntoa(binary,ascii)
+        const u_char *binary;
+        char *ascii;
+{
+
+
+
+Davis, et al                  Experimental                     [Page 15]
+
+RFC 1876            Location Information in the DNS         January 1996
+
+
+        static char tmpbuf[255*3];
+
+        register char *cp;
+        register const u_char *rcp;
+
+        int latdeg, latmin, latsec, latsecfrac;
+        int longdeg, longmin, longsec, longsecfrac;
+        char northsouth, eastwest;
+        int altmeters, altfrac, altsign;
+
+        const int referencealt = 100000 * 100;
+
+        int32_t latval, longval, altval;
+        u_int32_t templ;
+        u_int8_t sizeval, hpval, vpval, versionval;
+
+        char *sizestr, *hpstr, *vpstr;
+
+        rcp = binary;
+        if (ascii)
+                cp = ascii;
+        else {
+                cp = tmpbuf;
+        }
+
+        versionval = *rcp++;
+
+        if (versionval) {
+                sprintf(cp,"; error: unknown LOC RR version");
+                return (cp);
+        }
+
+        sizeval = *rcp++;
+
+        hpval = *rcp++;
+        vpval = *rcp++;
+
+        GETLONG(templ,rcp);
+        latval = (templ - ((unsigned)1<<31));
+
+        GETLONG(templ,rcp);
+        longval = (templ - ((unsigned)1<<31));
+
+        GETLONG(templ,rcp);
+        if (templ < referencealt) { /* below WGS 84 spheroid */
+                altval = referencealt - templ;
+                altsign = -1;
+        } else {
+
+
+
+Davis, et al                  Experimental                     [Page 16]
+
+RFC 1876            Location Information in the DNS         January 1996
+
+
+                altval = templ - referencealt;
+                altsign = 1;
+        }
+
+        if (latval < 0) {
+                northsouth = 'S';
+                latval = -latval;
+        }
+        else
+                northsouth = 'N';
+
+        latsecfrac = latval % 1000;
+        latval = latval / 1000;
+        latsec = latval % 60;
+        latval = latval / 60;
+        latmin = latval % 60;
+        latval = latval / 60;
+        latdeg = latval;
+
+        if (longval < 0) {
+                eastwest = 'W';
+                longval = -longval;
+        }
+        else
+                eastwest = 'E';
+
+        longsecfrac = longval % 1000;
+        longval = longval / 1000;
+        longsec = longval % 60;
+        longval = longval / 60;
+        longmin = longval % 60;
+        longval = longval / 60;
+        longdeg = longval;
+
+        altfrac = altval % 100;
+        altmeters = (altval / 100) * altsign;
+
+        sizestr = savestr(precsize_ntoa(sizeval));
+        hpstr = savestr(precsize_ntoa(hpval));
+        vpstr = savestr(precsize_ntoa(vpval));
+
+        sprintf(cp,
+                "%d %.2d %.2d.%.3d %c %d %.2d %.2d.%.3d %c %d.%.2dm
+                %sm %sm %sm",
+                latdeg, latmin, latsec, latsecfrac, northsouth,
+                longdeg, longmin, longsec, longsecfrac, eastwest,
+                altmeters, altfrac, sizestr, hpstr, vpstr);
+
+
+
+
+Davis, et al                  Experimental                     [Page 17]
+
+RFC 1876            Location Information in the DNS         January 1996
+
+
+        free(sizestr);
+        free(hpstr);
+        free(vpstr);
+
+        return (cp);
+}
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Davis, et al                  Experimental                     [Page 18]
+
diff --git a/doc/rfc/rfc1886.txt b/doc/rfc/rfc1886.txt
new file mode 100644
index 0000000..9874fdd
--- /dev/null
+++ b/doc/rfc/rfc1886.txt
@@ -0,0 +1,268 @@
+
+
+
+
+
+
+Network Working Group                                         S. Thomson
+Request for Comments: 1886                                      Bellcore
+Category: Standards Track                                     C. Huitema
+                                                                   INRIA
+                                                           December 1995
+
+
+                DNS Extensions to support IP version 6
+
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+
+Abstract
+
+   This document defines the changes that need to be made to the Domain
+   Name System to support hosts running IP version 6 (IPv6).  The
+   changes include a new resource record type to store an IPv6 address,
+   a new domain to support lookups based on an IPv6 address, and updated
+   definitions of existing query types that return Internet addresses as
+   part of additional section processing.  The extensions are designed
+   to be compatible with existing applications and, in particular, DNS
+   implementations themselves.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Thompson & Huitema          Standards Track                    [Page 1]
+
+RFC 1886                  IPv6 DNS Extensions              December 1995
+
+
+1. INTRODUCTION
+
+   Current support for the storage of Internet addresses in the Domain
+   Name System (DNS)[1,2] cannot easily be extended to support IPv6
+   addresses[3] since applications assume that address queries return
+   32-bit IPv4 addresses only.
+
+   To support the storage of IPv6 addresses we define the following
+   extensions:
+
+      o A new resource record type is defined to map a domain name to an
+        IPv6 address.
+
+      o A new domain is defined to support lookups based on address.
+
+      o Existing queries that perform additional section processing to
+        locate IPv4 addresses are redefined to perform additional
+        section processing on both IPv4 and IPv6 addresses.
+
+   The changes are designed to be compatible with existing software. The
+   existing support for IPv4 addresses is retained. Transition issues
+   related to the co-existence of both IPv4 and IPv6 addresses in DNS
+   are discussed in [4].
+
+
+2. NEW RESOURCE RECORD DEFINITION AND DOMAIN
+
+   A new record type is defined to store a host's IPv6 address. A host
+   that has more than one IPv6 address must have more than one such
+   record.
+
+
+2.1 AAAA record type
+
+   The AAAA resource record type is a new record specific to the
+   Internet class that stores a single IPv6 address.
+
+   The value of the type is 28 (decimal).
+
+
+2.2 AAAA data format
+
+   A 128 bit IPv6 address is encoded in the data portion of an AAAA
+   resource record in network byte order (high-order byte first).
+
+
+
+
+Thompson & Huitema          Standards Track                    [Page 2]
+
+RFC 1886                  IPv6 DNS Extensions              December 1995
+
+
+2.3 AAAA query
+
+   An AAAA query for a specified domain name in the Internet class
+   returns all associated AAAA resource records in the answer section of
+   a response.
+
+   A type AAAA query does not perform additional section processing.
+
+
+2.4 Textual format of AAAA records
+
+   The textual representation of the data portion of the AAAA resource
+   record used in a master database file is the textual representation
+   of a IPv6 address as defined in [3].
+
+
+2.5 IP6.INT Domain
+
+   A special domain is defined to look up a record given an address. The
+   intent of this domain is to provide a way of mapping an IPv6 address
+   to a host name, although it may be used for other purposes as well.
+   The domain is rooted at IP6.INT.
+
+   An IPv6 address is represented as a name in the IP6.INT domain by a
+   sequence of nibbles separated by dots with the suffix ".IP6.INT". The
+   sequence of nibbles is encoded in reverse order, i.e. the low-order
+   nibble is encoded first, followed by the next low-order nibble and so
+   on. Each nibble is represented by a hexadecimal digit. For example,
+   the inverse lookup domain name corresponding to the address
+
+       4321:0:1:2:3:4:567:89ab
+
+   would be
+
+b.a.9.8.7.6.5.0.4.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.0.0.0.0.1.2.3.4.IP6.INT.
+
+
+
+3. MODIFICATIONS TO EXISTING QUERY TYPES
+
+   All existing query types that perform type A additional section
+   processing, i.e. name server (NS), mail exchange (MX) and mailbox
+   (MB) query types, must be redefined to perform both type A and type
+   AAAA additional section processing. These new definitions mean that a
+   name server must add any relevant IPv4 addresses and any relevant
+
+
+
+Thompson & Huitema          Standards Track                    [Page 3]
+
+RFC 1886                  IPv6 DNS Extensions              December 1995
+
+
+   IPv6 addresses available locally to the additional section of a
+   response when processing any one of the above queries.
+
+
+4. SECURITY CONSIDERATIONS
+
+   Security issues are not discussed in this memo.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Thompson & Huitema          Standards Track                    [Page 4]
+
+RFC 1886                  IPv6 DNS Extensions              December 1995
+
+
+5. REFERENCES
+
+
+   [1]  Mockapetris, P., "Domain Names - Concepts and Facilities", STD
+        13, RFC 1034, USC/Information Sciences Institute, November 1987.
+
+   [2]  Mockapetris, P., "Domain Names - Implementation and Specifica-
+        tion", STD 13, RFC 1035, USC/Information Sciences Institute,
+        November 1987.
+
+   [3]  Hinden, R., and S. Deering, Editors, "IP Version 6 Addressing
+        Architecture", RFC 1884, Ipsilon Networks, Xerox PARC, December
+        1995.
+
+
+   [4]  Gilligan, R., and E. Nordmark, "Transition Mechanisms for IPv6
+        Hosts and Routers", Work in Progress.
+
+
+Authors' Addresses
+
+   Susan Thomson
+   Bellcore
+   MRE 2P343
+   445 South Street
+   Morristown, NJ 07960
+   U.S.A.
+
+   Phone: +1 201-829-4514
+   EMail: set@thumper.bellcore.com
+
+
+   Christian Huitema
+   INRIA, Sophia-Antipolis
+   2004 Route des Lucioles
+   BP 109
+   F-06561 Valbonne Cedex
+   France
+
+   Phone: +33 93 65 77 15
+   EMail: Christian.Huitema@MIRSA.INRIA.FR
+
+
+
+
+
+
+
+Thompson & Huitema          Standards Track                    [Page 5]
+
diff --git a/doc/rfc/rfc1982.txt b/doc/rfc/rfc1982.txt
new file mode 100644
index 0000000..5a34bc4
--- /dev/null
+++ b/doc/rfc/rfc1982.txt
@@ -0,0 +1,394 @@
+
+
+
+
+
+
+Network Working Group                                             R. Elz
+Request for Comments: 1982                       University of Melbourne
+Updates: 1034, 1035                                              R. Bush
+Category: Standards Track                                    RGnet, Inc.
+                                                             August 1996
+
+
+                        Serial Number Arithmetic
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Abstract
+
+   This memo defines serial number arithmetic, as used in the Domain
+   Name System.  The DNS has long relied upon serial number arithmetic,
+   a concept which has never really been defined, certainly not in an
+   IETF document, though which has been widely understood.  This memo
+   supplies the missing definition.  It is intended to update RFC1034
+   and RFC1035.
+
+1. Introduction
+
+   The serial number field of the SOA resource record is defined in
+   RFC1035 as
+
+   SERIAL   The unsigned 32 bit version number of the original copy of
+            the zone.  Zone transfers preserve this value.  This value
+            wraps and should be compared using sequence space
+            arithmetic.
+
+   RFC1034 uses the same terminology when defining secondary server zone
+   consistency procedures.
+
+   Unfortunately the term "sequence space arithmetic" is not defined in
+   either RFC1034 or RFC1035, nor do any of their references provide
+   further information.
+
+   This phrase seems to have been intending to specify arithmetic as
+   used in TCP sequence numbers [RFC793], and defined in [IEN-74].
+
+   Unfortunately, the arithmetic defined in [IEN-74] is not adequate for
+   the purposes of the DNS, as no general comparison operator is
+
+
+
+Elz & Bush                  Standards Track                     [Page 1]
+
+RFC 1982                Serial Number Arithmetic             August 1996
+
+
+   defined.
+
+   To avoid further problems with this simple field, this document
+   defines the field and the operations available upon it.  This
+   definition is intended merely to clarify the intent of RFC1034 and
+   RFC1035, and is believed to generally agree with current
+   implementations.  However, older, superseded, implementations are
+   known to have treated the serial number as a simple unsigned integer,
+   with no attempt to implement any kind of "sequence space arithmetic",
+   however that may have been interpreted, and further, ignoring the
+   requirement that the value wraps.  Nothing can be done with these
+   implementations, beyond extermination.
+
+2. Serial Number Arithmetic
+
+   Serial numbers are formed from non-negative integers from a finite
+   subset of the range of all integer values.  The lowest integer in
+   every subset used for this purpose is zero, the maximum is always one
+   less than a power of two.
+
+   When considered as serial numbers however no value has any particular
+   significance, there is no minimum or maximum serial number, every
+   value has a successor and predecessor.
+
+   To define a serial number to be used in this way, the size of the
+   serial number space must be given.  This value, called "SERIAL_BITS",
+   gives the power of two which results in one larger than the largest
+   integer corresponding to a serial number value.  This also specifies
+   the number of bits required to hold every possible value of a serial
+   number of the defined type.  The operations permitted upon serial
+   numbers are defined in the following section.
+
+3. Operations upon the serial number
+
+   Only two operations are defined upon serial numbers, addition of a
+   positive integer of limited range, and comparison with another serial
+   number.
+
+3.1. Addition
+
+   Serial numbers may be incremented by the addition of a positive
+   integer n, where n is taken from the range of integers
+   [0 .. (2^(SERIAL_BITS - 1) - 1)].  For a sequence number s, the
+   result of such an addition, s', is defined as
+
+                   s' = (s + n) modulo (2 ^ SERIAL_BITS)
+
+
+
+
+
+Elz & Bush                  Standards Track                     [Page 2]
+
+RFC 1982                Serial Number Arithmetic             August 1996
+
+
+   where the addition and modulus operations here act upon values that
+   are non-negative values of unbounded size in the usual ways of
+   integer arithmetic.
+
+   Addition of a value outside the range
+   [0 .. (2^(SERIAL_BITS - 1) - 1)] is undefined.
+
+3.2. Comparison
+
+   Any two serial numbers, s1 and s2, may be compared.  The definition
+   of the result of this comparison is as follows.
+
+   For the purposes of this definition, consider two integers, i1 and
+   i2, from the unbounded set of non-negative integers, such that i1 and
+   s1 have the same numeric value, as do i2 and s2.  Arithmetic and
+   comparisons applied to i1 and i2 use ordinary unbounded integer
+   arithmetic.
+
+   Then, s1 is said to be equal to s2 if and only if i1 is equal to i2,
+   in all other cases, s1 is not equal to s2.
+
+   s1 is said to be less than s2 if, and only if, s1 is not equal to s2,
+   and
+
+        (i1 < i2 and i2 - i1 < 2^(SERIAL_BITS - 1)) or
+        (i1 > i2 and i1 - i2 > 2^(SERIAL_BITS - 1))
+
+   s1 is said to be greater than s2 if, and only if, s1 is not equal to
+   s2, and
+
+        (i1 < i2 and i2 - i1 > 2^(SERIAL_BITS - 1)) or
+        (i1 > i2 and i1 - i2 < 2^(SERIAL_BITS - 1))
+
+   Note that there are some pairs of values s1 and s2 for which s1 is
+   not equal to s2, but for which s1 is neither greater than, nor less
+   than, s2.  An attempt to use these ordering operators on such pairs
+   of values produces an undefined result.
+
+   The reason for this is that those pairs of values are such that any
+   simple definition that were to define s1 to be less than s2 where
+   (s1, s2) is such a pair, would also usually cause s2 to be less than
+   s1, when the pair is (s2, s1).  This would mean that the particular
+   order selected for a test could cause the result to differ, leading
+   to unpredictable implementations.
+
+   While it would be possible to define the test in such a way that the
+   inequality would not have this surprising property, while being
+   defined for all pairs of values, such a definition would be
+
+
+
+Elz & Bush                  Standards Track                     [Page 3]
+
+RFC 1982                Serial Number Arithmetic             August 1996
+
+
+   unnecessarily burdensome to implement, and difficult to understand,
+   and would still allow cases where
+
+        s1 < s2 and (s1 + 1) > (s2 + 1)
+
+   which is just as non-intuitive.
+
+   Thus the problem case is left undefined, implementations are free to
+   return either result, or to flag an error, and users must take care
+   not to depend on any particular outcome.  Usually this will mean
+   avoiding allowing those particular pairs of numbers to co-exist.
+
+   The relationships greater than or equal to, and less than or equal
+   to, follow in the natural way from the above definitions.
+
+4. Corollaries
+
+   These definitions give rise to some results of note.
+
+4.1. Corollary 1
+
+   For any sequence number s and any integer n such that addition of n
+   to s is well defined, (s + n) >= s.  Further (s + n) == s only when
+   n == 0, in all other defined cases, (s + n) > s.
+
+4.2. Corollary 2
+
+   If s' is the result of adding the non-zero integer n to the sequence
+   number s, and m is another integer from the range defined as able to
+   be added to a sequence number, and s" is the result of adding m to
+   s', then it is undefined whether s" is greater than, or less than s,
+   though it is known that s" is not equal to s.
+
+4.3. Corollary 3
+
+   If s" from the previous corollary is further incremented, then there
+   is no longer any known relationship between the result and s.
+
+4.4. Corollary 4
+
+   If in corollary 2 the value (n + m) is such that addition of the sum
+   to sequence number s would produce a defined result, then corollary 1
+   applies, and s" is known to be greater than s.
+
+
+
+
+
+
+
+
+Elz & Bush                  Standards Track                     [Page 4]
+
+RFC 1982                Serial Number Arithmetic             August 1996
+
+
+5. Examples
+
+5.1. A trivial example
+
+   The simplest meaningful serial number space has SERIAL_BITS == 2.  In
+   this space, the integers that make up the serial number space are 0,
+   1, 2, and 3.  That is, 3 == 2^SERIAL_BITS - 1.
+
+   In this space, the largest integer that it is meaningful to add to a
+   sequence number is 2^(SERIAL_BITS - 1) - 1, or 1.
+
+   Then, as defined 0+1 == 1, 1+1 == 2, 2+1 == 3, and 3+1 == 0.
+   Further, 1 > 0, 2 > 1, 3 > 2, and 0 > 3.  It is undefined whether
+   2 > 0 or 0 > 2, and whether 1 > 3 or 3 > 1.
+
+5.2. A slightly larger example
+
+   Consider the case where SERIAL_BITS == 8.  In this space the integers
+   that make up the serial number space are 0, 1, 2, ... 254, 255.
+   255 == 2^SERIAL_BITS - 1.
+
+   In this space, the largest integer that it is meaningful to add to a
+   sequence number is 2^(SERIAL_BITS - 1) - 1, or 127.
+
+   Addition is as expected in this space, for example: 255+1 == 0,
+   100+100 == 200, and 200+100 == 44.
+
+   Comparison is more interesting, 1 > 0, 44 > 0, 100 > 0, 100 > 44,
+   200 > 100, 255 > 200, 0 > 255, 100 > 255, 0 > 200, and 44 > 200.
+
+   Note that 100+100 > 100, but that (100+100)+100 < 100.  Incrementing
+   a serial number can cause it to become "smaller".  Of course,
+   incrementing by a smaller number will allow many more increments to
+   be made before this occurs.  However this is always something to be
+   aware of, it can cause surprising errors, or be useful as it is the
+   only defined way to actually cause a serial number to decrease.
+
+   The pairs of values 0 and 128, 1 and 129, 2 and 130, etc, to 127 and
+   255 are not equal, but in each pair, neither number is defined as
+   being greater than, or less than, the other.
+
+   It could be defined (arbitrarily) that 128 > 0, 129 > 1,
+   130 > 2, ..., 255 > 127, by changing the comparison operator
+   definitions, as mentioned above.  However note that that would cause
+   255 > 127, while (255 + 1) < (127 + 1), as 0 < 128.  Such a
+   definition, apart from being arbitrary, would also be more costly to
+   implement.
+
+
+
+
+Elz & Bush                  Standards Track                     [Page 5]
+
+RFC 1982                Serial Number Arithmetic             August 1996
+
+
+6. Citation
+
+   As this defined arithmetic may be useful for purposes other than for
+   the DNS serial number, it may be referenced as Serial Number
+   Arithmetic from RFC1982.  Any such reference shall be taken as
+   implying that the rules of sections 2 to 5 of this document apply to
+   the stated values.
+
+7. The DNS SOA serial number
+
+   The serial number in the DNS SOA Resource Record is a Serial Number
+   as defined above, with SERIAL_BITS being 32.  That is, the serial
+   number is a non negative integer with values taken from the range
+   [0 .. 4294967295].  That is, a 32 bit unsigned integer.
+
+   The maximum defined increment is 2147483647 (2^31 - 1).
+
+   Care should be taken that the serial number not be incremented, in
+   one or more steps, by more than this maximum within the period given
+   by the value of SOA.expire.  Doing so may leave some secondary
+   servers with out of date copies of the zone, but with a serial number
+   "greater" than that of the primary server.  Of course, special
+   circumstances may require this rule be set aside, for example, when
+   the serial number needs to be set lower for some reason.  If this
+   must be done, then take special care to verify that ALL servers have
+   correctly succeeded in following the primary server's serial number
+   changes, at each step.
+
+   Note that each, and every, increment to the serial number must be
+   treated as the start of a new sequence of increments for this
+   purpose, as well as being the continuation of all previous sequences
+   started within the period specified by SOA.expire.
+
+   Caution should also be exercised before causing the serial number to
+   be set to the value zero.  While this value is not in any way special
+   in serial number arithmetic, or to the DNS SOA serial number, many
+   DNS implementations have incorrectly treated zero as a special case,
+   with special properties, and unusual behaviour may be expected if
+   zero is used as a DNS SOA serial number.
+
+
+
+
+
+
+
+
+
+
+
+
+Elz & Bush                  Standards Track                     [Page 6]
+
+RFC 1982                Serial Number Arithmetic             August 1996
+
+
+8. Document Updates
+
+   RFC1034 and RFC1035 are to be treated as if the references to
+   "sequence space arithmetic" therein are replaced by references to
+   serial number arithmetic, as defined in this document.
+
+9. Security Considerations
+
+   This document does not consider security.
+
+   It is not believed that anything in this document adds to any
+   security issues that may exist with the DNS, nor does it do anything
+   to lessen them.
+
+References
+
+   [RFC1034]   Domain Names - Concepts and Facilities,
+               P. Mockapetris, STD 13, ISI, November 1987.
+
+   [RFC1035]   Domain Names - Implementation and Specification
+               P. Mockapetris, STD 13, ISI, November 1987
+
+   [RFC793]    Transmission Control protocol
+               Information Sciences Institute, STD 7, USC, September 1981
+
+   [IEN-74]    Sequence Number Arithmetic
+               William W. Plummer, BB&N Inc, September 1978
+
+Acknowledgements
+
+   Thanks to Rob Austein for suggesting clarification of the undefined
+   comparison operators, and to Michael Patton for attempting to locate
+   another reference for this procedure.  Thanks also to members of the
+   IETF DNSIND working group of 1995-6, in particular, Paul Mockapetris.
+
+Authors' Addresses
+
+   Robert Elz                     Randy Bush
+   Computer Science               RGnet, Inc.
+   University of Melbourne        10361 NE Sasquatch Lane
+   Parkville, Vic,  3052          Bainbridge Island, Washington,  98110
+   Australia.                     United States.
+
+   EMail: kre@munnari.OZ.AU       EMail: randy@psg.com
+
+
+
+
+
+
+
+Elz & Bush                  Standards Track                     [Page 7]
diff --git a/doc/rfc/rfc1995.txt b/doc/rfc/rfc1995.txt
new file mode 100644
index 0000000..b50bdc6
--- /dev/null
+++ b/doc/rfc/rfc1995.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Network Working Group                                            M. Ohta
+Request for Comments: 1995                 Tokyo Institute of Technology
+Updates: 1035                                                August 1996
+Category: Standards Track
+
+
+                    Incremental Zone Transfer in DNS
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Abstract
+
+   This document proposes extensions to the DNS protocols to provide an
+   incremental zone transfer (IXFR) mechanism.
+
+1. Introduction
+
+   For rapid propagation of changes to a DNS database [STD13], it is
+   necessary to reduce latency by actively notifying servers of the
+   change.  This is accomplished by the NOTIFY extension of the DNS
+   [NOTIFY].
+
+   The current full zone transfer mechanism (AXFR) is not an efficient
+   means to propagate changes to a small part of a zone, as it transfers
+   the entire zone file.
+
+   Incremental transfer (IXFR) as proposed is a more efficient
+   mechanism, as it transfers only the changed portion(s) of a zone.
+
+   In this document, a secondary name server which requests IXFR is
+   called an IXFR client and a primary or secondary name server which
+   responds to the request is called an IXFR server.
+
+2. Brief Description of the Protocol
+
+   If an IXFR client, which likely has an older version of a zone,
+   thinks it needs new information about the zone (typically through SOA
+   refresh timeout or the NOTIFY mechanism), it sends an IXFR message
+   containing the SOA serial number of its, presumably outdated, copy of
+   the zone.
+
+
+
+
+
+Ohta                        Standards Track                     [Page 1]
+
+RFC 1995            Incremental Zone Transfer in DNS         August 1996
+
+
+   An IXFR server should keep record of the newest version of the zone
+   and the differences between that copy and several older versions.
+   When an IXFR request with an older version number is received, the
+   IXFR server needs to send only the differences required to make that
+   version current.  Alternatively, the server may choose to transfer
+   the entire zone just as in a normal full zone transfer.
+
+   When a zone has been updated, it should be saved in stable storage
+   before the new version is used to respond to IXFR (or AXFR) queries.
+   Otherwise, if the server crashes, data which is no longer available
+   may have been distributed to secondary servers, which can cause
+   persistent database inconsistencies.
+
+   If an IXFR query with the same or newer version number than that of
+   the server is received, it is replied to with a single SOA record of
+   the server's current version, just as in AXFR.
+
+   Transport of a query may be by either UDP or TCP.  If an IXFR query
+   is via UDP, the IXFR server may attempt to reply using UDP if the
+   entire response can be contained in a single DNS packet.  If the UDP
+   reply does not fit, the query is responded to with a single SOA
+   record of the server's current version to inform the client that a
+   TCP query should be initiated.
+
+   Thus, a client should first make an IXFR query using UDP.  If the
+   query type is not recognized by the server, an AXFR (preceded by a
+   UDP SOA query) should be tried, ensuring backward compatibility.  If
+   the query response is a single packet with the entire new zone, or if
+   the server does not have a newer version than the client, everything
+   is done.  Otherwise, a TCP IXFR query should be tried.
+
+   To ensure integrity, servers should use UDP checksums for all UDP
+   responses.  A cautious client which receives a UDP packet with a
+   checksum value of zero should ignore the result and try a TCP IXFR
+   instead.
+
+   The query type value of IXFR assigned by IANA is 251.
+
+3. Query Format
+
+   The IXFR query packet format is the same as that of a normal DNS
+   query, but with the query type being IXFR and the authority section
+   containing the SOA record of client's version of the zone.
+
+
+
+
+
+
+
+
+Ohta                        Standards Track                     [Page 2]
+
+RFC 1995            Incremental Zone Transfer in DNS         August 1996
+
+
+4. Response Format
+
+   If incremental zone transfer is not available, the entire zone is
+   returned.  The first and the last RR of the response is the SOA
+   record of the zone.  I.e. the behavior is the same as an AXFR
+   response except the query type is IXFR.
+
+   If incremental zone transfer is available, one or more difference
+   sequences is returned.  The list of difference sequences is preceded
+   and followed by a copy of the server's current version of the SOA.
+
+   Each difference sequence represents one update to the zone (one SOA
+   serial change) consisting of deleted RRs and added RRs.  The first RR
+   of the deleted RRs is the older SOA RR and the first RR of the added
+   RRs is the newer SOA RR.
+
+   Modification of an RR is performed first by removing the original RR
+   and then adding the modified one.
+
+   The sequences of differential information are ordered oldest first
+   newest last.  Thus, the differential sequences are the history of
+   changes made since the version known by the IXFR client up to the
+   server's current version.
+
+   RRs in the incremental transfer messages may be partial.  That is, if
+   a single RR of multiple RRs of the same RR type changes, only the
+   changed RR is transferred.
+
+   An IXFR client, should only replace an older version with a newer
+   version after all the differences have been successfully processed.
+
+   An incremental response is different from that of a non-incremental
+   response in that it begins with two SOA RRs, the server's current SOA
+   followed by the SOA of the client's version which is about to be
+   replaced.
+
+   5. Purging Strategy
+
+   An IXFR server can not be required to hold all previous versions
+   forever and may delete them anytime. In general, there is a trade-off
+   between the size of storage space and the possibility of using IXFR.
+
+   Information about older versions should be purged if the total length
+   of an IXFR response would be longer than that of an AXFR response.
+   Given that the purpose of IXFR is to reduce AXFR overhead, this
+   strategy is quite reasonable.  The strategy assures that the amount
+   of storage required is at most twice that of the current zone
+   information.
+
+
+
+Ohta                        Standards Track                     [Page 3]
+
+RFC 1995            Incremental Zone Transfer in DNS         August 1996
+
+
+   Information older than the SOA expire period may also be purged.
+
+6. Optional Condensation of Multiple Versions
+
+   An IXFR server may optionally condense multiple difference sequences
+   into a single difference sequence, thus, dropping information on
+   intermediate versions.
+
+   This may be beneficial if a lot of versions, not all of which are
+   useful, are generated. For example, if multiple ftp servers share a
+   single DNS name and the IP address associated with the name is
+   changed once a minute to balance load between the ftp servers, it is
+   not so important to keep track of all the history of changes.
+
+   But, this feature may not be so useful if an IXFR client has access
+   to two IXFR servers: A and B, with inconsistent condensation results.
+   The current version of the IXFR client, received from server A, may
+   be unknown to server B. In such a case, server B can not provide
+   incremental data from the unknown version and a full zone transfer is
+   necessary.
+
+   Condensation is completely optional. Clients can't detect from the
+   response whether the server has condensed the reply or not.
+
+   For interoperability, IXFR servers, including those without the
+   condensation feature, should not flag an error even if it receives a
+   client's IXFR request with a unknown version number and should,
+   instead, attempt to perform a full zone transfer.
+
+7. Example
+
+   Given the following three generations of data with the current serial
+   number of 3,
+
+      JAIN.AD.JP.         IN SOA NS.JAIN.AD.JP. mohta.jain.ad.jp. (
+                                        1 600 600 3600000 604800)
+                          IN NS  NS.JAIN.AD.JP.
+      NS.JAIN.AD.JP.      IN A   133.69.136.1
+      NEZU.JAIN.AD.JP.    IN A   133.69.136.5
+
+   NEZU.JAIN.AD.JP. is removed and JAIN-BB.JAIN.AD.JP. is added.
+
+      jain.ad.jp.         IN SOA ns.jain.ad.jp. mohta.jain.ad.jp. (
+                                        2 600 600 3600000 604800)
+                          IN NS  NS.JAIN.AD.JP.
+      NS.JAIN.AD.JP.      IN A   133.69.136.1
+      JAIN-BB.JAIN.AD.JP. IN A   133.69.136.4
+                          IN A   192.41.197.2
+
+
+
+Ohta                        Standards Track                     [Page 4]
+
+RFC 1995            Incremental Zone Transfer in DNS         August 1996
+
+
+   One of the IP addresses of JAIN-BB.JAIN.AD.JP. is changed.
+
+      JAIN.AD.JP.         IN SOA ns.jain.ad.jp. mohta.jain.ad.jp. (
+                                        3 600 600 3600000 604800)
+                          IN NS  NS.JAIN.AD.JP.
+      NS.JAIN.AD.JP.      IN A   133.69.136.1
+      JAIN-BB.JAIN.AD.JP. IN A   133.69.136.3
+                          IN A   192.41.197.2
+
+   The following IXFR query
+
+                 +---------------------------------------------------+
+      Header     | OPCODE=SQUERY                                     |
+                 +---------------------------------------------------+
+      Question   | QNAME=JAIN.AD.JP., QCLASS=IN, QTYPE=IXFR          |
+                 +---------------------------------------------------+
+      Answer     | <empty>                                           |
+                 +---------------------------------------------------+
+      Authority  | JAIN.AD.JP.         IN SOA serial=1               |
+                 +---------------------------------------------------+
+      Additional | <empty>                                           |
+                 +---------------------------------------------------+
+
+   could be replied to with the following full zone transfer message:
+
+                 +---------------------------------------------------+
+      Header     | OPCODE=SQUERY, RESPONSE                           |
+                 +---------------------------------------------------+
+      Question   | QNAME=JAIN.AD.JP., QCLASS=IN, QTYPE=IXFR          |
+                 +---------------------------------------------------+
+      Answer     | JAIN.AD.JP.         IN SOA serial=3               |
+                 | JAIN.AD.JP.         IN NS  NS.JAIN.AD.JP.         |
+                 | NS.JAIN.AD.JP.      IN A   133.69.136.1           |
+                 | JAIN-BB.JAIN.AD.JP. IN A   133.69.136.3           |
+                 | JAIN-BB.JAIN.AD.JP. IN A   192.41.197.2           |
+                 | JAIN.AD.JP.         IN SOA serial=3               |
+                 +---------------------------------------------------+
+      Authority  | <empty>                                           |
+                 +---------------------------------------------------+
+      Additional | <empty>                                           |
+                 +---------------------------------------------------+
+
+
+
+
+
+
+
+
+
+
+Ohta                        Standards Track                     [Page 5]
+
+RFC 1995            Incremental Zone Transfer in DNS         August 1996
+
+
+   or with the following incremental message:
+
+                 +---------------------------------------------------+
+      Header     | OPCODE=SQUERY, RESPONSE                           |
+                 +---------------------------------------------------+
+      Question   | QNAME=JAIN.AD.JP., QCLASS=IN, QTYPE=IXFR          |
+                 +---------------------------------------------------+
+      Answer     | JAIN.AD.JP.         IN SOA serial=3               |
+                 | JAIN.AD.JP.         IN SOA serial=1               |
+                 | NEZU.JAIN.AD.JP.    IN A   133.69.136.5           |
+                 | JAIN.AD.JP.         IN SOA serial=2               |
+                 | JAIN-BB.JAIN.AD.JP. IN A   133.69.136.4           |
+                 | JAIN-BB.JAIN.AD.JP. IN A   192.41.197.2           |
+                 | JAIN.AD.JP.         IN SOA serial=2               |
+                 | JAIN-BB.JAIN.AD.JP. IN A   133.69.136.4           |
+                 | JAIN.AD.JP.         IN SOA serial=3               |
+                 | JAIN-BB.JAIN.AD.JP. IN A   133.69.136.3           |
+                 | JAIN.AD.JP.         IN SOA serial=3               |
+                 +---------------------------------------------------+
+      Authority  | <empty>                                           |
+                 +---------------------------------------------------+
+      Additional | <empty>                                           |
+                 +---------------------------------------------------+
+
+   or with the following condensed incremental message:
+
+                 +---------------------------------------------------+
+      Header     | OPCODE=SQUERY, RESPONSE                           |
+                 +---------------------------------------------------+
+      Question   | QNAME=JAIN.AD.JP., QCLASS=IN, QTYPE=IXFR          |
+                 +---------------------------------------------------+
+      Answer     | JAIN.AD.JP.         IN SOA serial=3               |
+                 | JAIN.AD.JP.         IN SOA serial=1               |
+                 | NEZU.JAIN.AD.JP.    IN A   133.69.136.5           |
+                 | JAIN.AD.JP.         IN SOA serial=3               |
+                 | JAIN-BB.JAIN.AD.JP. IN A   133.69.136.3           |
+                 | JAIN-BB.JAIN.AD.JP. IN A   192.41.197.2           |
+                 | JAIN.AD.JP.         IN SOA serial=3               |
+                 +---------------------------------------------------+
+      Authority  | <empty>                                           |
+                 +---------------------------------------------------+
+      Additional | <empty>                                           |
+                 +---------------------------------------------------+
+
+
+
+
+
+
+
+
+Ohta                        Standards Track                     [Page 6]
+
+RFC 1995            Incremental Zone Transfer in DNS         August 1996
+
+
+   or, if UDP packet overflow occurs, with the following message:
+
+                 +---------------------------------------------------+
+      Header     | OPCODE=SQUERY, RESPONSE                           |
+                 +---------------------------------------------------+
+      Question   | QNAME=JAIN.AD.JP., QCLASS=IN, QTYPE=IXFR          |
+                 +---------------------------------------------------+
+      Answer     | JAIN.AD.JP.         IN SOA serial=3               |
+                 +---------------------------------------------------+
+      Authority  | <empty>                                           |
+                 +---------------------------------------------------+
+      Additional | <empty>                                           |
+                 +---------------------------------------------------+
+
+8. Acknowledgements
+
+   The original idea of IXFR was conceived by Anant Kumar, Steve Hotz
+   and Jon Postel.
+
+   For the refinement of the protocol and documentation, many people
+   have contributed including, but not limited to, Anant Kumar, Robert
+   Austein, Paul Vixie, Randy Bush, Mark Andrews, Robert Elz and the
+   members of the IETF DNSIND working group.
+
+9. References
+
+   [NOTIFY] Vixie, P., "DNS NOTIFY: A Mechanism for Prompt
+   Notification of Zone Changes", RFC 1996, August 1996.
+
+   [STD13] Mockapetris, P., "Domain Name System", STD 13, RFC 1034 and
+   RFC 1035), November 1987.
+
+10. Security Considerations
+
+   Though DNS is related to several security problems, no attempt is
+   made to fix them in this document.
+
+   This document is believed to introduce no additional security
+   problems to the current DNS protocol.
+
+
+
+
+
+
+
+
+
+
+
+
+Ohta                        Standards Track                     [Page 7]
+
+RFC 1995            Incremental Zone Transfer in DNS         August 1996
+
+
+11. Author's Address
+
+   Masataka Ohta
+   Computer Center
+   Tokyo Institute of Technology
+   2-12-1, O-okayama, Meguro-ku, Tokyo 152, JAPAN
+
+   Phone: +81-3-5734-3299
+   Fax: +81-3-5734-3415
+   EMail: mohta@necom830.hpcl.titech.ac.jp
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ohta                        Standards Track                     [Page 8]
+
diff --git a/doc/rfc/rfc1996.txt b/doc/rfc/rfc1996.txt
new file mode 100644
index 0000000..b08f200
--- /dev/null
+++ b/doc/rfc/rfc1996.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Network Working Group                                           P. Vixie
+Request for Comments: 1996                                           ISC
+Updates: 1035                                                August 1996
+Category: Standards Track
+
+
+    A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Abstract
+
+   This memo describes the NOTIFY opcode for DNS, by which a master
+   server advises a set of slave servers that the master's data has been
+   changed and that a query should be initiated to discover the new
+   data.
+
+1. Rationale and Scope
+
+   1.1. Slow propagation of new and changed data in a DNS zone can be
+   due to a zone's relatively long refresh times.  Longer refresh times
+   are beneficial in that they reduce load on the master servers, but
+   that benefit comes at the cost of long intervals of incoherence among
+   authority servers whenever the zone is updated.
+
+   1.2. The DNS NOTIFY transaction allows master servers to inform slave
+   servers when the zone has changed -- an interrupt as opposed to poll
+   model -- which it is hoped will reduce propagation delay while not
+   unduly increasing the masters' load.  This specification only allows
+   slaves to be notified of SOA RR changes, but the architechture of
+   NOTIFY is intended to be extensible to other RR types.
+
+   1.3. This document intentionally gives more definition to the roles
+   of "Master," "Slave" and "Stealth" servers, their enumeration in NS
+   RRs, and the SOA MNAME field.  In that sense, this document can be
+   considered an addendum to [RFC1035].
+
+
+
+
+
+
+
+
+
+Vixie                       Standards Track                     [Page 1]
+
+RFC 1996                       DNS NOTIFY                    August 1996
+
+
+2. Definitions and Invariants
+
+   2.1. The following definitions are used in this document:
+
+   Slave           an authoritative server which uses zone transfer to
+                   retrieve the zone.  All slave servers are named in
+                   the NS RRs for the zone.
+
+   Master          any authoritative server configured to be the source
+                   of zone transfer for one or more slave servers.
+
+   Primary Master  master server at the root of the zone transfer
+                   dependency graph.  The primary master is named in the
+                   zone's SOA MNAME field and optionally by an NS RR.
+                   There is by definition only one primary master server
+                   per zone.
+
+   Stealth         like a slave server except not listed in an NS RR for
+                   the zone.  A stealth server, unless explicitly
+                   configured to do otherwise, will set the AA bit in
+                   responses and be capable of acting as a master.  A
+                   stealth server will only be known by other servers if
+                   they are given static configuration data indicating
+                   its existence.
+
+   Notify Set      set of servers to be notified of changes to some
+                   zone.  Default is all servers named in the NS RRset,
+                   except for any server also named in the SOA MNAME.
+                   Some implementations will permit the name server
+                   administrator to override this set or add elements to
+                   it (such as, for example, stealth servers).
+
+   2.2. The zone's servers must be organized into a dependency graph
+   such that there is a primary master, and all other servers must use
+   AXFR or IXFR either from the primary master or from some slave which
+   is also a master.  No loops are permitted in the AXFR dependency
+   graph.
+
+3. NOTIFY Message
+
+   3.1. When a master has updated one or more RRs in which slave servers
+   may be interested, the master may send the changed RR's name, class,
+   type, and optionally, new RDATA(s), to each known slave server using
+   a best efforts protocol based on the NOTIFY opcode.
+
+   3.2. NOTIFY uses the DNS Message Format, although it uses only a
+   subset of the available fields.  Fields not otherwise described
+   herein are to be filled with binary zero (0), and implementations
+
+
+
+Vixie                       Standards Track                     [Page 2]
+
+RFC 1996                       DNS NOTIFY                    August 1996
+
+
+   must ignore all messages for which this is not the case.
+
+   3.3. NOTIFY is similar to QUERY in that it has a request message with
+   the header QR flag "clear" and a response message with QR "set".  The
+   response message contains no useful information, but its reception by
+   the master is an indication that the slave has received the NOTIFY
+   and that the master can remove the slave from any retry queue for
+   this NOTIFY event.
+
+   3.4. The transport protocol used for a NOTIFY transaction will be UDP
+   unless the master has reason to believe that TCP is necessary; for
+   example, if a firewall has been installed between master and slave,
+   and only TCP has been allowed; or, if the changed RR is too large to
+   fit in a UDP/DNS datagram.
+
+   3.5. If TCP is used, both master and slave must continue to offer
+   name service during the transaction, even when the TCP transaction is
+   not making progress.  The NOTIFY request is sent once, and a
+   "timeout" is said to have occurred if no NOTIFY response is received
+   within a reasonable interval.
+
+   3.6. If UDP is used, a master periodically sends a NOTIFY request to
+   a slave until either too many copies have been sent (a "timeout"), an
+   ICMP message indicating that the port is unreachable, or until a
+   NOTIFY response is received from the slave with a matching query ID,
+   QNAME, IP source address, and UDP source port number.
+
+   Note:
+      The interval between transmissions, and the total number of
+      retransmissions, should be operational parameters specifiable by
+      the name server administrator, perhaps on a per-zone basis.
+      Reasonable defaults are a 60 second interval (or timeout if
+      using TCP), and a maximum of 5 retransmissions (for UDP).  It is
+      considered reasonable to use additive or exponential backoff for
+      the retry interval.
+
+   3.7. A NOTIFY request has QDCOUNT>0, ANCOUNT>=0, AUCOUNT>=0,
+   ADCOUNT>=0.  If ANCOUNT>0, then the answer section represents an
+   unsecure hint at the new RRset for this <QNAME,QCLASS,QTYPE>.  A
+   slave receiving such a hint is free to treat equivilence of this
+   answer section with its local data as a "no further work needs to be
+   done" indication.  If ANCOUNT=0, or ANCOUNT>0 and the answer section
+   differs from the slave's local data, then the slave should query its
+   known masters to retrieve the new data.
+
+   3.8. In no case shall the answer section of a NOTIFY request be used
+   to update a slave's local data, or to indicate that a zone transfer
+   needs to be undertaken, or to change the slave's zone refresh timers.
+
+
+
+Vixie                       Standards Track                     [Page 3]
+
+RFC 1996                       DNS NOTIFY                    August 1996
+
+
+   Only a "data present; data same" condition can lead a slave to act
+   differently if ANCOUNT>0 than it would if ANCOUNT=0.
+
+   3.9. This version of the NOTIFY specification makes no use of the
+   authority or additional data sections, and so conforming
+   implementations should set AUCOUNT=0 and ADCOUNT=0 when transmitting
+   requests.  Since a future revision of this specification may define a
+   backwards compatible use for either or both of these sections,
+   current implementations must ignore these sections, but not the
+   entire message, if AUCOUNT>0 and/or ADCOUNT>0.
+
+   3.10. If a slave receives a NOTIFY request from a host that is not a
+   known master for the zone containing the QNAME, it should ignore the
+   request and produce an error message in its operations log.
+
+   Note:
+      This implies that slaves of a multihomed master must either know
+      their master by the "closest" of the master's interface
+      addresses, or must know all of the master's interface addresses.
+      Otherwise, a valid NOTIFY request might come from an address
+      that is not on the slave's state list of masters for the zone,
+      which would be an error.
+
+   3.11. The only defined NOTIFY event at this time is that the SOA RR
+   has changed.  Upon completion of a NOTIFY transaction for QTYPE=SOA,
+   the slave should behave as though the zone given in the QNAME had
+   reached its REFRESH interval (see [RFC1035]), i.e., it should query
+   its masters for the SOA of the zone given in the NOTIFY QNAME, and
+   check the answer to see if the SOA SERIAL has been incremented since
+   the last time the zone was fetched.  If so, a zone transfer (either
+   AXFR or IXFR) should be initiated.
+
+   Note:
+      Because a deep server dependency graph may have multiple paths
+      from the primary master to any given slave, it is possible that
+      a slave will receive a NOTIFY from one of its known masters even
+      though the rest of its known masters have not yet updated their
+      copies of the zone.  Therefore, when issuing a QUERY for the
+      zone's SOA, the query should be directed at the known master who
+      was the source of the NOTIFY event, and not at any of the other
+      known masters.  This represents a departure from [RFC1035],
+      which specifies that upon expiry of the SOA REFRESH interval,
+      all known masters should be queried in turn.
+
+   3.12. If a NOTIFY request is received by a slave who does not
+   implement the NOTIFY opcode, it will respond with a NOTIMP
+   (unimplemented feature error) message.  A master server who receives
+   such a NOTIMP should consider the NOTIFY transaction complete for
+
+
+
+Vixie                       Standards Track                     [Page 4]
+
+RFC 1996                       DNS NOTIFY                    August 1996
+
+
+   that slave.
+
+4. Details and Examples
+
+   4.1. Retaining query state information across host reboots is
+   optional, but it is reasonable to simply execute an SOA NOTIFY
+   transaction on each authority zone when a server first starts.
+
+   4.2. Each slave is likely to receive several copies of the same
+   NOTIFY request:  One from the primary master, and one from each other
+   slave as that slave transfers the new zone and notifies its potential
+   peers.  The NOTIFY protocol supports this multiplicity by requiring
+   that NOTIFY be sent by a slave/master only AFTER it has updated the
+   SOA RR or has determined that no update is necessary, which in
+   practice means after a successful zone transfer.  Thus, barring
+   delivery reordering, the last NOTIFY any slave receives will be the
+   one indicating the latest change.  Since a slave always requests SOAs
+   and AXFR/IXFRs only from its known masters, it will have an
+   opportunity to retry its QUERY for the SOA after each of its masters
+   have completed each zone update.
+
+   4.3. If a master server seeks to avoid causing a large number of
+   simultaneous outbound zone transfers, it may delay for an arbitrary
+   length of time before sending a NOTIFY message to any given slave.
+   It is expected that the time will be chosen at random, so that each
+   slave will begin its transfer at a unique time.  The delay shall not
+   in any case be longer than the SOA REFRESH time.
+
+   Note:
+      This delay should be a parameter that each primary master name
+      server can specify, perhaps on a per-zone basis.  Random delays
+      of between 30 and 60 seconds would seem adequate if the servers
+      share a LAN and the zones are of moderate size.
+
+   4.4. A slave which receives a valid NOTIFY should defer action on any
+   subsequent NOTIFY with the same <QNAME,QCLASS,QTYPE> until it has
+   completed the transaction begun by the first NOTIFY.  This duplicate
+   rejection is necessary to avoid having multiple notifications lead to
+   pummeling the master server.
+
+
+
+
+
+
+
+
+
+
+
+
+Vixie                       Standards Track                     [Page 5]
+
+RFC 1996                       DNS NOTIFY                    August 1996
+
+
+   4.5 Zone has Updated on Primary Master
+
+   Primary master sends a NOTIFY request to all servers named in Notify
+   Set.  The NOTIFY request has the following characteristics:
+
+      query ID:   (new)
+      op:         NOTIFY (4)
+      resp:       NOERROR
+      flags:      AA
+      qcount:     1
+      qname:      (zone name)
+      qclass:     (zone class)
+      qtype:      T_SOA
+
+   4.6 Zone has Updated on a Slave that is also a Master
+
+   As above in 4.5, except that this server's Notify Set may be
+   different from the Primary Master's due to optional static
+   specification of local stealth servers.
+
+   4.7 Slave Receives a NOTIFY Request from a Master
+
+   When a slave server receives a NOTIFY request from one of its locally
+   designated masters for the zone enclosing the given QNAME, with
+   QTYPE=SOA and QR=0, it should enter the state it would if the zone's
+   refresh timer had expired.  It will also send a NOTIFY response back
+   to the NOTIFY request's source, with the following characteristics:
+
+      query ID:   (same)
+      op:         NOTIFY (4)
+      resp:       NOERROR
+      flags:      QR AA
+      qcount:     1
+      qname:      (zone name)
+      qclass:     (zone class)
+      qtype:      T_SOA
+
+   This is intended to be identical to the NOTIFY request, except that
+   the QR bit is also set.  The query ID of the response must be the
+   same as was received in the request.
+
+   4.8 Master Receives a NOTIFY Response from Slave
+
+   When a master server receives a NOTIFY response, it deletes this
+   query from the retry queue, thus completing the "notification
+   process" of "this" RRset change to "that" server.
+
+
+
+
+
+Vixie                       Standards Track                     [Page 6]
+
+RFC 1996                       DNS NOTIFY                    August 1996
+
+
+5. Security Considerations
+
+   We believe that the NOTIFY operation's only security considerations
+   are:
+
+   1. That a NOTIFY request with a forged IP/UDP source address can
+      cause a slave to send spurious SOA queries to its masters,
+      leading to a benign denial of service attack if the forged
+      requests are sent very often.
+
+   2. That TCP spoofing could be used against a slave server given
+      NOTIFY as a means of synchronizing an SOA query and UDP/DNS
+      spoofing as a means of forcing a zone transfer.
+
+6. References
+
+   [RFC1035]
+      Mockapetris, P., "Domain Names - Implementation and
+      Specification", STD 13, RFC 1035, November 1987.
+
+   [IXFR]
+      Ohta, M., "Incremental Zone Transfer", RFC 1995, August 1996.
+
+7. Author's Address
+
+   Paul Vixie
+   Internet Software Consortium
+   Star Route Box 159A
+   Woodside, CA 94062
+
+   Phone: +1 415 747 0204
+   EMail: paul@vix.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Vixie                       Standards Track                     [Page 7]
+
diff --git a/doc/rfc/rfc2052.txt b/doc/rfc/rfc2052.txt
new file mode 100644
index 0000000..46ba362
--- /dev/null
+++ b/doc/rfc/rfc2052.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+Network Working Group                                     A. Gulbrandsen
+Request for Comments: 2052                            Troll Technologies
+Updates: 1035, 1183                                             P. Vixie
+Category: Experimental                                 Vixie Enterprises
+                                                            October 1996
+
+
+       A DNS RR for specifying the location of services (DNS SRV)
+
+Status of this Memo
+
+   This memo defines an Experimental Protocol for the Internet
+   community.  This memo does not specify an Internet standard of any
+   kind.  Discussion and suggestions for improvement are requested.
+   Distribution of this memo is unlimited.
+
+Abstract
+
+   This document describes a DNS RR which specifies the location of the
+   server(s) for a specific protocol and domain (like a more general
+   form of MX).
+
+Overview and rationale
+
+   Currently, one must either know the exact address of a server to
+   contact it, or broadcast a question.  This has led to, for example,
+   ftp.whatever.com aliases, the SMTP-specific MX RR, and using MAC-
+   level broadcasts to locate servers.
+
+   The SRV RR allows administrators to use several servers for a single
+   domain, to move services from host to host with little fuss, and to
+   designate some hosts as primary servers for a service and others as
+   backups.
+
+   Clients ask for a specific service/protocol for a specific domain
+   (the word domain is used here in the strict RFC 1034 sense), and get
+   back the names of any available servers.
+
+Introductory example
+
+   When a SRV-cognizant web-browser wants to retrieve
+
+      http://www.asdf.com/
+
+   it does a lookup of
+
+      http.tcp.www.asdf.com
+
+
+
+
+Gulbrandsen & Vixie           Experimental                      [Page 1]
+
+RFC 2052                       DNS SRV RR                   October 1996
+
+
+   and retrieves the document from one of the servers in the reply.  The
+   example zone file near the end of the memo contains answering RRs for
+   this query.
+
+The format of the SRV RR
+
+   Here is the format of the SRV RR, whose DNS type code is 33:
+
+        Service.Proto.Name TTL Class SRV Priority Weight Port Target
+
+        (There is an example near the end of this document.)
+
+   Service
+        The symbolic name of the desired service, as defined in Assigned
+        Numbers or locally.
+
+        Some widely used services, notably POP, don't have a single
+        universal name.  If Assigned Numbers names the service
+        indicated, that name is the only name which is legal for SRV
+        lookups.  Only locally defined services may be named locally.
+        The Service is case insensitive.
+
+   Proto
+        TCP and UDP are at present the most useful values
+        for this field, though any name defined by Assigned Numbers or
+        locally may be used (as for Service).  The Proto is case
+        insensitive.
+
+   Name
+        The domain this RR refers to.  The SRV RR is unique in that the
+        name one searches for is not this name; the example near the end
+        shows this clearly.
+
+   TTL
+        Standard DNS meaning.
+
+   Class
+        Standard DNS meaning.
+
+   Priority
+        As for MX, the priority of this target host.  A client MUST
+        attempt to contact the target host with the lowest-numbered
+        priority it can reach; target hosts with the same priority
+        SHOULD be tried in pseudorandom order.  The range is 0-65535.
+
+
+
+
+
+
+
+Gulbrandsen & Vixie           Experimental                      [Page 2]
+
+RFC 2052                       DNS SRV RR                   October 1996
+
+
+   Weight
+        Load balancing mechanism.  When selecting a target host among
+        the those that have the same priority, the chance of trying this
+        one first SHOULD be proportional to its weight.  The range of
+        this number is 1-65535.  Domain administrators are urged to use
+        Weight 0 when there isn't any load balancing to do, to make the
+        RR easier to read for humans (less noisy).
+
+   Port
+        The port on this target host of this service.  The range is
+        0-65535.  This is often as specified in Assigned Numbers but
+        need not be.
+
+   Target
+        As for MX, the domain name of the target host.  There MUST be
+        one or more A records for this name. Implementors are urged, but
+        not required, to return the A record(s) in the Additional Data
+        section.  Name compression is to be used for this field.
+
+        A Target of "." means that the service is decidedly not
+        available at this domain.
+
+Domain administrator advice
+
+   Asking everyone to update their telnet (for example) clients when the
+   first internet site adds a SRV RR for Telnet/TCP is futile (even if
+   desirable).  Therefore SRV will have to coexist with A record lookups
+   for a long time, and DNS administrators should try to provide A
+   records to support old clients:
+
+      - Where the services for a single domain are spread over several
+        hosts, it seems advisable to have a list of A RRs at the same
+        DNS node as the SRV RR, listing reasonable (if perhaps
+        suboptimal) fallback hosts for Telnet, NNTP and other protocols
+        likely to be used with this name.  Note that some programs only
+        try the first address they get back from e.g. gethostbyname(),
+        and we don't know how widespread this behaviour is.
+
+      - Where one service is provided by several hosts, one can either
+        provide A records for all the hosts (in which case the round-
+        robin mechanism, where available, will share the load equally)
+        or just for one (presumably the fastest).
+
+      - If a host is intended to provide a service only when the main
+        server(s) is/are down, it probably shouldn't be listed in A
+        records.
+
+
+
+
+
+Gulbrandsen & Vixie           Experimental                      [Page 3]
+
+RFC 2052                       DNS SRV RR                   October 1996
+
+
+      - Hosts that are referenced by backup A records must use the port
+        number specified in Assigned Numbers for the service.
+
+   Currently there's a practical limit of 512 bytes for DNS replies.
+   Until all resolvers can handle larger responses, domain
+   administrators are strongly advised to keep their SRV replies below
+   512 bytes.
+
+   All round numbers, wrote Dr. Johnson, are false, and these numbers
+   are very round: A reply packet has a 30-byte overhead plus the name
+   of the service ("telnet.tcp.asdf.com" for instance); each SRV RR adds
+   20 bytes plus the name of the target host; each NS RR in the NS
+   section is 15 bytes plus the name of the name server host; and
+   finally each A RR in the additional data section is 20 bytes or so,
+   and there are A's for each SRV and NS RR mentioned in the answer.
+   This size estimate is extremely crude, but shouldn't underestimate
+   the actual answer size by much.  If an answer may be close to the
+   limit, using e.g. "dig" to look at the actual answer is a good idea.
+
+The "Weight" field
+
+   Weight, the load balancing field, is not quite satisfactory, but the
+   actual load on typical servers changes much too quickly to be kept
+   around in DNS caches.  It seems to the authors that offering
+   administrators a way to say "this machine is three times as fast as
+   that one" is the best that can practically be done.
+
+   The only way the authors can see of getting a "better" load figure is
+   asking a separate server when the client selects a server and
+   contacts it.  For short-lived services like SMTP an extra step in the
+   connection establishment seems too expensive, and for long-lived
+   services like telnet, the load figure may well be thrown off a minute
+   after the connection is established when someone else starts or
+   finishes a heavy job.
+
+The Port number
+
+   Currently, the translation from service name to port number happens
+   at the client, often using a file such as /etc/services.
+
+   Moving this information to the DNS makes it less necessary to update
+   these files on every single computer of the net every time a new
+   service is added, and makes it possible to move standard services out
+   of the "root-only" port range on unix
+
+
+
+
+
+
+
+Gulbrandsen & Vixie           Experimental                      [Page 4]
+
+RFC 2052                       DNS SRV RR                   October 1996
+
+
+Usage rules
+
+   A SRV-cognizant client SHOULD use this procedure to locate a list of
+   servers and connect to the preferred one:
+
+        Do a lookup for QNAME=service.protocol.target, QCLASS=IN,
+        QTYPE=SRV.
+
+        If the reply is NOERROR, ANCOUNT>0 and there is at least one SRV
+        RR which specifies the requested Service and Protocol in the
+        reply:
+
+             If there is precisely one SRV RR, and its Target is "."
+             (the root domain), abort.
+
+             Else, for all such RR's, build a list of (Priority, Weight,
+             Target) tuples
+
+             Sort the list by priority (lowest number first)
+
+             Create a new empty list
+
+             For each distinct priority level
+                  While there are still elements left at this priority
+                  level
+                       Select an element randomly, with probability
+                       Weight, and move it to the tail of the new list
+
+             For each element in the new list
+
+                  query the DNS for A RR's for the Target or use any
+                  RR's found in the Additional Data secion of the
+                  earlier SRV query.
+
+                  for each A RR found, try to connect to the (protocol,
+                  address, service).
+
+        else if the service desired is SMTP
+
+             skip to RFC 974 (MX).
+
+        else
+
+             Do a lookup for QNAME=target, QCLASS=IN, QTYPE=A
+
+             for each A RR found, try to connect to the (protocol,
+             address, service)
+
+
+
+
+Gulbrandsen & Vixie           Experimental                      [Page 5]
+
+RFC 2052                       DNS SRV RR                   October 1996
+
+
+   Notes:
+
+      - Port numbers SHOULD NOT be used in place of the symbolic service
+        or protocol names (for the same reason why variant names cannot
+        be allowed: Applications would have to do two or more lookups).
+
+      - If a truncated response comes back from an SRV query, and the
+        Additional Data section has at least one complete RR in it, the
+        answer MUST be considered complete and the client resolver
+        SHOULD NOT retry the query using TCP, but use normal UDP queries
+        for A RR's missing from the Additional Data section.
+
+      - A client MAY use means other than Weight to choose among target
+        hosts with equal Priority.
+
+      - A client MUST parse all of the RR's in the reply.
+
+      - If the Additional Data section doesn't contain A RR's for all
+        the SRV RR's and the client may want to connect to the target
+        host(s) involved, the client MUST look up the A RR(s).  (This
+        happens quite often when the A RR has shorter TTL than the SRV
+        or NS RR's.)
+
+      - A future standard could specify that a SRV RR whose Protocol was
+        TCP and whose Service was SMTP would override RFC 974's rules
+        with regard to the use of an MX RR.  This would allow firewalled
+        organizations with several SMTP relays to control the load
+        distribution using the Weight field.
+
+      - Future protocols could be designed to use SRV RR lookups as the
+        means by which clients locate their servers.
+
+Fictional example
+
+   This is (part of) the zone file for asdf.com, a still-unused domain:
+
+        $ORIGIN asdf.com.
+        @               SOA server.asdf.com. root.asdf.com. (
+                            1995032001 3600 3600 604800 86400 )
+                        NS  server.asdf.com.
+                        NS  ns1.ip-provider.net.
+                        NS  ns2.ip-provider.net.
+        ftp.tcp         SRV 0 0 21 server.asdf.com.
+        finger.tcp      SRV 0 0 79 server.asdf.com.
+        ; telnet - use old-slow-box or new-fast-box if either is
+        ; available, make three quarters of the logins go to
+        ; new-fast-box.
+        telnet.tcp      SRV 0 1 23 old-slow-box.asdf.com.
+
+
+
+Gulbrandsen & Vixie           Experimental                      [Page 6]
+
+RFC 2052                       DNS SRV RR                   October 1996
+
+
+                        SRV 0 3 23 new-fast-box.asdf.com.
+        ; if neither old-slow-box or new-fast-box is up, switch to
+        ; using the sysdmin's box and the server
+                        SRV 1 0 23 sysadmins-box.asdf.com.
+                        SRV 1 0 23 server.asdf.com.
+        ; HTTP - server is the main server, new-fast-box is the backup
+        ; (On new-fast-box, the HTTP daemon runs on port 8000)
+        http.tcp        SRV 0 0 80 server.asdf.com.
+                        SRV 10 0 8000 new-fast-box.asdf.com.
+        ; since we want to support both http://asdf.com/ and
+        ; http://www.asdf.com/ we need the next two RRs as well
+        http.tcp.www    SRV 0 0 80 server.asdf.com.
+                        SRV 10 0 8000 new-fast-box.asdf.com.
+        ; SMTP - mail goes to the server, and to the IP provider if
+        ; the net is down
+        smtp.tcp        SRV 0 0 25 server.asdf.com.
+                        SRV 1 0 25 mailhost.ip-provider.net.
+        @               MX  0 server.asdf.com.
+                        MX  1 mailhost.ip-provider.net.
+        ; NNTP - use the IP providers's NNTP server
+        nntp.tcp        SRV 0 0 119 nntphost.ip-provider.net.
+        ; IDB is an locally defined protocol
+        idb.tcp         SRV  0 0 2025 new-fast-box.asdf.com.
+        ; addresses
+        server          A   172.30.79.10
+        old-slow-box    A   172.30.79.11
+        sysadmins-box   A   172.30.79.12
+        new-fast-box    A   172.30.79.13
+        ; backup A records - new-fast-box and old-slow-box are
+        ; included, naturally, and server is too, but might go
+        ; if the load got too bad
+        @               A   172.30.79.10
+                        A   172.30.79.11
+                        A   172.30.79.13
+        ; backup A RR for www.asdf.com
+        www             A       172.30.79.10
+        ; NO other services are supported
+        *.tcp           SRV  0 0 0 .
+        *.udp           SRV  0 0 0 .
+
+   In this example, a telnet connection to "asdf.com." needs an SRV
+   lookup of "telnet.tcp.asdf.com." and possibly A lookups of "new-
+   fast-box.asdf.com." and/or the other hosts named.  The size of the
+   SRV reply is approximately 365 bytes:
+
+      30 bytes general overhead
+      20 bytes for the query string, "telnet.tcp.asdf.com."
+      130 bytes for 4 SRV RR's, 20 bytes each plus the lengths of "new-
+
+
+
+Gulbrandsen & Vixie           Experimental                      [Page 7]
+
+RFC 2052                       DNS SRV RR                   October 1996
+
+
+        fast-box", "old-slow-box", "server" and "sysadmins-box" -
+        "asdf.com" in the query section is quoted here and doesn't
+        need to be counted again.
+      75 bytes for 3 NS RRs, 15 bytes each plus the lengths of
+        "server", "ns1.ip-provider.net." and "ns2" - again, "ip-
+        provider.net." is quoted and only needs to be counted once.
+      120 bytes for the 6 A RR's mentioned by the SRV and NS RR's.
+
+Refererences
+
+   RFC 1918: Rekhter, Y., Moskowitz, R., Karrenberg, D., de Groot, G.,
+        and E.  Lear, "Address Allocation for Private Internets",
+        RFC 1918, February 1996.
+
+   RFC 1916 Berkowitz, H., Ferguson, P, Leland, W. and P. Nesser,
+        "Enterprise Renumbering: Experience and Information
+        Solicitation", RFC 1916, February 1996.
+
+   RFC 1912 Barr, D., "Common DNS Operational and Configuration
+        Errors", RFC 1912, February 1996.
+
+   RFC 1900: Carpenter, B., and Y. Rekhter, "Renumbering Needs Work",
+        RFC 1900, February 1996.
+
+   RFC 1920: Postel, J., "INTERNET OFFICIAL PROTOCOL STANDARDS",
+        STD 1, RFC 1920, March 1996.
+
+   RFC 1814: Gerich, E., "Unique Addresses are Good", RFC 1814, June
+             1995.
+
+   RFC 1794: Brisco, T., "DNS Support for Load Balancing", April 1995.
+
+   RFC 1713: Romao, A., "Tools for DNS debugging", November 1994.
+
+   RFC 1712: Farrell, C., Schulze, M., Pleitner, S., and D. Baldoni,
+        "DNS Encoding of Geographical Location", RFC 1712, November
+        1994.
+
+   RFC 1706: Manning, B. and R. Colella, "DNS NSAP Resource Records",
+        RFC 1706, October 1994.
+
+   RFC 1700: Reynolds, J., and J. Postel, "ASSIGNED NUMBERS",
+        STD 2, RFC 1700, October 1994.
+
+   RFC 1183: Ullmann, R., Mockapetris, P., Mamakos, L., and
+        C. Everhart, "New DNS RR Definitions", RFC 1183, November
+        1990.
+
+
+
+
+Gulbrandsen & Vixie           Experimental                      [Page 8]
+
+RFC 2052                       DNS SRV RR                   October 1996
+
+
+   RFC 1101: Mockapetris, P., "DNS encoding of network names and other
+        types", RFC 1101, April 1989.
+
+   RFC 1035: Mockapetris, P., "Domain names - implementation and
+        specification", STD 13, RFC 1035, November 1987.
+
+   RFC 1034: Mockapetris, P., "Domain names - concepts and
+        facilities", STD 13, RFC 1034, November 1987.
+
+   RFC 1033: Lottor, M., "Domain administrators operations guide",
+        RFC 1033, November 1987.
+
+   RFC 1032: Stahl, M., "Domain administrators guide", RFC 1032,
+        November 1987.
+
+   RFC 974: Partridge, C., "Mail routing and the domain system",
+        STD 14, RFC 974, January 1986.
+
+Security Considerations
+
+   The authors believes this RR to not cause any new security problems.
+   Some problems become more visible, though.
+
+      - The ability to specify ports on a fine-grained basis obviously
+        changes how a router can filter packets.  It becomes impossible
+        to block internal clients from accessing specific external
+        services, slightly harder to block internal users from running
+        unautorised services, and more important for the router
+        operations and DNS operations personnel to cooperate.
+
+      - There is no way a site can keep its hosts from being referenced
+        as servers (as, indeed, some sites become unwilling secondary
+        MXes today).  This could lead to denial of service.
+
+      - With SRV, DNS spoofers can supply false port numbers, as well as
+        host names and addresses.  The authors do not see any practical
+        effect of this.
+
+   We assume that as the DNS-security people invent new features, DNS
+   servers will return the relevant RRs in the Additional Data section
+   when answering an SRV query.
+
+
+
+
+
+
+
+
+
+
+Gulbrandsen & Vixie           Experimental                      [Page 9]
+
+RFC 2052                       DNS SRV RR                   October 1996
+
+
+Authors' Addresses
+
+   Arnt Gulbrandsen
+   Troll Tech
+   Postboks 6133 Etterstad
+   N-0602 Oslo
+   Norway
+
+   Phone: +47 22646966
+   EMail: agulbra@troll.no
+
+
+   Paul Vixie
+   Vixie Enterprises
+   Star Route 159A
+   Woodside, CA  94062
+
+   Phone: (415) 747-0204
+   EMail: paul@vix.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gulbrandsen & Vixie           Experimental                     [Page 10]
+
diff --git a/doc/rfc/rfc2104.txt b/doc/rfc/rfc2104.txt
new file mode 100644
index 0000000..a205103
--- /dev/null
+++ b/doc/rfc/rfc2104.txt
@@ -0,0 +1,620 @@
+
+
+
+
+
+
+Network Working Group                                       H. Krawczyk
+Request for Comments: 2104                                          IBM
+Category: Informational                                      M. Bellare
+                                                                   UCSD
+                                                             R. Canetti
+                                                                    IBM
+                                                          February 1997
+
+
+             HMAC: Keyed-Hashing for Message Authentication
+
+Status of This Memo
+
+   This memo provides information for the Internet community.  This memo
+   does not specify an Internet standard of any kind.  Distribution of
+   this memo is unlimited.
+
+Abstract
+
+   This document describes HMAC, a mechanism for message authentication
+   using cryptographic hash functions. HMAC can be used with any
+   iterative cryptographic hash function, e.g., MD5, SHA-1, in
+   combination with a secret shared key.  The cryptographic strength of
+   HMAC depends on the properties of the underlying hash function.
+
+1. Introduction
+
+   Providing a way to check the integrity of information transmitted
+   over or stored in an unreliable medium is a prime necessity in the
+   world of open computing and communications. Mechanisms that provide
+   such integrity check based on a secret key are usually called
+   "message authentication codes" (MAC). Typically, message
+   authentication codes are used between two parties that share a secret
+   key in order to validate information transmitted between these
+   parties. In this document we present such a MAC mechanism based on
+   cryptographic hash functions. This mechanism, called HMAC, is based
+   on work by the authors [BCK1] where the construction is presented and
+   cryptographically analyzed. We refer to that work for the details on
+   the rationale and security analysis of HMAC, and its comparison to
+   other keyed-hash methods.
+
+
+
+
+
+
+
+
+
+
+
+Krawczyk, et. al.            Informational                      [Page 1]
+
+RFC 2104                          HMAC                     February 1997
+
+
+   HMAC can be used in combination with any iterated cryptographic hash
+   function. MD5 and SHA-1 are examples of such hash functions. HMAC
+   also uses a secret key for calculation and verification of the
+   message authentication values. The main goals behind this
+   construction are
+
+   * To use, without modifications, available hash functions.
+     In particular, hash functions that perform well in software,
+     and for which code is freely and widely available.
+
+   * To preserve the original performance of the hash function without
+     incurring a significant degradation.
+
+   * To use and handle keys in a simple way.
+
+   * To have a well understood cryptographic analysis of the strength of
+     the authentication mechanism based on reasonable assumptions on the
+     underlying hash function.
+
+   * To allow for easy replaceability of the underlying hash function in
+     case that faster or more secure hash functions are found or
+     required.
+
+   This document specifies HMAC using a generic cryptographic hash
+   function (denoted by H). Specific instantiations of HMAC need to
+   define a particular hash function. Current candidates for such hash
+   functions include SHA-1 [SHA], MD5 [MD5], RIPEMD-128/160 [RIPEMD].
+   These different realizations of HMAC will be denoted by HMAC-SHA1,
+   HMAC-MD5, HMAC-RIPEMD, etc.
+
+   Note: To the date of writing of this document MD5 and SHA-1 are the
+   most widely used cryptographic hash functions. MD5 has been recently
+   shown to be vulnerable to collision search attacks [Dobb].  This
+   attack and other currently known weaknesses of MD5 do not compromise
+   the use of MD5 within HMAC as specified in this document (see
+   [Dobb]); however, SHA-1 appears to be a cryptographically stronger
+   function. To this date, MD5 can be considered for use in HMAC for
+   applications where the superior performance of MD5 is critical.   In
+   any case, implementers and users need to be aware of possible
+   cryptanalytic developments regarding any of these cryptographic hash
+   functions, and the eventual need to replace the underlying hash
+   function. (See section 6 for more information on the security of
+   HMAC.)
+
+
+
+
+
+
+
+
+Krawczyk, et. al.            Informational                      [Page 2]
+
+RFC 2104                          HMAC                     February 1997
+
+
+2. Definition of HMAC
+
+   The definition of HMAC requires a cryptographic hash function, which
+   we denote by H, and a secret key K. We assume H to be a cryptographic
+   hash function where data is hashed by iterating a basic compression
+   function on blocks of data.   We denote by B the byte-length of such
+   blocks (B=64 for all the above mentioned examples of hash functions),
+   and by L the byte-length of hash outputs (L=16 for MD5, L=20 for
+   SHA-1).  The authentication key K can be of any length up to B, the
+   block length of the hash function.  Applications that use keys longer
+   than B bytes will first hash the key using H and then use the
+   resultant L byte string as the actual key to HMAC. In any case the
+   minimal recommended length for K is L bytes (as the hash output
+   length). See section 3 for more information on keys.
+
+   We define two fixed and different strings ipad and opad as follows
+   (the 'i' and 'o' are mnemonics for inner and outer):
+
+                   ipad = the byte 0x36 repeated B times
+                  opad = the byte 0x5C repeated B times.
+
+   To compute HMAC over the data `text' we perform
+
+                    H(K XOR opad, H(K XOR ipad, text))
+
+   Namely,
+
+    (1) append zeros to the end of K to create a B byte string
+        (e.g., if K is of length 20 bytes and B=64, then K will be
+         appended with 44 zero bytes 0x00)
+    (2) XOR (bitwise exclusive-OR) the B byte string computed in step
+        (1) with ipad
+    (3) append the stream of data 'text' to the B byte string resulting
+        from step (2)
+    (4) apply H to the stream generated in step (3)
+    (5) XOR (bitwise exclusive-OR) the B byte string computed in
+        step (1) with opad
+    (6) append the H result from step (4) to the B byte string
+        resulting from step (5)
+    (7) apply H to the stream generated in step (6) and output
+        the result
+
+   For illustration purposes, sample code based on MD5 is provided as an
+   appendix.
+
+
+
+
+
+
+
+Krawczyk, et. al.            Informational                      [Page 3]
+
+RFC 2104                          HMAC                     February 1997
+
+
+3. Keys
+
+   The key for HMAC can be of any length (keys longer than B bytes are
+   first hashed using H).  However, less than L bytes is strongly
+   discouraged as it would decrease the security strength of the
+   function.  Keys longer than L bytes are acceptable but the extra
+   length would not significantly increase the function strength. (A
+   longer key may be advisable if the randomness of the key is
+   considered weak.)
+
+   Keys need to be chosen at random (or using a cryptographically strong
+   pseudo-random generator seeded with a random seed), and periodically
+   refreshed.  (Current attacks do not indicate a specific recommended
+   frequency for key changes as these attacks are practically
+   infeasible.  However, periodic key refreshment is a fundamental
+   security practice that helps against potential weaknesses of the
+   function and keys, and limits the damage of an exposed key.)
+
+4. Implementation Note
+
+   HMAC is defined in such a way that the underlying hash function H can
+   be used with no modification to its code. In particular, it uses the
+   function H with the pre-defined initial value IV (a fixed value
+   specified by each iterative hash function to initialize its
+   compression function).  However, if desired, a performance
+   improvement can be achieved at the cost of (possibly) modifying the
+   code of H to support variable IVs.
+
+   The idea is that the intermediate results of the compression function
+   on the B-byte blocks (K XOR ipad) and (K XOR opad) can be precomputed
+   only once at the time of generation of the key K, or before its first
+   use. These intermediate results are stored and then used to
+   initialize the IV of H each time that a message needs to be
+   authenticated.  This method saves, for each authenticated message,
+   the application of the compression function of H on two B-byte blocks
+   (i.e., on (K XOR ipad) and (K XOR opad)). Such a savings may be
+   significant when authenticating short streams of data.  We stress
+   that the stored intermediate values need to be treated and protected
+   the same as secret keys.
+
+   Choosing to implement HMAC in the above way is a decision of the
+   local implementation and has no effect on inter-operability.
+
+
+
+
+
+
+
+
+
+Krawczyk, et. al.            Informational                      [Page 4]
+
+RFC 2104                          HMAC                     February 1997
+
+
+5. Truncated output
+
+   A well-known practice with message authentication codes is to
+   truncate the output of the MAC and output only part of the bits
+   (e.g., [MM, ANSI]).  Preneel and van Oorschot [PV] show some
+   analytical advantages of truncating the output of hash-based MAC
+   functions. The results in this area are not absolute as for the
+   overall security advantages of truncation. It has advantages (less
+   information on the hash result available to an attacker) and
+   disadvantages (less bits to predict for the attacker).  Applications
+   of HMAC can choose to truncate the output of HMAC by outputting the t
+   leftmost bits of the HMAC computation for some parameter t (namely,
+   the computation is carried in the normal way as defined in section 2
+   above but the end result is truncated to t bits). We recommend that
+   the output length t be not less than half the length of the hash
+   output (to match the birthday attack bound) and not less than 80 bits
+   (a suitable lower bound on the number of bits that need to be
+   predicted by an attacker).  We propose denoting a realization of HMAC
+   that uses a hash function H with t bits of output as HMAC-H-t. For
+   example, HMAC-SHA1-80 denotes HMAC computed using the SHA-1 function
+   and with the output truncated to 80 bits.  (If the parameter t is not
+   specified, e.g. HMAC-MD5, then it is assumed that all the bits of the
+   hash are output.)
+
+6. Security
+
+   The security of the message authentication mechanism presented here
+   depends on cryptographic properties of the hash function H: the
+   resistance to collision finding (limited to the case where the
+   initial value is secret and random, and where the output of the
+   function is not explicitly available to the attacker), and the
+   message authentication property of the compression function of H when
+   applied to single blocks (in HMAC these blocks are partially unknown
+   to an attacker as they contain the result of the inner H computation
+   and, in particular, cannot be fully chosen by the attacker).
+
+   These properties, and actually stronger ones, are commonly assumed
+   for hash functions of the kind used with HMAC. In particular, a hash
+   function for which the above properties do not hold would become
+   unsuitable for most (probably, all) cryptographic applications,
+   including alternative message authentication schemes based on such
+   functions.  (For a complete analysis and rationale of the HMAC
+   function the reader is referred to [BCK1].)
+
+
+
+
+
+
+
+
+Krawczyk, et. al.            Informational                      [Page 5]
+
+RFC 2104                          HMAC                     February 1997
+
+
+   Given the limited confidence gained so far as for the cryptographic
+   strength of candidate hash functions, it is important to observe the
+   following two properties of the HMAC construction and its secure use
+   for message authentication:
+
+   1. The construction is independent of the details of the particular
+   hash function H in use and then the latter can be replaced by any
+   other secure (iterative) cryptographic hash function.
+
+   2. Message authentication, as opposed to encryption, has a
+   "transient" effect. A published breaking of a message authentication
+   scheme would lead to the replacement of that scheme, but would have
+   no adversarial effect on information authenticated in the past.  This
+   is in sharp contrast with encryption, where information encrypted
+   today may suffer from exposure in the future if, and when, the
+   encryption algorithm is broken.
+
+   The strongest attack known against HMAC is based on the frequency of
+   collisions for the hash function H ("birthday attack") [PV,BCK2], and
+   is totally impractical for minimally reasonable hash functions.
+
+   As an example, if we consider a hash function like MD5 where the
+   output length equals L=16 bytes (128 bits) the attacker needs to
+   acquire the correct message authentication tags computed (with the
+   _same_ secret key K!) on about 2**64 known plaintexts.  This would
+   require the processing of at least 2**64 blocks under H, an
+   impossible task in any realistic scenario (for a block length of 64
+   bytes this would take 250,000 years in a continuous 1Gbps link, and
+   without changing the secret key K during all this time).  This attack
+   could become realistic only if serious flaws in the collision
+   behavior of the function H are discovered (e.g.  collisions found
+   after 2**30 messages). Such a discovery would determine the immediate
+   replacement of the function H (the effects of such failure would be
+   far more severe for the traditional uses of H in the context of
+   digital signatures, public key certificates, etc.).
+
+   Note: this attack needs to be strongly contrasted with regular
+   collision attacks on cryptographic hash functions where no secret key
+   is involved and where 2**64 off-line parallelizable (!) operations
+   suffice to find collisions.  The latter attack is approaching
+   feasibility [VW] while the birthday attack on HMAC is totally
+   impractical.  (In the above examples, if one uses a hash function
+   with, say, 160 bit of output then 2**64 should be replaced by 2**80.)
+
+
+
+
+
+
+
+
+Krawczyk, et. al.            Informational                      [Page 6]
+
+RFC 2104                          HMAC                     February 1997
+
+
+   A correct implementation of the above construction, the choice of
+   random (or cryptographically pseudorandom) keys, a secure key
+   exchange mechanism, frequent key refreshments, and good secrecy
+   protection of keys are all essential ingredients for the security of
+   the integrity verification mechanism provided by HMAC.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Krawczyk, et. al.            Informational                      [Page 7]
+
+RFC 2104                          HMAC                     February 1997
+
+
+Appendix -- Sample Code
+
+   For the sake of illustration we provide the following sample code for
+   the implementation of HMAC-MD5 as well as some corresponding test
+   vectors (the code is based on MD5 code as described in [MD5]).
+
+/*
+** Function: hmac_md5
+*/
+
+void
+hmac_md5(text, text_len, key, key_len, digest)
+unsigned char*  text;                /* pointer to data stream */
+int             text_len;            /* length of data stream */
+unsigned char*  key;                 /* pointer to authentication key */
+int             key_len;             /* length of authentication key */
+caddr_t         digest;              /* caller digest to be filled in */
+
+{
+        MD5_CTX context;
+        unsigned char k_ipad[65];    /* inner padding -
+                                      * key XORd with ipad
+                                      */
+        unsigned char k_opad[65];    /* outer padding -
+                                      * key XORd with opad
+                                      */
+        unsigned char tk[16];
+        int i;
+        /* if key is longer than 64 bytes reset it to key=MD5(key) */
+        if (key_len > 64) {
+
+                MD5_CTX      tctx;
+
+                MD5Init(&tctx);
+                MD5Update(&tctx, key, key_len);
+                MD5Final(tk, &tctx);
+
+                key = tk;
+                key_len = 16;
+        }
+
+        /*
+         * the HMAC_MD5 transform looks like:
+         *
+         * MD5(K XOR opad, MD5(K XOR ipad, text))
+         *
+         * where K is an n byte key
+         * ipad is the byte 0x36 repeated 64 times
+
+
+
+Krawczyk, et. al.            Informational                      [Page 8]
+
+RFC 2104                          HMAC                     February 1997
+
+
+         * opad is the byte 0x5c repeated 64 times
+         * and text is the data being protected
+         */
+
+        /* start out by storing key in pads */
+        bzero( k_ipad, sizeof k_ipad);
+        bzero( k_opad, sizeof k_opad);
+        bcopy( key, k_ipad, key_len);
+        bcopy( key, k_opad, key_len);
+
+        /* XOR key with ipad and opad values */
+        for (i=0; i<64; i++) {
+                k_ipad[i] ^= 0x36;
+                k_opad[i] ^= 0x5c;
+        }
+        /*
+         * perform inner MD5
+         */
+        MD5Init(&context);                   /* init context for 1st
+                                              * pass */
+        MD5Update(&context, k_ipad, 64)      /* start with inner pad */
+        MD5Update(&context, text, text_len); /* then text of datagram */
+        MD5Final(digest, &context);          /* finish up 1st pass */
+        /*
+         * perform outer MD5
+         */
+        MD5Init(&context);                   /* init context for 2nd
+                                              * pass */
+        MD5Update(&context, k_opad, 64);     /* start with outer pad */
+        MD5Update(&context, digest, 16);     /* then results of 1st
+                                              * hash */
+        MD5Final(digest, &context);          /* finish up 2nd pass */
+}
+
+Test Vectors (Trailing '\0' of a character string not included in test):
+
+  key =         0x0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b0b
+  key_len =     16 bytes
+  data =        "Hi There"
+  data_len =    8  bytes
+  digest =      0x9294727a3638bb1c13f48ef8158bfc9d
+
+  key =         "Jefe"
+  data =        "what do ya want for nothing?"
+  data_len =    28 bytes
+  digest =      0x750c783e6ab0b503eaa86e310a5db738
+
+  key =         0xAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
+
+
+
+Krawczyk, et. al.            Informational                      [Page 9]
+
+RFC 2104                          HMAC                     February 1997
+
+
+  key_len       16 bytes
+  data =        0xDDDDDDDDDDDDDDDDDDDD...
+                ..DDDDDDDDDDDDDDDDDDDD...
+                ..DDDDDDDDDDDDDDDDDDDD...
+                ..DDDDDDDDDDDDDDDDDDDD...
+                ..DDDDDDDDDDDDDDDDDDDD
+  data_len =    50 bytes
+  digest =      0x56be34521d144c88dbb8c733f0e8b3f6
+
+Acknowledgments
+
+   Pau-Chen Cheng, Jeff Kraemer, and Michael Oehler, have provided
+   useful comments on early drafts, and ran the first interoperability
+   tests of this specification. Jeff and Pau-Chen kindly provided the
+   sample code and test vectors that appear in the appendix.  Burt
+   Kaliski, Bart Preneel, Matt Robshaw, Adi Shamir, and Paul van
+   Oorschot have provided useful comments and suggestions during the
+   investigation of the HMAC construction.
+
+References
+
+   [ANSI]  ANSI X9.9, "American National Standard for Financial
+           Institution Message Authentication (Wholesale)," American
+           Bankers Association, 1981.   Revised 1986.
+
+   [Atk]   Atkinson, R., "IP Authentication Header", RFC 1826, August
+           1995.
+
+   [BCK1]  M. Bellare, R. Canetti, and H. Krawczyk,
+           "Keyed Hash Functions and Message Authentication",
+           Proceedings of Crypto'96, LNCS 1109, pp. 1-15.
+           (http://www.research.ibm.com/security/keyed-md5.html)
+
+   [BCK2]  M. Bellare, R. Canetti, and H. Krawczyk,
+           "Pseudorandom Functions Revisited: The Cascade Construction",
+           Proceedings of FOCS'96.
+
+   [Dobb]  H. Dobbertin, "The Status of MD5  After a Recent Attack",
+           RSA Labs' CryptoBytes, Vol. 2 No. 2, Summer 1996.
+           http://www.rsa.com/rsalabs/pubs/cryptobytes.html
+
+   [PV]    B. Preneel and P. van Oorschot, "Building fast MACs from hash
+           functions", Advances in Cryptology -- CRYPTO'95 Proceedings,
+           Lecture Notes in Computer Science, Springer-Verlag Vol.963,
+           1995, pp. 1-14.
+
+   [MD5]   Rivest, R., "The MD5 Message-Digest Algorithm",
+           RFC 1321, April 1992.
+
+
+
+Krawczyk, et. al.            Informational                     [Page 10]
+
+RFC 2104                          HMAC                     February 1997
+
+
+   [MM]    Meyer, S. and Matyas, S.M., Cryptography, New York Wiley,
+           1982.
+
+   [RIPEMD] H. Dobbertin, A. Bosselaers, and B. Preneel, "RIPEMD-160: A
+            strengthened version of RIPEMD", Fast Software Encryption,
+            LNCS Vol 1039, pp. 71-82.
+            ftp://ftp.esat.kuleuven.ac.be/pub/COSIC/bosselae/ripemd/.
+
+   [SHA]   NIST, FIPS PUB 180-1: Secure Hash Standard, April 1995.
+
+   [Tsu]   G. Tsudik, "Message authentication with one-way hash
+           functions", In Proceedings of Infocom'92, May 1992.
+           (Also in "Access Control and Policy Enforcement in
+            Internetworks", Ph.D. Dissertation, Computer Science
+            Department, University of Southern California, April 1991.)
+
+   [VW]    P. van Oorschot and M. Wiener, "Parallel Collision
+           Search with Applications to Hash Functions and Discrete
+           Logarithms", Proceedings of the 2nd ACM Conf. Computer and
+           Communications Security, Fairfax, VA, November 1994.
+
+Authors' Addresses
+
+   Hugo Krawczyk
+   IBM T.J. Watson Research Center
+   P.O.Box 704
+   Yorktown Heights, NY 10598
+
+   EMail: hugo@watson.ibm.com
+
+   Mihir Bellare
+   Dept of Computer Science and Engineering
+   Mail Code 0114
+   University of California at San Diego
+   9500 Gilman Drive
+   La Jolla, CA 92093
+
+   EMail: mihir@cs.ucsd.edu
+
+   Ran Canetti
+   IBM T.J. Watson Research Center
+   P.O.Box 704
+   Yorktown Heights, NY 10598
+
+   EMail: canetti@watson.ibm.com
+
+
+
+
+
+
+Krawczyk, et. al.            Informational                     [Page 11]
+
+
diff --git a/doc/rfc/rfc2119.txt b/doc/rfc/rfc2119.txt
new file mode 100644
index 0000000..e31fae4
--- /dev/null
+++ b/doc/rfc/rfc2119.txt
@@ -0,0 +1,171 @@
+
+
+
+
+
+
+Network Working Group                                         S. Bradner
+Request for Comments: 2119                            Harvard University
+BCP: 14                                                       March 1997
+Category: Best Current Practice
+
+
+        Key words for use in RFCs to Indicate Requirement Levels
+
+Status of this Memo
+
+   This document specifies an Internet Best Current Practices for the
+   Internet Community, and requests discussion and suggestions for
+   improvements.  Distribution of this memo is unlimited.
+
+Abstract
+
+   In many standards track documents several words are used to signify
+   the requirements in the specification.  These words are often
+   capitalized.  This document defines these words as they should be
+   interpreted in IETF documents.  Authors who follow these guidelines
+   should incorporate this phrase near the beginning of their document:
+
+      The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
+      NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and
+      "OPTIONAL" in this document are to be interpreted as described in
+      RFC 2119.
+
+   Note that the force of these words is modified by the requirement
+   level of the document in which they are used.
+
+1. MUST   This word, or the terms "REQUIRED" or "SHALL", mean that the
+   definition is an absolute requirement of the specification.
+
+2. MUST NOT   This phrase, or the phrase "SHALL NOT", mean that the
+   definition is an absolute prohibition of the specification.
+
+3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
+   may exist valid reasons in particular circumstances to ignore a
+   particular item, but the full implications must be understood and
+   carefully weighed before choosing a different course.
+
+4. SHOULD NOT   This phrase, or the phrase "NOT RECOMMENDED" mean that
+   there may exist valid reasons in particular circumstances when the
+   particular behavior is acceptable or even useful, but the full
+   implications should be understood and the case carefully weighed
+   before implementing any behavior described with this label.
+
+
+
+
+
+Bradner                  Best Current Practice                  [Page 1]
+
+RFC 2119                     RFC Key Words                    March 1997
+
+
+5. MAY   This word, or the adjective "OPTIONAL", mean that an item is
+   truly optional.  One vendor may choose to include the item because a
+   particular marketplace requires it or because the vendor feels that
+   it enhances the product while another vendor may omit the same item.
+   An implementation which does not include a particular option MUST be
+   prepared to interoperate with another implementation which does
+   include the option, though perhaps with reduced functionality. In the
+   same vein an implementation which does include a particular option
+   MUST be prepared to interoperate with another implementation which
+   does not include the option (except, of course, for the feature the
+   option provides.)
+
+6. Guidance in the use of these Imperatives
+
+   Imperatives of the type defined in this memo must be used with care
+   and sparingly.  In particular, they MUST only be used where it is
+   actually required for interoperation or to limit behavior which has
+   potential for causing harm (e.g., limiting retransmisssions)  For
+   example, they must not be used to try to impose a particular method
+   on implementors where the method is not required for
+   interoperability.
+
+7. Security Considerations
+
+   These terms are frequently used to specify behavior with security
+   implications.  The effects on security of not implementing a MUST or
+   SHOULD, or doing something the specification says MUST NOT or SHOULD
+   NOT be done may be very subtle. Document authors should take the time
+   to elaborate the security implications of not following
+   recommendations or requirements as most implementors will not have
+   had the benefit of the experience and discussion that produced the
+   specification.
+
+8. Acknowledgments
+
+   The definitions of these terms are an amalgam of definitions taken
+   from a number of RFCs.  In addition, suggestions have been
+   incorporated from a number of people including Robert Ullmann, Thomas
+   Narten, Neal McBurnett, and Robert Elz.
+
+
+
+
+
+
+
+
+
+
+
+
+Bradner                  Best Current Practice                  [Page 2]
+
+RFC 2119                     RFC Key Words                    March 1997
+
+
+9. Author's Address
+
+      Scott Bradner
+      Harvard University
+      1350 Mass. Ave.
+      Cambridge, MA 02138
+
+      phone - +1 617 495 3864
+
+      email - sob@harvard.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bradner                  Best Current Practice                  [Page 3]
+
diff --git a/doc/rfc/rfc2133.txt b/doc/rfc/rfc2133.txt
new file mode 100644
index 0000000..ea66cf0
--- /dev/null
+++ b/doc/rfc/rfc2133.txt
@@ -0,0 +1,1795 @@
+
+
+
+
+
+
+Network Working Group                                        R. Gilligan
+Request for Comments: 2133                                      Freegate
+Category: Informational                                       S. Thomson
+                                                                Bellcore
+                                                                J. Bound
+                                                                 Digital
+                                                              W. Stevens
+                                                              Consultant
+                                                              April 1997
+
+               Basic Socket Interface Extensions for IPv6
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  This memo
+   does not specify an Internet standard of any kind.  Distribution of
+   this memo is unlimited.
+
+Abstract
+
+   The de facto standard application program interface (API) for TCP/IP
+   applications is the "sockets" interface.  Although this API was
+   developed for Unix in the early 1980s it has also been implemented on
+   a wide variety of non-Unix systems.  TCP/IP applications written
+   using the sockets API have in the past enjoyed a high degree of
+   portability and we would like the same portability with IPv6
+   applications.  But changes are required to the sockets API to support
+   IPv6 and this memo describes these changes.  These include a new
+   socket address structure to carry IPv6 addresses, new address
+   conversion functions, and some new socket options.  These extensions
+   are designed to provide access to the basic IPv6 features required by
+   TCP and UDP applications, including multicasting, while introducing a
+   minimum of change into the system and providing complete
+   compatibility for existing IPv4 applications.  Additional extensions
+   for advanced IPv6 features (raw sockets and access to the IPv6
+   extension headers) are defined in another document [5].
+
+Table of Contents
+
+   1.  Introduction ................................................  2
+   2.  Design Considerations .......................................  3
+   2.1.  What Needs to be Changed ..................................  3
+   2.2.  Data Types ................................................  5
+   2.3.  Headers ...................................................  5
+   2.4.  Structures ................................................  5
+   3.  Socket Interface ............................................  5
+   3.1.  IPv6 Address Family and Protocol Family ...................  5
+   3.2.  IPv6 Address Structure ....................................  6
+
+
+
+Gilligan, et. al.            Informational                      [Page 1]
+
+RFC 2133            IPv6 Socket Interface Extensions          April 1997
+
+
+   3.3.  Socket Address Structure for 4.3BSD-Based Systems .........  6
+   3.4.  Socket Address Structure for 4.4BSD-Based Systems .........  7
+   3.5.  The Socket Functions ......................................  8
+   3.6.  Compatibility with IPv4 Applications ......................  9
+   3.7.  Compatibility with IPv4 Nodes .............................  9
+   3.8.  IPv6 Wildcard Address ..................................... 10
+   3.9.  IPv6 Loopback Address ..................................... 11
+   4.  Interface Identification .................................... 12
+   4.1.  Name-to-Index ............................................. 13
+   4.2.  Index-to-Name ............................................. 13
+   4.3.  Return All Interface Names and Indexes .................... 14
+   4.4.  Free Memory ............................................... 14
+   5.  Socket Options .............................................. 14
+   5.1.  Changing Socket Type ...................................... 15
+   5.2.  Unicast Hop Limit ......................................... 16
+   5.3.  Sending and Receiving Multicast Packets ................... 17
+   6.  Library Functions ........................................... 19
+   6.1.  Hostname-to-Address Translation ........................... 19
+   6.2.  Address To Hostname Translation ........................... 22
+   6.3.  Protocol-Independent Hostname and Service Name Translation  22
+   6.4.  Socket Address Structure to Hostname and Service Name ..... 25
+   6.5.  Address Conversion Functions .............................. 27
+   6.6.  Address Testing Macros .................................... 28
+   7.  Summary of New Definitions .................................. 29
+   8.  Security Considerations ..................................... 31
+   9.  Acknowledgments ............................................. 31
+   10.  References ................................................. 31
+   11.  Authors' Addresses ......................................... 32
+
+1.  Introduction
+
+   While IPv4 addresses are 32 bits long, IPv6 interfaces are identified
+   by 128-bit addresses.  The socket interface make the size of an IP
+   address quite visible to an application; virtually all TCP/IP
+   applications for BSD-based systems have knowledge of the size of an
+   IP address.  Those parts of the API that expose the addresses must be
+   changed to accommodate the larger IPv6 address size.  IPv6 also
+   introduces new features (e.g., flow label and priority), some of
+   which must be made visible to applications via the API.  This memo
+   defines a set of extensions to the socket interface to support the
+   larger address size and new features of IPv6.
+
+
+
+
+
+
+
+
+
+
+Gilligan, et. al.            Informational                      [Page 2]
+
+RFC 2133            IPv6 Socket Interface Extensions          April 1997
+
+
+2.  Design Considerations
+
+   There are a number of important considerations in designing changes
+   to this well-worn API:
+
+   -  The API changes should provide both source and binary
+       compatibility for programs written to the original API.  That is,
+       existing program binaries should continue to operate when run on
+       a system supporting the new API.  In addition, existing
+       applications that are re-compiled and run on a system supporting
+       the new API should continue to operate.  Simply put, the API
+       changes for IPv6 should not break existing programs.
+
+   -  The changes to the API should be as small as possible in order to
+       simplify the task of converting existing IPv4 applications to
+       IPv6.
+
+   -  Where possible, applications should be able to use this API to
+       interoperate with both IPv6 and IPv4 hosts.  Applications should
+       not need to know which type of host they are communicating with.
+
+   -  IPv6 addresses carried in data structures should be 64-bit
+       aligned.  This is necessary in order to obtain optimum
+       performance on 64-bit machine architectures.
+
+   Because of the importance of providing IPv4 compatibility in the API,
+   these extensions are explicitly designed to operate on machines that
+   provide complete support for both IPv4 and IPv6.  A subset of this
+   API could probably be designed for operation on systems that support
+   only IPv6.  However, this is not addressed in this memo.
+
+2.1.  What Needs to be Changed
+
+   The socket interface API consists of a few distinct components:
+
+    -  Core socket functions.
+
+    -  Address data structures.
+
+    -  Name-to-address translation functions.
+
+    -  Address conversion functions.
+
+    The core socket functions -- those functions that deal with such
+    things as setting up and tearing down TCP connections, and sending
+    and receiving UDP packets -- were designed to be transport
+    independent.  Where protocol addresses are passed as function
+    arguments, they are carried via opaque pointers.  A protocol-specific
+
+
+
+Gilligan, et. al.            Informational                      [Page 3]
+
+RFC 2133            IPv6 Socket Interface Extensions          April 1997
+
+
+    address data structure is defined for each protocol that the socket
+    functions support.  Applications must cast pointers to these
+    protocol-specific address structures into pointers to the generic
+    "sockaddr" address structure when using the socket functions.  These
+    functions need not change for IPv6, but a new IPv6-specific address
+    data structure is needed.
+
+    The "sockaddr_in" structure is the protocol-specific data structure
+    for IPv4.  This data structure actually includes 8-octets of unused
+    space, and it is tempting to try to use this space to adapt the
+    sockaddr_in structure to IPv6.  Unfortunately, the sockaddr_in
+    structure is not large enough to hold the 16-octet IPv6 address as
+    well as the other information (address family and port number) that
+    is needed.  So a new address data structure must be defined for IPv6.
+
+    The name-to-address translation functions in the socket interface are
+    gethostbyname() and gethostbyaddr().  These must be modified to
+    support IPv6 and the semantics defined must provide 100% backward
+    compatibility for all existing IPv4 applications, along with IPv6
+    support for new applications.  Additionally, the POSIX 1003.g work in
+    progress [4] specifies a new hostname-to-address translation function
+    which is protocol independent.  This function can also be used with
+    IPv6.
+
+    The address conversion functions -- inet_ntoa() and inet_addr() --
+    convert IPv4 addresses between binary and printable form.  These
+    functions are quite specific to 32-bit IPv4 addresses.  We have
+    designed two analogous functions that convert both IPv4 and IPv6
+    addresses, and carry an address type parameter so that they can be
+    extended to other protocol families as well.
+
+    Finally, a few miscellaneous features are needed to support IPv6.
+    New interfaces are needed to support the IPv6 flow label, priority,
+    and hop limit header fields.  New socket options are needed to
+    control the sending and receiving of IPv6 multicast packets.
+
+    The socket interface will be enhanced in the future to provide access
+    to other IPv6 features.  These extensions are described in [5].
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gilligan, et. al.            Informational                      [Page 4]
+
+RFC 2133            IPv6 Socket Interface Extensions          April 1997
+
+
+2.2.  Data Types
+
+   The data types of the structure elements given in this memo are
+   intended to be examples, not absolute requirements.  Whenever
+   possible, POSIX 1003.1g data types are used:  u_intN_t means an
+   unsigned integer of exactly N bits (e.g., u_int16_t) and u_intNm_t
+   means an unsigned integer of at least N bits (e.g., u_int32m_t).  We
+   also assume the argument data types from 1003.1g when possible (e.g.,
+    the final argument to setsockopt() is a size_t value).  Whenever
+   buffer sizes are specified, the POSIX 1003.1 size_t data type is used
+   (e.g., the two length arguments to getnameinfo()).
+
+2.3.  Headers
+
+   When function prototypes and structures are shown we show the headers
+   that must be #included to cause that item to be defined.
+
+2.4.  Structures
+
+   When structures are described the members shown are the ones that
+   must appear in an implementation.  Additional, nonstandard members
+   may also be defined by an implementation.
+
+   The ordering shown for the members of a structure is the recommended
+   ordering, given alignment considerations of multibyte members, but an
+   implementation may order the members differently.
+
+3.  Socket Interface
+
+   This section specifies the socket interface changes for IPv6.
+
+3.1.  IPv6 Address Family and Protocol Family
+
+   A new address family name, AF_INET6, is defined in <sys/socket.h>.
+   The AF_INET6 definition distinguishes between the original
+   sockaddr_in address data structure, and the new sockaddr_in6 data
+   structure.
+
+   A new protocol family name, PF_INET6, is defined in <sys/socket.h>.
+   Like most of the other protocol family names, this will usually be
+   defined to have the same value as the corresponding address family
+   name:
+
+       #define PF_INET6        AF_INET6
+
+   The PF_INET6 is used in the first argument to the socket() function
+   to indicate that an IPv6 socket is being created.
+
+
+
+
+Gilligan, et. al.            Informational                      [Page 5]
+
+RFC 2133            IPv6 Socket Interface Extensions          April 1997
+
+
+3.2.  IPv6 Address Structure
+
+   A new data structure to hold a single IPv6 address is defined as
+    follows:
+
+       #include <netinet/in.h>
+
+       struct in6_addr {
+           u_int8_t  s6_addr[16];      /* IPv6 address */
+       }
+
+   This data structure contains an array of sixteen 8-bit elements,
+   which make up one 128-bit IPv6 address.  The IPv6 address is stored
+   in network byte order.
+
+3.3.  Socket Address Structure for 4.3BSD-Based Systems
+
+   In the socket interface, a different protocol-specific data structure
+   is defined to carry the addresses for each protocol suite.  Each
+   protocol-specific data structure is designed so it can be cast into a
+   protocol-independent data structure -- the "sockaddr" structure.
+   Each has a "family" field that overlays the "sa_family" of the
+   sockaddr data structure.  This field identifies the type of the data
+   structure.
+
+   The sockaddr_in structure is the protocol-specific address data
+   structure for IPv4.  It is used to pass addresses between
+   applications and the system in the socket functions.  The following
+   structure is defined to carry IPv6 addresses:
+
+       #include <netinet/in.h>
+
+       struct sockaddr_in6 {
+           u_int16m_t      sin6_family;    /* AF_INET6 */
+           u_int16m_t      sin6_port;      /* transport layer port # */
+           u_int32m_t      sin6_flowinfo;  /* IPv6 flow information */
+           struct in6_addr sin6_addr;      /* IPv6 address */
+       };
+
+   This structure is designed to be compatible with the sockaddr data
+   structure used in the 4.3BSD release.
+
+   The sin6_family field identifies this as a sockaddr_in6 structure.
+   This field overlays the sa_family field when the buffer is cast to a
+   sockaddr data structure.  The value of this field must be AF_INET6.
+
+
+
+
+
+
+Gilligan, et. al.            Informational                      [Page 6]
+
+RFC 2133            IPv6 Socket Interface Extensions          April 1997
+
+
+   The sin6_port field contains the 16-bit UDP or TCP port number.  This
+   field is used in the same way as the sin_port field of the
+   sockaddr_in structure.  The port number is stored in network byte
+   order.
+
+   The sin6_flowinfo field is a 32-bit field that contains two pieces of
+   information: the 24-bit IPv6 flow label and the 4-bit priority field.
+   The contents and interpretation of this member is unspecified at this
+   time.
+
+   The sin6_addr field is a single in6_addr structure (defined in the
+   previous section).  This field holds one 128-bit IPv6 address.  The
+   address is stored in network byte order.
+
+   The ordering of elements in this structure is specifically designed
+   so that the sin6_addr field will be aligned on a 64-bit boundary.
+   This is done for optimum performance on 64-bit architectures.
+
+   Notice that the sockaddr_in6 structure will normally be larger than
+   the generic sockaddr structure.  On many existing implementations the
+   sizeof(struct sockaddr_in) equals sizeof(struct sockaddr), with both
+   being 16 bytes.  Any existing code that makes this assumption needs
+   to be examined carefully when converting to IPv6.
+
+3.4.  Socket Address Structure for 4.4BSD-Based Systems
+
+   The 4.4BSD release includes a small, but incompatible change to the
+   socket interface.  The "sa_family" field of the sockaddr data
+   structure was changed from a 16-bit value to an 8-bit value, and the
+   space saved used to hold a length field, named "sa_len".  The
+   sockaddr_in6 data structure given in the previous section cannot be
+   correctly cast into the newer sockaddr data structure.  For this
+   reason, the following alternative IPv6 address data structure is
+   provided to be used on systems based on 4.4BSD:
+
+       #include <netinet/in.h>
+
+       #define SIN6_LEN
+
+       struct sockaddr_in6 {
+           u_char          sin6_len;       /* length of this struct */
+           u_char          sin6_family;    /* AF_INET6 */
+           u_int16m_t      sin6_port;      /* transport layer port # */
+           u_int32m_t      sin6_flowinfo;  /* IPv6 flow information */
+           struct in6_addr sin6_addr;      /* IPv6 address */
+       };
+
+
+
+
+
+Gilligan, et. al.            Informational                      [Page 7]
+
+RFC 2133            IPv6 Socket Interface Extensions          April 1997
+
+
+   The only differences between this data structure and the 4.3BSD
+   variant are the inclusion of the length field, and the change of the
+   family field to a 8-bit data type.  The definitions of all the other
+   fields are identical to the structure defined in the previous
+   section.
+
+   Systems that provide this version of the sockaddr_in6 data structure
+   must also declare SIN6_LEN as a result of including the
+   <netinet/in.h> header.  This macro allows applications to determine
+   whether they are being built on a system that supports the 4.3BSD or
+   4.4BSD variants of the data structure.
+
+3.5.  The Socket Functions
+
+   Applications call the socket() function to create a socket descriptor
+   that represents a communication endpoint.  The arguments to the
+   socket() function tell the system which protocol to use, and what
+   format address structure will be used in subsequent functions.  For
+   example, to create an IPv4/TCP socket, applications make the call:
+
+       s = socket(PF_INET, SOCK_STREAM, 0);
+
+   To create an IPv4/UDP socket, applications make the call:
+
+       s = socket(PF_INET, SOCK_DGRAM, 0);
+
+   Applications may create IPv6/TCP and IPv6/UDP sockets by simply using
+   the constant PF_INET6 instead of PF_INET in the first argument.  For
+   example, to create an IPv6/TCP socket, applications make the call:
+
+       s = socket(PF_INET6, SOCK_STREAM, 0);
+
+   To create an IPv6/UDP socket, applications make the call:
+
+       s = socket(PF_INET6, SOCK_DGRAM, 0);
+
+   Once the application has created a PF_INET6 socket, it must use the
+   sockaddr_in6 address structure when passing addresses in to the
+   system.  The functions that the application uses to pass addresses
+   into the system are:
+
+       bind()
+       connect()
+       sendmsg()
+       sendto()
+
+
+
+
+
+
+Gilligan, et. al.            Informational                      [Page 8]
+
+RFC 2133            IPv6 Socket Interface Extensions          April 1997
+
+
+   The system will use the sockaddr_in6 address structure to return
+   addresses to applications that are using PF_INET6 sockets.  The
+   functions that return an address from the system to an application
+   are:
+
+          accept()
+          recvfrom()
+          recvmsg()
+          getpeername()
+          getsockname()
+
+   No changes to the syntax of the socket functions are needed to
+   support IPv6, since all of the "address carrying" functions use an
+   opaque address pointer, and carry an address length as a function
+   argument.
+
+3.6.  Compatibility with IPv4 Applications
+
+   In order to support the large base of applications using the original
+   API, system implementations must provide complete source and binary
+   compatibility with the original API.  This means that systems must
+   continue to support PF_INET sockets and the sockaddr_in address
+   structure.  Applications must be able to create IPv4/TCP and IPv4/UDP
+   sockets using the PF_INET constant in the socket() function, as
+   described in the previous section.  Applications should be able to
+   hold a combination of IPv4/TCP, IPv4/UDP, IPv6/TCP and IPv6/UDP
+   sockets simultaneously within the same process.
+
+   Applications using the original API should continue to operate as
+   they did on systems supporting only IPv4.  That is, they should
+   continue to interoperate with IPv4 nodes.
+
+3.7.  Compatibility with IPv4 Nodes
+
+   The API also provides a different type of compatibility: the ability
+   for IPv6 applications to interoperate with IPv4 applications.  This
+   feature uses the IPv4-mapped IPv6 address format defined in the IPv6
+   addressing architecture specification [2].  This address format
+   allows the IPv4 address of an IPv4 node to be represented as an IPv6
+   address.  The IPv4 address is encoded into the low-order 32 bits of
+   the IPv6 address, and the high-order 96 bits hold the fixed prefix
+   0:0:0:0:0:FFFF.  IPv4-mapped addresses are written as follows:
+
+       ::FFFF:<IPv4-address>
+
+   These addresses are often generated automatically by the
+   gethostbyname() function when the specified host has only IPv4
+   addresses (as described in Section 6.1).
+
+
+
+Gilligan, et. al.            Informational                      [Page 9]
+
+RFC 2133            IPv6 Socket Interface Extensions          April 1997
+
+
+   Applications may use PF_INET6 sockets to open TCP connections to IPv4
+   nodes, or send UDP packets to IPv4 nodes, by simply encoding the
+   destination's IPv4 address as an IPv4-mapped IPv6 address, and
+   passing that address, within a sockaddr_in6 structure, in the
+   connect() or sendto() call.  When applications use PF_INET6 sockets
+   to accept TCP connections from IPv4 nodes, or receive UDP packets
+   from IPv4 nodes, the system returns the peer's address to the
+   application in the accept(), recvfrom(), or getpeername() call using
+   a sockaddr_in6 structure encoded this way.
+
+   Few applications will likely need to know which type of node they are
+   interoperating with.  However, for those applications that do need to
+   know, the IN6_IS_ADDR_V4MAPPED() macro, defined in Section 6.6, is
+   provided.
+
+3.8.  IPv6 Wildcard Address
+
+   While the bind() function allows applications to select the source IP
+   address of UDP packets and TCP connections, applications often want
+   the system to select the source address for them.  With IPv4, one
+   specifies the address as the symbolic constant INADDR_ANY (called the
+   "wildcard" address) in the bind() call, or simply omits the bind()
+   entirely.
+
+   Since the IPv6 address type is a structure (struct in6_addr), a
+   symbolic constant can be used to initialize an IPv6 address variable,
+   but cannot be used in an assignment.  Therefore systems provide the
+   IPv6 wildcard address in two forms.
+
+   The first version is a global variable named "in6addr_any" that is an
+   in6_addr structure.  The extern declaration for this variable is
+   defined in <netinet/in.h>:
+
+       extern const struct in6_addr in6addr_any;
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gilligan, et. al.            Informational                     [Page 10]
+
+RFC 2133            IPv6 Socket Interface Extensions          April 1997
+
+
+   Applications use in6addr_any similarly to the way they use INADDR_ANY
+   in IPv4.  For example, to bind a socket to port number 23, but let
+   the system select the source address, an application could use the
+   following code:
+
+       struct sockaddr_in6 sin6;
+        . . .
+       sin6.sin6_family = AF_INET6;
+       sin6.sin6_flowinfo = 0;
+       sin6.sin6_port = htons(23);
+       sin6.sin6_addr = in6addr_any;  /* structure assignment */
+        . . .
+       if (bind(s, (struct sockaddr *) &sin6, sizeof(sin6)) == -1)
+               . . .
+
+   The other version is a symbolic constant named IN6ADDR_ANY_INIT and
+   is defined in <netinet/in.h>.  This constant can be used to
+   initialize an in6_addr structure:
+
+       struct in6_addr anyaddr = IN6ADDR_ANY_INIT;
+
+   Note that this constant can be used ONLY at declaration time.  It can
+   not be used to assign a previously declared in6_addr structure.  For
+   example, the following code will not work:
+
+       /* This is the WRONG way to assign an unspecified address */
+       struct sockaddr_in6 sin6;
+        . . .
+       sin6.sin6_addr = IN6ADDR_ANY_INIT; /* will NOT compile */
+
+   Be aware that the IPv4 INADDR_xxx constants are all defined in host
+   byte order but the IPv6 IN6ADDR_xxx constants and the IPv6
+   in6addr_xxx externals are defined in network byte order.
+
+3.9.  IPv6 Loopback Address
+
+   Applications may need to send UDP packets to, or originate TCP
+   connections to, services residing on the local node.  In IPv4, they
+   can do this by using the constant IPv4 address INADDR_LOOPBACK in
+   their connect(), sendto(), or sendmsg() call.
+
+   IPv6 also provides a loopback address to contact local TCP and UDP
+   services.  Like the unspecified address, the IPv6 loopback address is
+   provided in two forms -- a global variable and a symbolic constant.
+
+
+
+
+
+
+
+Gilligan, et. al.            Informational                     [Page 11]
+
+RFC 2133            IPv6 Socket Interface Extensions          April 1997
+
+
+   The global variable is an in6_addr structure named
+   "in6addr_loopback."  The extern declaration for this variable is
+   defined in <netinet/in.h>:
+
+       extern const struct in6_addr in6addr_loopback;
+
+   Applications use in6addr_loopback as they would use INADDR_LOOPBACK
+   in IPv4 applications (but beware of the byte ordering difference
+   mentioned at the end of the previous section).  For example, to open
+   a TCP connection to the local telnet server, an application could use
+   the following code:
+
+       struct sockaddr_in6 sin6;
+        . . .
+       sin6.sin6_family = AF_INET6;
+       sin6.sin6_flowinfo = 0;
+       sin6.sin6_port = htons(23);
+       sin6.sin6_addr = in6addr_loopback;  /* structure assignment */
+        . . .
+       if (connect(s, (struct sockaddr *) &sin6, sizeof(sin6)) == -1)
+               . . .
+
+   The symbolic constant is named IN6ADDR_LOOPBACK_INIT and is defined
+   in <netinet/in.h>.  It can be used at declaration time ONLY; for
+   example:
+
+       struct in6_addr loopbackaddr = IN6ADDR_LOOPBACK_INIT;
+
+   Like IN6ADDR_ANY_INIT, this constant cannot be used in an assignment
+   to a previously declared IPv6 address variable.
+
+4.  Interface Identification
+
+   This API uses an interface index (a small positive integer) to
+   identify the local interface on which a multicast group is joined
+   (Section 5.3).  Additionally, the advanced API [5] uses these same
+   interface indexes to identify the interface on which a datagram is
+   received, or to specify the interface on which a datagram is to be
+   sent.
+
+   Interfaces are normally known by names such as "le0", "sl1", "ppp2",
+   and the like.  On Berkeley-derived implementations, when an interface
+   is made known to the system, the kernel assigns a unique positive
+   integer value (called the interface index) to that interface.  These
+   are small positive integers that start at 1.  (Note that 0 is never
+   used for an interface index.)  There may be gaps so that there is no
+   current interface for a particular positive interface index.
+
+
+
+
+Gilligan, et. al.            Informational                     [Page 12]
+
+RFC 2133            IPv6 Socket Interface Extensions          April 1997
+
+
+   This API defines two functions that map between an interface name and
+   index, a third function that returns all the interface names and
+   indexes, and a fourth function to return the dynamic memory allocated
+   by the previous function.  How these functions are implemented is
+   left up to the implementation.  4.4BSD implementations can implement
+   these functions using the existing sysctl() function with the
+   NET_RT_LIST command.  Other implementations may wish to use ioctl()
+   for this purpose.
+
+4.1.  Name-to-Index
+
+   The first function maps an interface name into its corresponding
+   index.
+
+       #include <net/if.h>
+
+       unsigned int  if_nametoindex(const char *ifname);
+
+   If the specified interface does not exist, the return value is 0.
+
+4.2.  Index-to-Name
+
+   The second function maps an interface index into its corresponding
+   name.
+
+       #include <net/if.h>
+
+       char  *if_indextoname(unsigned int ifindex, char *ifname);
+
+   The ifname argument must point to a buffer of at least IFNAMSIZ bytes
+   into which the interface name corresponding to the specified index is
+   returned.  (IFNAMSIZ is also defined in <net/if.h> and its value
+   includes a terminating null byte at the end of the interface name.)
+   This pointer is also the return value of the function.  If there is
+   no interface corresponding to the specified index, NULL is returned.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gilligan, et. al.            Informational                     [Page 13]
+
+RFC 2133            IPv6 Socket Interface Extensions          April 1997
+
+
+4.3.  Return All Interface Names and Indexes
+
+   The final function returns an array of if_nameindex structures, one
+   structure per interface.
+
+       #include <net/if.h>
+
+       struct if_nameindex {
+         unsigned int   if_index;  /* 1, 2, ... */
+         char          *if_name;   /* null terminated name: "le0", ... */
+       };
+
+       struct if_nameindex  *if_nameindex(void);
+
+   The end of the array of structures is indicated by a structure with
+   an if_index of 0 and an if_name of NULL.  The function returns a NULL
+   pointer upon an error.
+
+   The memory used for this array of structures along with the interface
+   names pointed to by the if_name members is obtained dynamically.
+   This memory is freed by the next function.
+
+4.4.  Free Memory
+
+   The following function frees the dynamic memory that was allocated by
+   if_nameindex().
+
+       #include <net/if.h>
+
+       void  if_freenameindex(struct if_nameindex *ptr);
+
+   The argument to this function must be a pointer that was returned by
+   if_nameindex().
+
+5.  Socket Options
+
+   A number of new socket options are defined for IPv6.  All of these
+   new options are at the IPPROTO_IPV6 level.  That is, the "level"
+   parameter in the getsockopt() and setsockopt() calls is IPPROTO_IPV6
+   when using these options.  The constant name prefix IPV6_ is used in
+   all of the new socket options.  This serves to clearly identify these
+   options as applying to IPv6.
+
+   The declaration for IPPROTO_IPV6, the new IPv6 socket options, and
+   related constants defined in this section are obtained by including
+   the header <netinet/in.h>.
+
+
+
+
+
+Gilligan, et. al.            Informational                     [Page 14]
+
+RFC 2133            IPv6 Socket Interface Extensions          April 1997
+
+
+5.1.  Changing Socket Type
+
+   Unix allows open sockets to be passed between processes via the
+   exec() call and other means.  It is a relatively common application
+   practice to pass open sockets across exec() calls.  Thus it is
+   possible for an application using the original API to pass an open
+   PF_INET socket to an application that is expecting to receive a
+   PF_INET6 socket.  Similarly, it is possible for an application using
+   the extended API to pass an open PF_INET6 socket to an application
+   using the original API, which would be equipped only to deal with
+   PF_INET sockets.  Either of these cases could cause problems, because
+   the application that is passed the open socket might not know how to
+   decode the address structures returned in subsequent socket
+   functions.
+
+   To remedy this problem, a new setsockopt() option is defined that
+   allows an application to "convert" a PF_INET6 socket into a PF_INET
+   socket and vice versa.
+
+   An IPv6 application that is passed an open socket from an unknown
+   process may use the IPV6_ADDRFORM setsockopt() option to "convert"
+   the socket to PF_INET6.  Once that has been done, the system will
+   return sockaddr_in6 address structures in subsequent socket
+   functions.
+
+   An IPv6 application that is about to pass an open PF_INET6 socket to
+   a program that is not be IPv6 capable can "downgrade" the socket to
+   PF_INET before calling exec().  After that, the system will return
+   sockaddr_in address structures to the application that was exec()'ed.
+   Be aware that you cannot downgrade an IPv6 socket to an IPv4 socket
+   unless all nonwildcard addresses already associated with the IPv6
+   socket are IPv4-mapped IPv6 addresses.
+
+   The IPV6_ADDRFORM option is valid at both the IPPROTO_IP and
+   IPPROTO_IPV6 levels.  The only valid option values are PF_INET6 and
+   PF_INET.  For example, to convert a PF_INET6 socket to PF_INET, a
+   program would call:
+
+       int  addrform = PF_INET;
+
+       if (setsockopt(s, IPPROTO_IPV6, IPV6_ADDRFORM,
+                      (char *) &addrform, sizeof(addrform)) == -1)
+           perror("setsockopt IPV6_ADDRFORM");
+
+
+
+
+
+
+
+
+Gilligan, et. al.            Informational                     [Page 15]
+
+RFC 2133            IPv6 Socket Interface Extensions          April 1997
+
+
+   An application may use IPV6_ADDRFORM with getsockopt() to learn
+   whether an open socket is a PF_INET of PF_INET6 socket.  For example:
+
+       int  addrform;
+       size_t  len = sizeof(addrform);
+
+       if (getsockopt(s, IPPROTO_IPV6, IPV6_ADDRFORM,
+                      (char *) &addrform, &len) == -1)
+           perror("getsockopt IPV6_ADDRFORM");
+       else if (addrform == PF_INET)
+           printf("This is an IPv4 socket.\n");
+       else if (addrform == PF_INET6)
+           printf("This is an IPv6 socket.\n");
+       else
+           printf("This system is broken.\n");
+
+5.2.  Unicast Hop Limit
+
+   A new setsockopt() option controls the hop limit used in outgoing
+   unicast IPv6 packets.  The name of this option is IPV6_UNICAST_HOPS,
+   and it is used at the IPPROTO_IPV6 layer.  The following example
+   illustrates how it is used:
+
+       int  hoplimit = 10;
+
+       if (setsockopt(s, IPPROTO_IPV6, IPV6_UNICAST_HOPS,
+                      (char *) &hoplimit, sizeof(hoplimit)) == -1)
+           perror("setsockopt IPV6_UNICAST_HOPS");
+
+   When the IPV6_UNICAST_HOPS option is set with setsockopt(), the
+   option value given is used as the hop limit for all subsequent
+   unicast packets sent via that socket.  If the option is not set, the
+   system selects a default value.  The integer hop limit value (called
+   x) is interpreted as follows:
+
+       x < -1:        return an error of EINVAL
+       x == -1:       use kernel default
+       0 <= x <= 255: use x
+       x >= 256:      return an error of EINVAL
+
+
+
+
+
+
+
+
+
+
+
+
+Gilligan, et. al.            Informational                     [Page 16]
+
+RFC 2133            IPv6 Socket Interface Extensions          April 1997
+
+
+   The IPV6_UNICAST_HOPS option may be used with getsockopt() to
+   determine the hop limit value that the system will use for subsequent
+   unicast packets sent via that socket.  For example:
+
+       int  hoplimit;
+       size_t  len = sizeof(hoplimit);
+
+       if (getsockopt(s, IPPROTO_IPV6, IPV6_UNICAST_HOPS,
+                      (char *) &hoplimit, &len) == -1)
+           perror("getsockopt IPV6_UNICAST_HOPS");
+       else
+           printf("Using %d for hop limit.\n", hoplimit);
+
+5.3.  Sending and Receiving Multicast Packets
+
+   IPv6 applications may send UDP multicast packets by simply specifying
+   an IPv6 multicast address in the address argument of the sendto()
+   function.
+
+   Three socket options at the IPPROTO_IPV6 layer control some of the
+   parameters for sending multicast packets.  Setting these options is
+   not required:  applications may send multicast packets without using
+   these options.  The setsockopt() options for controlling the sending
+   of multicast packets are summarized below:
+
+       IPV6_MULTICAST_IF
+
+           Set the interface to use for outgoing multicast packets.  The
+           argument is the index of the interface to use.
+
+           Argument type: unsigned int
+
+       IPV6_MULTICAST_HOPS
+
+           Set the hop limit to use for outgoing multicast packets.
+           (Note a separate option - IPV6_UNICAST_HOPS - is provided to
+           set the hop limit to use for outgoing unicast packets.)  The
+           interpretation of the argument is the same as for the
+           IPV6_UNICAST_HOPS option:
+
+               x < -1:        return an error of EINVAL
+               x == -1:       use kernel default
+               0 <= x <= 255: use x
+               x >= 256:      return an error of EINVAL
+
+           Argument type: int
+
+
+
+
+
+Gilligan, et. al.            Informational                     [Page 17]
+
+RFC 2133            IPv6 Socket Interface Extensions          April 1997
+
+
+       IPV6_MULTICAST_LOOP
+
+           Controls whether outgoing multicast packets  sent  should  be
+           delivered  back  to the local application.  A toggle.  If the
+           option is set to 1, multicast packets are looped back.  If it
+           is set to 0, they are not.
+
+           Argument type: unsigned int
+
+   The reception of multicast packets is controlled by the two
+   setsockopt() options summarized below:
+
+       IPV6_ADD_MEMBERSHIP
+
+           Join a multicast group on a specified local interface.  If
+           the interface index is specified as 0, the kernel chooses the
+           local interface.  For example, some kernels look up the
+           multicast group in the normal IPv6 routing table and using
+           the resulting interface.
+
+           Argument type: struct ipv6_mreq
+
+       IPV6_DROP_MEMBERSHIP
+
+           Leave a multicast group on a specified interface.
+
+           Argument type: struct ipv6_mreq
+
+   The argument type of both of these options is the ipv6_mreq
+   structure, defined as:
+
+       #include <netinet/in.h>
+
+       struct ipv6_mreq {
+           struct in6_addr ipv6mr_multiaddr; /* IPv6 multicast addr */
+           unsigned int    ipv6mr_interface; /* interface index */
+       };
+
+   Note that to receive multicast datagrams a process must join the
+   multicast group and bind the UDP port to which datagrams will be
+   sent.  Some processes also bind the multicast group address to the
+   socket, in addition to the port, to prevent other datagrams destined
+   to that same port from being delivered to the socket.
+
+
+
+
+
+
+
+
+Gilligan, et. al.            Informational                     [Page 18]
+
+RFC 2133            IPv6 Socket Interface Extensions          April 1997
+
+
+6.  Library Functions
+
+   New library functions are needed to perform a variety of operations
+   with IPv6 addresses.  Functions are needed to lookup IPv6 addresses
+   in the Domain Name System (DNS).  Both forward lookup (hostname-to-
+   address translation) and reverse lookup (address-to-hostname
+   translation) need to be supported.  Functions are also needed to
+   convert IPv6 addresses between their binary and textual form.
+
+6.1.  Hostname-to-Address Translation
+
+   The commonly used function gethostbyname() remains unchanged as does
+   the hostent structure to which it returns a pointer.  Existing
+   applications that call this function continue to receive only IPv4
+   addresses that are the result of a query in the DNS for A records.
+   (We assume the DNS is being used; some environments may be using a
+   hosts file or some other name resolution system, either of which may
+   impede renumbering.  We also assume that the RES_USE_INET6 resolver
+   option is not set, which we describe in more detail shortly.)
+
+   Two new changes are made to support IPv6 addresses.  First, the
+   following function is new:
+
+       #include <sys/socket.h>
+       #include <netdb.h>
+
+       struct hostent *gethostbyname2(const char *name, int af);
+
+   The af argument specifies the address family.  The default operation
+   of this function is simple:
+
+    -  If the af argument is AF_INET, then a query is made for A
+       records.  If successful, IPv4 addresses are returned and the
+       h_length member of the hostent structure will be 4, else the
+       function returns a NULL pointer.
+
+    -  If the af argument is AF_INET6, then a query is made for AAAA
+       records.  If successful, IPv6 addresses are returned and the
+       h_length member of the hostent structure will be 16, else the
+       function returns a NULL pointer.
+
+
+
+
+
+
+
+
+
+
+
+Gilligan, et. al.            Informational                     [Page 19]
+
+RFC 2133            IPv6 Socket Interface Extensions          April 1997
+
+
+   The second change, that provides additional functionality, is a new
+   resolver option RES_USE_INET6, which is defined as a result of
+   including the <resolv.h> header.  (This option is provided starting
+   with the BIND 4.9.4 release.)  There are three ways to set this
+   option.
+
+    -  The first way is
+
+           res_init();
+           _res.options |= RES_USE_INET6;
+
+       and then call either gethostbyname() or gethostbyname2().  This
+       option then affects only the process that is calling the
+       resolver.
+
+    -  The second way to set this option is to set the environment
+       variable RES_OPTIONS, as in RES_OPTIONS=inet6.  (This example is
+       for the Bourne and Korn shells.)  This method affects any
+       processes that see this environment variable.
+
+    -  The third way is to set this option in the resolver configuration
+       file (normally /etc/resolv.conf) and the option then affects all
+       applications on the host.  This final method should not be done
+       until all applications on the host are capable of dealing with
+       IPv6 addresses.
+
+   There is no priority among these three methods.  When the
+   RES_USE_INET6 option is set, two changes occur:
+
+    -  gethostbyname(host) first calls gethostbyname2(host, AF_INET6)
+       looking for AAAA records, and if this fails it then calls
+       gethostbyname2(host, AF_INET) looking for A records.
+
+    -  gethostbyname2(host, AF_INET) always returns IPv4-mapped IPv6
+       addresses with the h_length member of the hostent structure set
+       to 16.
+
+   An application must not enable the RES_USE_INET6 option until it is
+   prepared to deal with 16-byte addresses in the returned hostent
+   structure.
+
+
+
+
+
+
+
+
+
+
+
+Gilligan, et. al.            Informational                     [Page 20]
+
+RFC 2133            IPv6 Socket Interface Extensions          April 1997
+
+
+   The following table summarizes the operation of the existing
+   gethostbyname() function, the new function gethostbyname2(), along
+   with the new resolver option RES_USE_INET6.
+
++------------------+---------------------------------------------------+
+|                  |              RES_USE_INET6 option                 |
+|                  +-------------------------+-------------------------+
+|                  |          off            |           on            |
++------------------+-------------------------+-------------------------+
+|                  |Search for A records.    |Search for AAAA records. |
+| gethostbyname    | If found, return IPv4   | If found, return IPv6   |
+| (host)           | addresses (h_length=4). | addresses (h_length=16).|
+|                  | Else error.             | Else search for A       |
+|                  |                         | records.  If found,     |
+|                  |Provides backward        | return IPv4-mapped IPv6 |
+|                  | compatibility with all  | addresses (h_length=16).|
+|                  | existing IPv4 appls.    | Else error.             |
++------------------+-------------------------+-------------------------+
+|                  |Search for A records.    |Search for A records.    |
+| gethostbyname2   | If found, return IPv4   | If found, return        |
+| (host, AF_INET)  | addresses (h_length=4). | IPv4-mapped IPv6        |
+|                  | Else error.             | addresses (h_length=16).|
+|                  |                         | Else error.             |
++------------------+-------------------------+-------------------------+
+|                  |Search for AAAA records. |Search for AAAA records. |
+| gethostbyname2   | If found, return IPv6   | If found, return IPv6   |
+| (host, AF_INET6) | addresses (h_length=16).| addresses (h_length=16).|
+|                  | Else error.             | Else error.             |
++------------------+-------------------------+-------------------------+
+
+   It is expected that when a typical naive application that calls
+   gethostbyname() today is modified to use IPv6, it simply changes the
+   program to use IPv6 sockets and then enables the RES_USE_INET6
+   resolver option before calling gethostbyname().  This application
+   will then work with either IPv4 or IPv6 peers.
+
+   Note that gethostbyname() and gethostbyname2() are not thread-safe,
+   since both return a pointer to a static hostent structure.  But
+   several vendors have defined a thread-safe gethostbyname_r() function
+   that requires four additional arguments.  We expect these vendors to
+   also define a gethostbyname2_r() function.
+
+
+
+
+
+
+
+
+
+
+Gilligan, et. al.            Informational                     [Page 21]
+
+RFC 2133            IPv6 Socket Interface Extensions          April 1997
+
+
+6.2.  Address To Hostname Translation
+
+   The existing gethostbyaddr() function already requires an address
+   family argument and can therefore work with IPv6 addresses:
+
+       #include <sys/socket.h>
+       #include <netdb.h>
+
+       struct hostent *gethostbyaddr(const char *src, int len, int af);
+
+   One possible source of confusion is the handling of IPv4-mapped IPv6
+   addresses and IPv4-compatible IPv6 addresses.  This is addressed in
+   [6] and involves the following logic:
+
+    1.  If af is AF_INET6, and if len equals 16, and if the IPv6 address
+        is an IPv4-mapped IPv6 address or an IPv4-compatible IPv6
+        address, then skip over the first 12 bytes of the IPv6 address,
+        set af to AF_INET, and set len to 4.
+
+    2.  If af is AF_INET, then query for a PTR record in the in-
+        addr.arpa domain.
+
+    3.  If af is AF_INET6, then query for a PTR record in the ip6.int
+        domain.
+
+    4.  If the function is returning success, and if af equals AF_INET,
+        and if the RES_USE_INET6 option was set, then the single address
+        that is returned in the hostent structure (a copy of the first
+        argument to the function) is returned as an IPv4-mapped IPv6
+        address and the h_length member is set to 16.
+
+   All four steps listed are performed, in order.  The same caveats
+   regarding a thread-safe version of gethostbyname() that were made at
+   the end of the previous section apply here as well.
+
+6.3.  Protocol-Independent Hostname and Service Name Translation
+
+   Hostname-to-address translation is done in a protocol-independent
+   fashion using the getaddrinfo() function that is taken from the
+   Institute of Electrical and Electronic Engineers (IEEE) POSIX 1003.1g
+   (Protocol Independent Interfaces) work in progress specification [4].
+
+   The official specification for this function will be the final POSIX
+   standard.  We are providing this independent description of the
+   function because POSIX standards are not freely available (as are
+   IETF documents).  Should there be any discrepancies between this
+   description and the POSIX description, the POSIX description takes
+   precedence.
+
+
+
+Gilligan, et. al.            Informational                     [Page 22]
+
+RFC 2133            IPv6 Socket Interface Extensions          April 1997
+
+
+       #include <sys/socket.h>
+       #include <netdb.h>
+
+       int getaddrinfo(const char *hostname, const char *servname,
+                       const struct addrinfo *hints,
+                       struct addrinfo **res);
+
+   The addrinfo structure is defined as:
+
+       #include <sys/socket.h>
+       #include <netdb.h>
+
+       struct addrinfo {
+         int     ai_flags;     /* AI_PASSIVE, AI_CANONNAME */
+         int     ai_family;    /* PF_xxx */
+         int     ai_socktype;  /* SOCK_xxx */
+         int     ai_protocol;  /* 0 or IPPROTO_xxx for IPv4 and IPv6 */
+         size_t  ai_addrlen;   /* length of ai_addr */
+         char   *ai_canonname; /* canonical name for hostname */
+         struct sockaddr  *ai_addr; /* binary address */
+         struct addrinfo  *ai_next; /* next structure in linked list */
+       };
+
+   The return value from the function is 0 upon success or a nonzero
+   error code.  The following names are the nonzero error codes from
+   getaddrinfo(), and are defined in <netdb.h>:
+
+       EAI_ADDRFAMILY  address family for hostname not supported
+       EAI_AGAIN       temporary failure in name resolution
+       EAI_BADFLAGS    invalid value for ai_flags
+       EAI_FAIL        non-recoverable failure in name resolution
+       EAI_FAMILY      ai_family not supported
+       EAI_MEMORY      memory allocation failure
+       EAI_NODATA      no address associated with hostname
+       EAI_NONAME      hostname nor servname provided, or not known
+       EAI_SERVICE     servname not supported for ai_socktype
+       EAI_SOCKTYPE    ai_socktype not supported
+       EAI_SYSTEM      system error returned in errno
+
+   The hostname and servname arguments are pointers to null-terminated
+   strings or NULL.  One or both of these two arguments must be a non-
+   NULL pointer.  In the normal client scenario, both the hostname and
+   servname are specified.  In the normal server scenario, only the
+   servname is specified.  A non-NULL hostname string can be either a
+   host name or a numeric host address string (i.e., a dotted-decimal
+   IPv4 address or an IPv6 hex address).  A non-NULL servname string can
+   be either a service name or a decimal port number.
+
+
+
+
+Gilligan, et. al.            Informational                     [Page 23]
+
+RFC 2133            IPv6 Socket Interface Extensions          April 1997
+
+
+   The caller can optionally pass an addrinfo structure, pointed to by
+   the third argument, to provide hints concerning the type of socket
+   that the caller supports.  In this hints structure all members other
+   than ai_flags, ai_family, ai_socktype, and ai_protocol must be zero
+   or a NULL pointer.  A value of PF_UNSPEC for ai_family means the
+   caller will accept any protocol family.  A value of 0 for ai_socktype
+   means the caller will accept any socket type.  A value of 0 for
+   ai_protocol means the caller will accept any protocol.  For example,
+   if the caller handles only TCP and not UDP, then the ai_socktype
+   member of the hints structure should be set to SOCK_STREAM when
+   getaddrinfo() is called.  If the caller handles only IPv4 and not
+   IPv6, then the ai_family member of the hints structure should be set
+   to PF_INET when getaddrinfo() is called.  If the third argument to
+   getaddrinfo() is a NULL pointer, this is the same as if the caller
+   had filled in an addrinfo structure initialized to zero with
+   ai_family set to PF_UNSPEC.
+
+   Upon successful return a pointer to a linked list of one or more
+   addrinfo structures is returned through the final argument.  The
+   caller can process each addrinfo structure in this list by following
+   the ai_next pointer, until a NULL pointer is encountered.  In each
+   returned addrinfo structure the three members ai_family, ai_socktype,
+   and ai_protocol are the corresponding arguments for a call to the
+   socket() function.  In each addrinfo structure the ai_addr member
+   points to a filled-in socket address structure whose length is
+   specified by the ai_addrlen member.
+
+   If the AI_PASSIVE bit is set in the ai_flags member of the hints
+   structure, then the caller plans to use the returned socket address
+   structure in a call to bind().  In this case, if the hostname
+   argument is a NULL pointer, then the IP address portion of the socket
+   address structure will be set to INADDR_ANY for an IPv4 address or
+   IN6ADDR_ANY_INIT for an IPv6 address.
+
+   If the AI_PASSIVE bit is not set in the ai_flags member of the hints
+   structure, then the returned socket address structure will be ready
+   for a call to connect() (for a connection-oriented protocol) or
+   either connect(), sendto(), or sendmsg() (for a connectionless
+   protocol).  In this case, if the hostname argument is a NULL pointer,
+   then the IP address portion of the socket address structure will be
+   set to the loopback address.
+
+   If the AI_CANONNAME bit is set in the ai_flags member of the hints
+   structure, then upon successful return the ai_canonname member of the
+   first addrinfo structure in the linked list will point to a null-
+   terminated string containing the canonical name of the specified
+   hostname.
+
+
+
+
+Gilligan, et. al.            Informational                     [Page 24]
+
+RFC 2133            IPv6 Socket Interface Extensions          April 1997
+
+
+   All of the information returned by getaddrinfo() is dynamically
+   allocated: the addrinfo structures, and the socket address structures
+   and canonical host name strings pointed to by the addrinfo
+   structures.  To return this information to the system the function
+   freeaddrinfo() is called:
+
+       #include <sys/socket.h>
+       #include <netdb.h>
+
+       void freeaddrinfo(struct addrinfo *ai);
+
+   The addrinfo structure pointed to by the ai argument is freed, along
+   with any dynamic storage pointed to by the structure.  This operation
+   is repeated until a NULL ai_next pointer is encountered.
+
+   To aid applications in printing error messages based on the EAI_xxx
+   codes returned by getaddrinfo(), the following function is defined.
+
+       #include <sys/socket.h>
+       #include <netdb.h>
+
+       char *gai_strerror(int ecode);
+
+   The argument is one of the EAI_xxx values defined earlier and the
+   eturn value points to a string describing the error.  If the argument
+   is not one of the EAI_xxx values, the function still returns a
+   pointer to a string whose contents indicate an unknown error.
+
+6.4.  Socket Address Structure to Hostname and Service Name
+
+   The POSIX 1003.1g specification includes no function to perform the
+   reverse conversion from getaddrinfo():  to look up a hostname and
+   service name, given the binary address and port.  Therefore, we
+   define the following function:
+
+       #include <sys/socket.h>
+       #include <netdb.h>
+
+       int getnameinfo(const struct sockaddr *sa, size_t salen,
+                       char *host, size_t hostlen,
+                       char *serv, size_t servlen,
+                       int flags);
+
+   This function looks up an IP address and port number provided by the
+   caller in the DNS and system-specific database, and returns text
+   strings for both in buffers provided by the caller.  The function
+   indicates successful completion by a zero return value; a non-zero
+   return value indicates failure.
+
+
+
+Gilligan, et. al.            Informational                     [Page 25]
+
+RFC 2133            IPv6 Socket Interface Extensions          April 1997
+
+
+   The first argument, sa, points to either a sockaddr_in structure (for
+   IPv4) or a sockaddr_in6 structure (for IPv6) that holds the IP
+   address and port number.  The salen argument gives the length of the
+   sockaddr_in or sockaddr_in6 structure.
+
+   The function returns the hostname associated with the IP address in
+   the buffer pointed to by the host argument.  The caller provides the
+   size of this buffer via the hostlen argument.  The service name
+   associated with the port number is returned in the buffer pointed to
+   by serv, and the servlen argument gives the length of this buffer.
+   The caller specifies not to return either string by providing a zero
+   value for the hostlen or servlen arguments.  Otherwise, the caller
+   must provide buffers large enough to hold the hostname and the
+   service name, including the terminating null characters.
+
+   Unfortunately most systems do not provide constants that specify the
+   maximum size of either a fully-qualified domain name or a service
+   name.  Therefore to aid the application in allocating buffers for
+   these two returned strings the following constants are defined in
+   <netdb.h>:
+
+       #define NI_MAXHOST  1025
+       #define NI_MAXSERV    32
+
+   The first value is actually defined as the constant MAXDNAME in
+   recent versions of BIND's <arpa/nameser.h> header (older versions of
+   BIND define this constant to be 256) and the second is a guess based
+   on the services listed in the current Assigned Numbers RFC.
+
+   The final argument is a flag that changes the default actions of this
+   function.  By default the fully-qualified domain name (FQDN) for the
+   host is looked up in the DNS and returned.  If the flag bit NI_NOFQDN
+   is set, only the hostname portion of the FQDN is returned for local
+   hosts.
+
+   If the flag bit NI_NUMERICHOST is set, or if the host's name cannot
+   be located in the DNS, the numeric form of the host's address is
+   returned instead of its name (e.g., by calling inet_ntop() instead of
+   gethostbyaddr()).  If the flag bit NI_NAMEREQD is set, an error is
+   returned if the host's name cannot be located in the DNS.
+
+   If the flag bit NI_NUMERICSERV is set, the numeric form of the
+   service address is returned (e.g., its port number) instead of its
+   name.  The two NI_NUMERICxxx flags are required to support the "-n"
+   flag that many commands provide.
+
+
+
+
+
+
+Gilligan, et. al.            Informational                     [Page 26]
+
+RFC 2133            IPv6 Socket Interface Extensions          April 1997
+
+
+   A fifth flag bit, NI_DGRAM, specifies that the service is a datagram
+   service, and causes getservbyport() to be called with a second
+   argument of "udp" instead of its default of "tcp".  This is required
+   for the few ports (512-514) that have different services for UDP and
+   TCP.
+
+   These NI_xxx flags are defined in <netdb.h> along with the AI_xxx
+   flags already defined for getaddrinfo().
+
+6.5.  Address Conversion Functions
+
+   The two functions inet_addr() and inet_ntoa() convert an IPv4 address
+   between binary and text form.  IPv6 applications need similar
+   functions.  The following two functions convert both IPv6 and IPv4
+   addresses:
+
+       #include <sys/socket.h>
+       #include <arpa/inet.h>
+
+       int inet_pton(int af, const char *src, void *dst);
+
+       const char *inet_ntop(int af, const void *src,
+                             char *dst, size_t size);
+
+   The inet_pton() function converts an address in its standard text
+   presentation form into its numeric binary form.  The af argument
+   specifies the family of the address.  Currently the AF_INET and
+   AF_INET6 address families are supported.  The src argument points to
+   the string being passed in.  The dst argument points to a buffer into
+   which the function stores the numeric address.  The address is
+   returned in network byte order.  Inet_pton() returns 1 if the
+   conversion succeeds, 0 if the input is not a valid IPv4 dotted-
+   decimal string or a valid IPv6 address string, or -1 with errno set
+   to EAFNOSUPPORT if the af argument is unknown.  The calling
+   application must ensure that the buffer referred to by dst is large
+   enough to hold the numeric address (e.g., 4 bytes for AF_INET or 16
+   bytes for AF_INET6).
+
+   If the af argument is AF_INET, the function accepts a string in the
+   standard IPv4 dotted-decimal form:
+
+       ddd.ddd.ddd.ddd
+
+   where ddd is a one to three digit decimal number between 0 and 255.
+   Note that many implementations of the existing inet_addr() and
+   inet_aton() functions accept nonstandard input:  octal numbers,
+   hexadecimal numbers, and fewer than four numbers.  inet_pton() does
+   not accept these formats.
+
+
+
+Gilligan, et. al.            Informational                     [Page 27]
+
+RFC 2133            IPv6 Socket Interface Extensions          April 1997
+
+
+   If the af argument is AF_INET6, then the function accepts a string in
+   one of the standard IPv6 text forms defined in Section 2.2 of the
+   addressing architecture specification [2].
+
+   The inet_ntop() function converts a numeric address into a text
+   string suitable for presentation.  The af argument specifies the
+   family of the address.  This can be AF_INET or AF_INET6.  The src
+   argument points to a buffer holding an IPv4 address if the af
+   argument is AF_INET, or an IPv6 address if the af argument is
+   AF_INET6.  The dst argument points to a buffer where the function
+   will store the resulting text string.  The size argument specifies
+   the size of this buffer.  The application must specify a non-NULL dst
+   argument.  For IPv6 addresses, the buffer must be at least 46-octets.
+   For IPv4 addresses, the buffer must be at least 16-octets.  In order
+   to allow applications to easily declare buffers of the proper size to
+   store IPv4 and IPv6 addresses in string form, the following two
+   constants are defined in <netinet/in.h>:
+
+       #define INET_ADDRSTRLEN    16
+       #define INET6_ADDRSTRLEN   46
+
+   The inet_ntop() function returns a pointer to the buffer containing
+   the text string if the conversion succeeds, and NULL otherwise.  Upon
+   failure, errno is set to EAFNOSUPPORT if the af argument is invalid
+   or ENOSPC if the size of the result buffer is inadequate.
+
+6.6.  Address Testing Macros
+
+   The following macros can be used to test for special IPv6 addresses.
+
+       #include <netinet/in.h>
+
+       int  IN6_IS_ADDR_UNSPECIFIED (const struct in6_addr *);
+       int  IN6_IS_ADDR_LOOPBACK    (const struct in6_addr *);
+       int  IN6_IS_ADDR_MULTICAST   (const struct in6_addr *);
+       int  IN6_IS_ADDR_LINKLOCAL   (const struct in6_addr *);
+       int  IN6_IS_ADDR_SITELOCAL   (const struct in6_addr *);
+       int  IN6_IS_ADDR_V4MAPPED    (const struct in6_addr *);
+       int  IN6_IS_ADDR_V4COMPAT    (const struct in6_addr *);
+
+       int  IN6_IS_ADDR_MC_NODELOCAL(const struct in6_addr *);
+       int  IN6_IS_ADDR_MC_LINKLOCAL(const struct in6_addr *);
+       int  IN6_IS_ADDR_MC_SITELOCAL(const struct in6_addr *);
+       int  IN6_IS_ADDR_MC_ORGLOCAL (const struct in6_addr *);
+       int  IN6_IS_ADDR_MC_GLOBAL   (const struct in6_addr *);
+
+
+
+
+
+
+Gilligan, et. al.            Informational                     [Page 28]
+
+RFC 2133            IPv6 Socket Interface Extensions          April 1997
+
+
+   The first seven macros return true if the address is of the specified
+   type, or false otherwise.  The last five test the scope of a
+   multicast address and return true if the address is a multicast
+   address of the specified scope or false if the address is either not
+   a multicast address or not of the specified scope.
+
+7.  Summary of New Definitions
+
+   The following list summarizes the constants, structure, and extern
+   definitions discussed in this memo, sorted by header.
+
+     <net/if.h>      IFNAMSIZ
+     <net/if.h>      struct if_nameindex{};
+
+     <netdb.h>       AI_CANONNAME
+     <netdb.h>       AI_PASSIVE
+     <netdb.h>       EAI_ADDRFAMILY
+     <netdb.h>       EAI_AGAIN
+     <netdb.h>       EAI_BADFLAGS
+     <netdb.h>       EAI_FAIL
+     <netdb.h>       EAI_FAMILY
+     <netdb.h>       EAI_MEMORY
+     <netdb.h>       EAI_NODATA
+     <netdb.h>       EAI_NONAME
+     <netdb.h>       EAI_SERVICE
+     <netdb.h>       EAI_SOCKTYPE
+     <netdb.h>       EAI_SYSTEM
+     <netdb.h>       NI_DGRAM
+     <netdb.h>       NI_MAXHOST
+     <netdb.h>       NI_MAXSERV
+     <netdb.h>       NI_NAMEREQD
+     <netdb.h>       NI_NOFQDN
+     <netdb.h>       NI_NUMERICHOST
+     <netdb.h>       NI_NUMERICSERV
+     <netdb.h>       struct addrinfo{};
+
+     <netinet/in.h>  IN6ADDR_ANY_INIT
+     <netinet/in.h>  IN6ADDR_LOOPBACK_INIT
+     <netinet/in.h>  INET6_ADDRSTRLEN
+     <netinet/in.h>  INET_ADDRSTRLEN
+     <netinet/in.h>  IPPROTO_IPV6
+     <netinet/in.h>  IPV6_ADDRFORM
+     <netinet/in.h>  IPV6_ADD_MEMBERSHIP
+     <netinet/in.h>  IPV6_DROP_MEMBERSHIP
+     <netinet/in.h>  IPV6_MULTICAST_HOPS
+     <netinet/in.h>  IPV6_MULTICAST_IF
+     <netinet/in.h>  IPV6_MULTICAST_LOOP
+     <netinet/in.h>  IPV6_UNICAST_HOPS
+
+
+
+Gilligan, et. al.            Informational                     [Page 29]
+
+RFC 2133            IPv6 Socket Interface Extensions          April 1997
+
+
+     <netinet/in.h>  SIN6_LEN
+     <netinet/in.h>  extern const struct in6_addr in6addr_any;
+     <netinet/in.h>  extern const struct in6_addr in6addr_loopback;
+     <netinet/in.h>  struct in6_addr{};
+     <netinet/in.h>  struct ipv6_mreq{};
+     <netinet/in.h>  struct sockaddr_in6{};
+
+     <resolv.h>      RES_USE_INET6
+
+     <sys/socket.h>  AF_INET6
+     <sys/socket.h>  PF_INET6
+
+
+   The following list summarizes the function and macro prototypes
+   discussed in this memo, sorted by header.
+
+<arpa/inet.h>   int inet_pton(int, const char *, void *);
+<arpa/inet.h>   const char *inet_ntop(int, const void *,
+                                      char *, size_t);
+
+<net/if.h>      char *if_indextoname(unsigned int, char *);
+<net/if.h>      unsigned int if_nametoindex(const char *);
+<net/if.h>      void if_freenameindex(struct if_nameindex *);
+<net/if.h>      struct if_nameindex *if_nameindex(void);
+
+<netdb.h>       int getaddrinfo(const char *, const char *,
+                                const struct addrinfo *,
+                                struct addrinfo **);
+<netdb.h>       int getnameinfo(const struct sockaddr *, size_t,
+                                char *, size_t, char *, size_t, int);
+<netdb.h>       void freeaddrinfo(struct addrinfo *);
+<netdb.h>       char *gai_strerror(int);
+<netdb.h>       struct hostent *gethostbyname(const char *);
+<netdb.h>       struct hostent *gethostbyaddr(const char *, int, int);
+<netdb.h>       struct hostent *gethostbyname2(const char *, int);
+
+<netinet/in.h>  int IN6_IS_ADDR_LINKLOCAL(const struct in6_addr *);
+<netinet/in.h>  int IN6_IS_ADDR_LOOPBACK(const struct in6_addr *);
+<netinet/in.h>  int IN6_IS_ADDR_MC_GLOBAL(const struct in6_addr *);
+<netinet/in.h>  int IN6_IS_ADDR_MC_LINKLOCAL(const struct in6_addr *);
+<netinet/in.h>  int IN6_IS_ADDR_MC_NODELOCAL(const struct in6_addr *);
+<netinet/in.h>  int IN6_IS_ADDR_MC_ORGLOCAL(const struct in6_addr *);
+<netinet/in.h>  int IN6_IS_ADDR_MC_SITELOCAL(const struct in6_addr *);
+<netinet/in.h>  int IN6_IS_ADDR_MULTICAST(const struct in6_addr *);
+<netinet/in.h>  int IN6_IS_ADDR_SITELOCAL(const struct in6_addr *);
+<netinet/in.h>  int IN6_IS_ADDR_UNSPECIFIED(const struct in6_addr *);
+<netinet/in.h>  int IN6_IS_ADDR_V4COMPAT(const struct in6_addr *);
+<netinet/in.h>  int IN6_IS_ADDR_V4MAPPED(const struct in6_addr *);
+
+
+
+Gilligan, et. al.            Informational                     [Page 30]
+
+RFC 2133            IPv6 Socket Interface Extensions          April 1997
+
+
+8.  Security Considerations
+
+   IPv6 provides a number of new security mechanisms, many of which need
+   to be accessible to applications.  A companion memo detailing the
+   extensions to the socket interfaces to support IPv6 security is being
+   written [3].
+
+9.  Acknowledgments
+
+   Thanks to the many people who made suggestions and provided feedback
+   to to the numerous revisions of this document, including: Werner
+   Almesberger, Ran Atkinson, Fred Baker, Dave Borman, Andrew Cherenson,
+   Alex Conta, Alan Cox, Steve Deering, Richard Draves, Francis Dupont,
+   Robert Elz, Marc Hasson, Tim Hartrick, Tom Herbert, Bob Hinden, Wan-
+   Yen Hsu, Christian Huitema, Koji Imada, Markus Jork, Ron Lee, Alan
+   Lloyd, Charles Lynn, Jack McCann, Dan McDonald, Dave Mitton, Thomas
+   Narten, Erik Nordmark, Josh Osborne, Craig Partridge, Jean-Luc
+   Richier, Erik Scoredos, Keith Sklower, Matt Thomas, Harvey Thompson,
+   Dean D. Throop, Karen Tracey, Glenn Trewitt, Paul Vixie, David
+   Waitzman, Carl Williams, and Kazuhiko Yamamoto,
+
+   The getaddrinfo() and getnameinfo() functions are taken from an
+   earlier Work in Progress by Keith Sklower.  As noted in that
+   document, William Durst, Steven Wise, Michael Karels, and Eric Allman
+   provided many useful discussions on the subject of protocol-
+   independent name-to-address translation, and reviewed early versions
+   of Keith Sklower's original proposal.  Eric Allman implemented the
+   first prototype of getaddrinfo().  The observation that specifying
+   the pair of name and service would suffice for connecting to a
+   service independent of protocol details was made by Marshall Rose in
+   a proposal to X/Open for a "Uniform Network Interface".
+
+   Craig Metz made many contributions to this document.  Ramesh Govindan
+   made a number of contributions and co-authored an earlier version of
+   this memo.
+
+10.  References
+
+   [1] Deering, S., and R. Hinden, "Internet Protocol, Version 6 (IPv6)
+       Specification", RFC 1883, December 1995.
+
+   [2] Hinden, R., and S. Deering, "IP Version 6 Addressing Architecture",
+       RFC 1884, December 1995.
+
+   [3] McDonald, D., "A Simple IP Security API Extension to BSD Sockets",
+       Work in Progress.
+
+
+
+
+
+Gilligan, et. al.            Informational                     [Page 31]
+
+RFC 2133            IPv6 Socket Interface Extensions          April 1997
+
+
+   [4] IEEE, "Protocol Independent Interfaces", IEEE Std 1003.1g, DRAFT
+       6.3, November 1995.
+
+   [5] Stevens, W., and M. Thomas, "Advanced Sockets API for IPv6",
+       Work in Progress.
+
+   [6] Vixie, P., "Reverse Name Lookups of Encapsulated IPv4 Addresses in
+       IPv6", Work in Progress.
+
+11.  Authors' Addresses
+
+    Robert E. Gilligan
+    Freegate Corporation
+    710 Lakeway Dr.  STE 230
+    Sunnyvale, CA 94086
+
+    Phone: +1 408 524 4804
+    EMail: gilligan@freegate.net
+
+
+    Susan Thomson
+    Bell Communications Research
+    MRE 2P-343, 445 South Street
+    Morristown, NJ 07960
+
+    Phone: +1 201 829 4514
+    EMail: set@thumper.bellcore.com
+
+
+    Jim Bound
+    Digital Equipment Corporation
+    110 Spitbrook Road ZK3-3/U14
+    Nashua, NH 03062-2698
+
+    Phone: +1 603 881 0400
+    Email: bound@zk3.dec.com
+
+
+    W. Richard Stevens
+    1202 E. Paseo del Zorro
+    Tucson, AZ 85718-2826
+
+    Phone: +1 520 297 9416
+    EMail: rstevens@kohala.com
+
+
+
+
+
+
+
+Gilligan, et. al.            Informational                     [Page 32]
+
diff --git a/doc/rfc/rfc2136.txt b/doc/rfc/rfc2136.txt
new file mode 100644
index 0000000..4d62702
--- /dev/null
+++ b/doc/rfc/rfc2136.txt
@@ -0,0 +1,1460 @@
+
+
+
+
+
+
+Network Working Group                                  P. Vixie, Editor
+Request for Comments: 2136                                          ISC
+Updates: 1035                                                S. Thomson
+Category: Standards Track                                      Bellcore
+                                                             Y. Rekhter
+                                                                  Cisco
+                                                               J. Bound
+                                                                    DEC
+                                                             April 1997
+
+         Dynamic Updates in the Domain Name System (DNS UPDATE)
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Abstract
+
+   The Domain Name System was originally designed to support queries of
+   a statically configured database.  While the data was expected to
+   change, the frequency of those changes was expected to be fairly low,
+   and all updates were made as external edits to a zone's Master File.
+
+   Using this specification of the UPDATE opcode, it is possible to add
+   or delete RRs or RRsets from a specified zone.  Prerequisites are
+   specified separately from update operations, and can specify a
+   dependency upon either the previous existence or nonexistence of an
+   RRset, or the existence of a single RR.
+
+   UPDATE is atomic, i.e., all prerequisites must be satisfied or else
+   no update operations will take place.  There are no data dependent
+   error conditions defined after the prerequisites have been met.
+
+1 - Definitions
+
+   This document intentionally gives more definition to the roles of
+   "Master," "Slave," and "Primary Master" servers, and their
+   enumeration in NS RRs, and the SOA MNAME field.  In that sense, the
+   following server type definitions can be considered an addendum to
+   [RFC1035], and are intended to be consistent with [RFC1996]:
+
+      Slave           an authoritative server that uses AXFR or IXFR to
+                      retrieve the zone and is named in the zone's NS
+                      RRset.
+
+
+
+Vixie, et. al.              Standards Track                     [Page 1]
+
+RFC 2136                       DNS Update                     April 1997
+
+
+      Master          an authoritative server configured to be the
+                      source of AXFR or IXFR data for one or more slave
+                      servers.
+
+      Primary Master  master server at the root of the AXFR/IXFR
+                      dependency graph.  The primary master is named in
+                      the zone's SOA MNAME field and optionally by an NS
+                      RR.  There is by definition only one primary master
+                      server per zone.
+
+   A domain name identifies a node within the domain name space tree
+   structure.  Each node has a set (possibly empty) of Resource Records
+   (RRs).  All RRs having the same NAME, CLASS and TYPE are called a
+   Resource Record Set (RRset).
+
+   The pseudocode used in this document is for example purposes only.
+   If it is found to disagree with the text, the text shall be
+   considered authoritative.  If the text is found to be ambiguous, the
+   pseudocode can be used to help resolve the ambiguity.
+
+   1.1 - Comparison Rules
+
+   1.1.1. Two RRs are considered equal if their NAME, CLASS, TYPE,
+   RDLENGTH and RDATA fields are equal.  Note that the time-to-live
+   (TTL) field is explicitly excluded from the comparison.
+
+   1.1.2. The rules for comparison of character strings in names are
+   specified in [RFC1035 2.3.3].
+
+   1.1.3. Wildcarding is disabled.  That is, a wildcard ("*") in an
+   update only matches a wildcard ("*") in the zone, and vice versa.
+
+   1.1.4. Aliasing is disabled: A CNAME in the zone matches a CNAME in
+   the update, and will not otherwise be followed.  All UPDATE
+   operations are done on the basis of canonical names.
+
+   1.1.5. The following RR types cannot be appended to an RRset.  If the
+   following comparison rules are met, then an attempt to add the new RR
+   will result in the replacement of the previous RR:
+
+      SOA    compare only NAME, CLASS and TYPE -- it is not possible to
+             have more than one SOA per zone, even if any of the data
+             fields differ.
+
+      WKS    compare only NAME, CLASS, TYPE, ADDRESS, and PROTOCOL
+             -- only one WKS RR is possible for this tuple, even if the
+             services masks differ.
+
+
+
+
+Vixie, et. al.              Standards Track                     [Page 2]
+
+RFC 2136                       DNS Update                     April 1997
+
+
+      CNAME  compare only NAME, CLASS, and TYPE -- it is not possible
+             to have more than one CNAME RR, even if their data fields
+             differ.
+
+   1.2 - Glue RRs
+
+   For the purpose of determining whether a domain name used in the
+   UPDATE protocol is contained within a specified zone, a domain name
+   is "in" a zone if it is owned by that zone's domain name.  See
+   section 7.18 for details.
+
+   1.3 - New Assigned Numbers
+
+      CLASS = NONE (254)
+      RCODE = YXDOMAIN (6)
+      RCODE = YXRRSET (7)
+      RCODE = NXRRSET (8)
+      RCODE = NOTAUTH (9)
+      RCODE = NOTZONE (10)
+      Opcode = UPDATE (5)
+
+2 - Update Message Format
+
+   The DNS Message Format is defined by [RFC1035 4.1].  Some extensions
+   are necessary (for example, more error codes are possible under
+   UPDATE than under QUERY) and some fields must be overloaded (see
+   description of CLASS fields below).
+
+   The overall format of an UPDATE message is, following [ibid]:
+
+      +---------------------+
+      |        Header       |
+      +---------------------+
+      |         Zone        | specifies the zone to be updated
+      +---------------------+
+      |     Prerequisite    | RRs or RRsets which must (not) preexist
+      +---------------------+
+      |        Update       | RRs or RRsets to be added or deleted
+      +---------------------+
+      |   Additional Data   | additional data
+      +---------------------+
+
+
+
+
+
+
+
+
+
+
+Vixie, et. al.              Standards Track                     [Page 3]
+
+RFC 2136                       DNS Update                     April 1997
+
+
+   The Header Section specifies that this message is an UPDATE, and
+   describes the size of the other sections.  The Zone Section names the
+   zone that is to be updated by this message.  The Prerequisite Section
+   specifies the starting invariants (in terms of zone content) required
+   for this update.  The Update Section contains the edits to be made,
+   and the Additional Data Section contains data which may be necessary
+   to complete, but is not part of, this update.
+
+   2.1 - Transport Issues
+
+   An update transaction may be carried in a UDP datagram, if the
+   request fits, or in a TCP connection (at the discretion of the
+   requestor).  When TCP is used, the message is in the format described
+   in [RFC1035 4.2.2].
+
+   2.2 - Message Header
+
+   The header of the DNS Message Format is defined by [RFC 1035 4.1].
+   Not all opcodes define the same set of flag bits, though as a
+   practical matter most of the bits defined for QUERY (in [ibid]) are
+   identically defined by the other opcodes.  UPDATE uses only one flag
+   bit (QR).
+
+   The DNS Message Format specifies record counts for its four sections
+   (Question, Answer, Authority, and Additional).  UPDATE uses the same
+   fields, and the same section formats, but the naming and use of these
+   sections differs as shown in the following modified header, after
+   [RFC1035 4.1.1]:
+
+                                      1  1  1  1  1  1
+        0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
+      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+      |                      ID                       |
+      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+      |QR|   Opcode  |          Z         |   RCODE   |
+      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+      |                    ZOCOUNT                    |
+      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+      |                    PRCOUNT                    |
+      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+      |                    UPCOUNT                    |
+      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+      |                    ADCOUNT                    |
+      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+
+
+
+
+
+
+Vixie, et. al.              Standards Track                     [Page 4]
+
+RFC 2136                       DNS Update                     April 1997
+
+
+   These fields are used as follows:
+
+   ID      A 16-bit identifier assigned by the entity that generates any
+           kind of request.  This identifier is copied in the
+           corresponding reply and can be used by the requestor to match
+           replies to outstanding requests, or by the server to detect
+           duplicated requests from some requestor.
+
+   QR      A one bit field that specifies whether this message is a
+           request (0), or a response (1).
+
+   Opcode  A four bit field that specifies the kind of request in this
+           message.  This value is set by the originator of a request
+           and copied into the response.  The Opcode value that
+           identifies an UPDATE message is five (5).
+
+   Z       Reserved for future use.  Should be zero (0) in all requests
+           and responses.  A non-zero Z field should be ignored by
+           implementations of this specification.
+
+   RCODE   Response code - this four bit field is undefined in requests
+           and set in responses.  The values and meanings of this field
+           within responses are as follows:
+
+              Mneumonic   Value   Description
+              ------------------------------------------------------------
+              NOERROR     0       No error condition.
+              FORMERR     1       The name server was unable to interpret
+                                  the request due to a format error.
+              SERVFAIL    2       The name server encountered an internal
+                                  failure while processing this request,
+                                  for example an operating system error
+                                  or a forwarding timeout.
+              NXDOMAIN    3       Some name that ought to exist,
+                                  does not exist.
+              NOTIMP      4       The name server does not support
+                                  the specified Opcode.
+              REFUSED     5       The name server refuses to perform the
+                                  specified operation for policy or
+                                  security reasons.
+              YXDOMAIN    6       Some name that ought not to exist,
+                                  does exist.
+              YXRRSET     7       Some RRset that ought not to exist,
+                                  does exist.
+              NXRRSET     8       Some RRset that ought to exist,
+                                  does not exist.
+
+
+
+
+
+Vixie, et. al.              Standards Track                     [Page 5]
+
+RFC 2136                       DNS Update                     April 1997
+
+
+              NOTAUTH     9       The server is not authoritative for
+                                  the zone named in the Zone Section.
+              NOTZONE     10      A name used in the Prerequisite or
+                                  Update Section is not within the
+                                  zone denoted by the Zone Section.
+
+   ZOCOUNT The number of RRs in the Zone Section.
+
+   PRCOUNT The number of RRs in the Prerequisite Section.
+
+   UPCOUNT The number of RRs in the Update Section.
+
+   ADCOUNT The number of RRs in the Additional Data Section.
+
+   2.3 - Zone Section
+
+   The Zone Section has the same format as that specified in [RFC1035
+   4.1.2], with the fields redefined as follows:
+
+                                      1  1  1  1  1  1
+        0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
+      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+      |                                               |
+      /                     ZNAME                     /
+      /                                               /
+      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+      |                     ZTYPE                     |
+      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+      |                     ZCLASS                    |
+      +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+   UPDATE uses this section to denote the zone of the records being
+   updated.  All records to be updated must be in the same zone, and
+   therefore the Zone Section is allowed to contain exactly one record.
+   The ZNAME is the zone name, the ZTYPE must be SOA, and the ZCLASS is
+   the zone's class.
+
+   2.4 - Prerequisite Section
+
+   This section contains a set of RRset prerequisites which must be
+   satisfied at the time the UPDATE packet is received by the primary
+   master server.  The format of this section is as specified by
+   [RFC1035 4.1.3].  There are five possible sets of semantics that can
+   be expressed here, summarized as follows and then explained below.
+
+      (1)  RRset exists (value independent).  At least one RR with a
+           specified NAME and TYPE (in the zone and class specified by
+           the Zone Section) must exist.
+
+
+
+Vixie, et. al.              Standards Track                     [Page 6]
+
+RFC 2136                       DNS Update                     April 1997
+
+
+      (2)  RRset exists (value dependent).  A set of RRs with a
+           specified NAME and TYPE exists and has the same members
+           with the same RDATAs as the RRset specified here in this
+           Section.
+
+      (3)  RRset does not exist.  No RRs with a specified NAME and TYPE
+          (in the zone and class denoted by the Zone Section) can exist.
+
+      (4)  Name is in use.  At least one RR with a specified NAME (in
+           the zone and class specified by the Zone Section) must exist.
+           Note that this prerequisite is NOT satisfied by empty
+           nonterminals.
+
+      (5)  Name is not in use.  No RR of any type is owned by a
+           specified NAME.  Note that this prerequisite IS satisfied by
+           empty nonterminals.
+
+   The syntax of these is as follows:
+
+   2.4.1 - RRset Exists (Value Independent)
+
+   At least one RR with a specified NAME and TYPE (in the zone and class
+   specified in the Zone Section) must exist.
+
+   For this prerequisite, a requestor adds to the section a single RR
+   whose NAME and TYPE are equal to that of the zone RRset whose
+   existence is required.  RDLENGTH is zero and RDATA is therefore
+   empty.  CLASS must be specified as ANY to differentiate this
+   condition from that of an actual RR whose RDLENGTH is naturally zero
+   (0) (e.g., NULL).  TTL is specified as zero (0).
+
+   2.4.2 - RRset Exists (Value Dependent)
+
+   A set of RRs with a specified NAME and TYPE exists and has the same
+   members with the same RDATAs as the RRset specified here in this
+   section.  While RRset ordering is undefined and therefore not
+   significant to this comparison, the sets be identical in their
+   extent.
+
+   For this prerequisite, a requestor adds to the section an entire
+   RRset whose preexistence is required.  NAME and TYPE are that of the
+   RRset being denoted.  CLASS is that of the zone.  TTL must be
+   specified as zero (0) and is ignored when comparing RRsets for
+   identity.
+
+
+
+
+
+
+
+Vixie, et. al.              Standards Track                     [Page 7]
+
+RFC 2136                       DNS Update                     April 1997
+
+
+   2.4.3 - RRset Does Not Exist
+
+   No RRs with a specified NAME and TYPE (in the zone and class denoted
+   by the Zone Section) can exist.
+
+   For this prerequisite, a requestor adds to the section a single RR
+   whose NAME and TYPE are equal to that of the RRset whose nonexistence
+   is required.  The RDLENGTH of this record is zero (0), and RDATA
+   field is therefore empty.  CLASS must be specified as NONE in order
+   to distinguish this condition from a valid RR whose RDLENGTH is
+   naturally zero (0) (for example, the NULL RR).  TTL must be specified
+   as zero (0).
+
+   2.4.4 - Name Is In Use
+
+   Name is in use.  At least one RR with a specified NAME (in the zone
+   and class specified by the Zone Section) must exist.  Note that this
+   prerequisite is NOT satisfied by empty nonterminals.
+
+   For this prerequisite, a requestor adds to the section a single RR
+   whose NAME is equal to that of the name whose ownership of an RR is
+   required.  RDLENGTH is zero and RDATA is therefore empty.  CLASS must
+   be specified as ANY to differentiate this condition from that of an
+   actual RR whose RDLENGTH is naturally zero (0) (e.g., NULL).  TYPE
+   must be specified as ANY to differentiate this case from that of an
+   RRset existence test.  TTL is specified as zero (0).
+
+   2.4.5 - Name Is Not In Use
+
+   Name is not in use.  No RR of any type is owned by a specified NAME.
+   Note that this prerequisite IS satisfied by empty nonterminals.
+
+   For this prerequisite, a requestor adds to the section a single RR
+   whose NAME is equal to that of the name whose nonownership of any RRs
+   is required.  RDLENGTH is zero and RDATA is therefore empty.  CLASS
+   must be specified as NONE.  TYPE must be specified as ANY.  TTL must
+   be specified as zero (0).
+
+   2.5 - Update Section
+
+   This section contains RRs to be added to or deleted from the zone.
+   The format of this section is as specified by [RFC1035 4.1.3].  There
+   are four possible sets of semantics, summarized below and with
+   details to follow.
+
+
+
+
+
+
+
+Vixie, et. al.              Standards Track                     [Page 8]
+
+RFC 2136                       DNS Update                     April 1997
+
+
+      (1) Add RRs to an RRset.
+      (2) Delete an RRset.
+      (3) Delete all RRsets from a name.
+      (4) Delete an RR from an RRset.
+
+   The syntax of these is as follows:
+
+   2.5.1 - Add To An RRset
+
+   RRs are added to the Update Section whose NAME, TYPE, TTL, RDLENGTH
+   and RDATA are those being added, and CLASS is the same as the zone
+   class.  Any duplicate RRs will be silently ignored by the primary
+   master.
+
+   2.5.2 - Delete An RRset
+
+   One RR is added to the Update Section whose NAME and TYPE are those
+   of the RRset to be deleted.  TTL must be specified as zero (0) and is
+   otherwise not used by the primary master.  CLASS must be specified as
+   ANY.  RDLENGTH must be zero (0) and RDATA must therefore be empty.
+   If no such RRset exists, then this Update RR will be silently ignored
+   by the primary master.
+
+   2.5.3 - Delete All RRsets From A Name
+
+   One RR is added to the Update Section whose NAME is that of the name
+   to be cleansed of RRsets.  TYPE must be specified as ANY.  TTL must
+   be specified as zero (0) and is otherwise not used by the primary
+   master.  CLASS must be specified as ANY.  RDLENGTH must be zero (0)
+   and RDATA must therefore be empty.  If no such RRsets exist, then
+   this Update RR will be silently ignored by the primary master.
+
+   2.5.4 - Delete An RR From An RRset
+
+   RRs to be deleted are added to the Update Section.  The NAME, TYPE,
+   RDLENGTH and RDATA must match the RR being deleted.  TTL must be
+   specified as zero (0) and will otherwise be ignored by the primary
+   master.  CLASS must be specified as NONE to distinguish this from an
+   RR addition.  If no such RRs exist, then this Update RR will be
+   silently ignored by the primary master.
+
+
+
+
+
+
+
+
+
+
+
+Vixie, et. al.              Standards Track                     [Page 9]
+
+RFC 2136                       DNS Update                     April 1997
+
+
+   2.6 - Additional Data Section
+
+   This section contains RRs which are related to the update itself, or
+   to new RRs being added by the update.  For example, out of zone glue
+   (A RRs referred to by new NS RRs) should be presented here.  The
+   server can use or ignore out of zone glue, at the discretion of the
+   server implementor.  The format of this section is as specified by
+   [RFC1035 4.1.3].
+
+3 - Server Behavior
+
+   A server, upon receiving an UPDATE request, will signal NOTIMP to the
+   requestor if the UPDATE opcode is not recognized or if it is
+   recognized but has not been implemented.  Otherwise, processing
+   continues as follows.
+
+   3.1 - Process Zone Section
+
+   3.1.1. The Zone Section is checked to see that there is exactly one
+   RR therein and that the RR's ZTYPE is SOA, else signal FORMERR to the
+   requestor.  Next, the ZNAME and ZCLASS are checked to see if the zone
+   so named is one of this server's authority zones, else signal NOTAUTH
+   to the requestor.  If the server is a zone slave, the request will be
+   forwarded toward the primary master.
+
+   3.1.2 - Pseudocode For Zone Section Processing
+
+      if (zcount != 1 || ztype != SOA)
+           return (FORMERR)
+      if (zone_type(zname, zclass) == SLAVE)
+           return forward()
+      if (zone_type(zname, zclass) == MASTER)
+           return update()
+      return (NOTAUTH)
+
+   Sections 3.2 through 3.8 describe the primary master's behaviour,
+   whereas Section 6 describes a forwarder's behaviour.
+
+   3.2 - Process Prerequisite Section
+
+   Next, the Prerequisite Section is checked to see that all
+   prerequisites are satisfied by the current state of the zone.  Using
+   the definitions expressed in Section 1.2, if any RR's NAME is not
+   within the zone specified in the Zone Section, signal NOTZONE to the
+   requestor.
+
+
+
+
+
+
+Vixie, et. al.              Standards Track                    [Page 10]
+
+RFC 2136                       DNS Update                     April 1997
+
+
+   3.2.1. For RRs in this section whose CLASS is ANY, test to see that
+   TTL and RDLENGTH are both zero (0), else signal FORMERR to the
+   requestor.  If TYPE is ANY, test to see that there is at least one RR
+   in the zone whose NAME is the same as that of the Prerequisite RR,
+   else signal NXDOMAIN to the requestor.  If TYPE is not ANY, test to
+   see that there is at least one RR in the zone whose NAME and TYPE are
+   the same as that of the Prerequisite RR, else signal NXRRSET to the
+   requestor.
+
+   3.2.2. For RRs in this section whose CLASS is NONE, test to see that
+   the TTL and RDLENGTH are both zero (0), else signal FORMERR to the
+   requestor.  If the TYPE is ANY, test to see that there are no RRs in
+   the zone whose NAME is the same as that of the Prerequisite RR, else
+   signal YXDOMAIN to the requestor.  If the TYPE is not ANY, test to
+   see that there are no RRs in the zone whose NAME and TYPE are the
+   same as that of the Prerequisite RR, else signal YXRRSET to the
+   requestor.
+
+   3.2.3. For RRs in this section whose CLASS is the same as the ZCLASS,
+   test to see that the TTL is zero (0), else signal FORMERR to the
+   requestor.  Then, build an RRset for each unique <NAME,TYPE> and
+   compare each resulting RRset for set equality (same members, no more,
+   no less) with RRsets in the zone.  If any Prerequisite RRset is not
+   entirely and exactly matched by a zone RRset, signal NXRRSET to the
+   requestor.  If any RR in this section has a CLASS other than ZCLASS
+   or NONE or ANY, signal FORMERR to the requestor.
+
+   3.2.4 - Table Of Metavalues Used In Prerequisite Section
+
+   CLASS    TYPE     RDATA    Meaning
+   ------------------------------------------------------------
+   ANY      ANY      empty    Name is in use
+   ANY      rrset    empty    RRset exists (value independent)
+   NONE     ANY      empty    Name is not in use
+   NONE     rrset    empty    RRset does not exist
+   zone     rrset    rr       RRset exists (value dependent)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Vixie, et. al.              Standards Track                    [Page 11]
+
+RFC 2136                       DNS Update                     April 1997
+
+
+   3.2.5 - Pseudocode for Prerequisite Section Processing
+
+      for rr in prerequisites
+           if (rr.ttl != 0)
+                return (FORMERR)
+           if (zone_of(rr.name) != ZNAME)
+                return (NOTZONE);
+           if (rr.class == ANY)
+                if (rr.rdlength != 0)
+                     return (FORMERR)
+                if (rr.type == ANY)
+                     if (!zone_name<rr.name>)
+                          return (NXDOMAIN)
+                else
+                     if (!zone_rrset<rr.name, rr.type>)
+                          return (NXRRSET)
+           if (rr.class == NONE)
+                if (rr.rdlength != 0)
+                     return (FORMERR)
+                if (rr.type == ANY)
+                     if (zone_name<rr.name>)
+                          return (YXDOMAIN)
+                else
+                     if (zone_rrset<rr.name, rr.type>)
+                          return (YXRRSET)
+           if (rr.class == zclass)
+                temp<rr.name, rr.type> += rr
+           else
+                return (FORMERR)
+
+      for rrset in temp
+           if (zone_rrset<rrset.name, rrset.type> != rrset)
+                return (NXRRSET)
+
+   3.3 - Check Requestor's Permissions
+
+   3.3.1. Next, the requestor's permission to update the RRs named in
+   the Update Section may be tested in an implementation dependent
+   fashion or using mechanisms specified in a subsequent Secure DNS
+   Update protocol.  If the requestor does not have permission to
+   perform these updates, the server may write a warning message in its
+   operations log, and may either signal REFUSED to the requestor, or
+   ignore the permission problem and proceed with the update.
+
+
+
+
+
+
+
+
+Vixie, et. al.              Standards Track                    [Page 12]
+
+RFC 2136                       DNS Update                     April 1997
+
+
+   3.3.2. While the exact processing is implementation defined, if these
+   verification activities are to be performed, this is the point in the
+   server's processing where such performance should take place, since
+   if a REFUSED condition is encountered after an update has been
+   partially applied, it will be necessary to undo the partial update
+   and restore the zone to its original state before answering the
+   requestor.
+
+   3.3.3 - Pseudocode for Permission Checking
+
+      if (security policy exists)
+           if (this update is not permitted)
+                if (local option)
+                     log a message about permission problem
+                if (local option)
+                     return (REFUSED)
+
+   3.4 - Process Update Section
+
+   Next, the Update Section is processed as follows.
+
+   3.4.1 - Prescan
+
+   The Update Section is parsed into RRs and each RR's CLASS is checked
+   to see if it is ANY, NONE, or the same as the Zone Class, else signal
+   a FORMERR to the requestor.  Using the definitions in Section 1.2,
+   each RR's NAME must be in the zone specified by the Zone Section,
+   else signal NOTZONE to the requestor.
+
+   3.4.1.2. For RRs whose CLASS is not ANY, check the TYPE and if it is
+   ANY, AXFR, MAILA, MAILB, or any other QUERY metatype, or any
+   unrecognized type, then signal FORMERR to the requestor.  For RRs
+   whose CLASS is ANY or NONE, check the TTL to see that it is zero (0),
+   else signal a FORMERR to the requestor.  For any RR whose CLASS is
+   ANY, check the RDLENGTH to make sure that it is zero (0) (that is,
+   the RDATA field is empty), and that the TYPE is not AXFR, MAILA,
+   MAILB, or any other QUERY metatype besides ANY, or any unrecognized
+   type, else signal FORMERR to the requestor.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Vixie, et. al.              Standards Track                    [Page 13]
+
+RFC 2136                       DNS Update                     April 1997
+
+
+   3.4.1.3 - Pseudocode For Update Section Prescan
+
+      [rr] for rr in updates
+           if (zone_of(rr.name) != ZNAME)
+                return (NOTZONE);
+           if (rr.class == zclass)
+                if (rr.type & ANY|AXFR|MAILA|MAILB)
+                     return (FORMERR)
+           elsif (rr.class == ANY)
+                if (rr.ttl != 0 || rr.rdlength != 0
+                    || rr.type & AXFR|MAILA|MAILB)
+                     return (FORMERR)
+           elsif (rr.class == NONE)
+                if (rr.ttl != 0 || rr.type & ANY|AXFR|MAILA|MAILB)
+                     return (FORMERR)
+           else
+                return (FORMERR)
+
+   3.4.2 - Update
+
+   The Update Section is parsed into RRs and these RRs are processed in
+   order.
+
+   3.4.2.1. If any system failure (such as an out of memory condition,
+   or a hardware error in persistent storage) occurs during the
+   processing of this section, signal SERVFAIL to the requestor and undo
+   all updates applied to the zone during this transaction.
+
+   3.4.2.2. Any Update RR whose CLASS is the same as ZCLASS is added to
+   the zone.  In case of duplicate RDATAs (which for SOA RRs is always
+   the case, and for WKS RRs is the case if the ADDRESS and PROTOCOL
+   fields both match), the Zone RR is replaced by Update RR.  If the
+   TYPE is SOA and there is no Zone SOA RR, or the new SOA.SERIAL is
+   lower (according to [RFC1982]) than or equal to the current Zone SOA
+   RR's SOA.SERIAL, the Update RR is ignored.  In the case of a CNAME
+   Update RR and a non-CNAME Zone RRset or vice versa, ignore the CNAME
+   Update RR, otherwise replace the CNAME Zone RR with the CNAME Update
+   RR.
+
+   3.4.2.3. For any Update RR whose CLASS is ANY and whose TYPE is ANY,
+   all Zone RRs with the same NAME are deleted, unless the NAME is the
+   same as ZNAME in which case only those RRs whose TYPE is other than
+   SOA or NS are deleted.  For any Update RR whose CLASS is ANY and
+   whose TYPE is not ANY all Zone RRs with the same NAME and TYPE are
+   deleted, unless the NAME is the same as ZNAME in which case neither
+   SOA or NS RRs will be deleted.
+
+
+
+
+
+Vixie, et. al.              Standards Track                    [Page 14]
+
+RFC 2136                       DNS Update                     April 1997
+
+
+   3.4.2.4. For any Update RR whose class is NONE, any Zone RR whose
+   NAME, TYPE, RDATA and RDLENGTH are equal to the Update RR is deleted,
+   unless the NAME is the same as ZNAME and either the TYPE is SOA or
+   the TYPE is NS and the matching Zone RR is the only NS remaining in
+   the RRset, in which case this Update RR is ignored.
+
+   3.4.2.5. Signal NOERROR to the requestor.
+
+   3.4.2.6 - Table Of Metavalues Used In Update Section
+
+   CLASS    TYPE     RDATA    Meaning
+   ---------------------------------------------------------
+   ANY      ANY      empty    Delete all RRsets from a name
+   ANY      rrset    empty    Delete an RRset
+   NONE     rrset    rr       Delete an RR from an RRset
+   zone     rrset    rr       Add to an RRset
+
+   3.4.2.7 - Pseudocode For Update Section Processing
+
+      [rr] for rr in updates
+           if (rr.class == zclass)
+                if (rr.type == CNAME)
+                     if (zone_rrset<rr.name, ~CNAME>)
+                          next [rr]
+                elsif (zone_rrset<rr.name, CNAME>)
+                     next [rr]
+                if (rr.type == SOA)
+                     if (!zone_rrset<rr.name, SOA> ||
+                         zone_rr<rr.name, SOA>.serial > rr.soa.serial)
+                          next [rr]
+                for zrr in zone_rrset<rr.name, rr.type>
+                     if (rr.type == CNAME || rr.type == SOA ||
+                         (rr.type == WKS && rr.proto == zrr.proto &&
+                          rr.address == zrr.address) ||
+                         rr.rdata == zrr.rdata)
+                          zrr = rr
+                          next [rr]
+                zone_rrset<rr.name, rr.type> += rr
+           elsif (rr.class == ANY)
+                if (rr.type == ANY)
+                     if (rr.name == zname)
+                          zone_rrset<rr.name, ~(SOA|NS)> = Nil
+                     else
+                          zone_rrset<rr.name, *> = Nil
+                elsif (rr.name == zname &&
+                       (rr.type == SOA || rr.type == NS))
+                     next [rr]
+                else
+
+
+
+Vixie, et. al.              Standards Track                    [Page 15]
+
+RFC 2136                       DNS Update                     April 1997
+
+
+                     zone_rrset<rr.name, rr.type> = Nil
+           elsif (rr.class == NONE)
+                if (rr.type == SOA)
+                     next [rr]
+                if (rr.type == NS && zone_rrset<rr.name, NS> == rr)
+                     next [rr]
+                zone_rr<rr.name, rr.type, rr.data> = Nil
+      return (NOERROR)
+
+   3.5 - Stability
+
+   When a zone is modified by an UPDATE operation, the server must
+   commit the change to nonvolatile storage before sending a response to
+   the requestor or answering any queries or transfers for the modified
+   zone.  It is reasonable for a server to store only the update records
+   as long as a system reboot or power failure will cause these update
+   records to be incorporated into the zone the next time the server is
+   started.  It is also reasonable for the server to copy the entire
+   modified zone to nonvolatile storage after each update operation,
+   though this would have suboptimal performance for large zones.
+
+   3.6 - Zone Identity
+
+   If the zone's SOA SERIAL is changed by an update operation, that
+   change must be in a positive direction (using modulo 2**32 arithmetic
+   as specified by [RFC1982]).  Attempts to replace an SOA with one
+   whose SERIAL is less than the current one will be silently ignored by
+   the primary master server.
+
+   If the zone's SOA's SERIAL is not changed as a result of an update
+   operation, then the server shall increment it automatically before
+   the SOA or any changed name or RR or RRset is included in any
+   response or transfer.  The primary master server's implementor might
+   choose to autoincrement the SOA SERIAL if any of the following events
+   occurs:
+
+   (1)  Each update operation.
+
+   (2)  A name, RR or RRset in the zone has changed and has subsequently
+        been visible to a DNS client since the unincremented SOA was
+        visible to a DNS client, and the SOA is about to become visible
+        to a DNS client.
+
+   (3)  A configurable period of time has elapsed since the last update
+        operation.  This period shall be less than or equal to one third
+        of the zone refresh time, and the default shall be the lesser of
+        that maximum and 300 seconds.
+
+
+
+
+Vixie, et. al.              Standards Track                    [Page 16]
+
+RFC 2136                       DNS Update                     April 1997
+
+
+   (4)  A configurable number of updates has been applied since the last
+        SOA change.  The default value for this configuration parameter
+        shall be one hundred (100).
+
+   It is imperative that the zone's contents and the SOA's SERIAL be
+   tightly synchronized.  If the zone appears to change, the SOA must
+   appear to change as well.
+
+   3.7 - Atomicity
+
+   During the processing of an UPDATE transaction, the server must
+   ensure atomicity with respect to other (concurrent) UPDATE or QUERY
+   transactions.  No two transactions can be processed concurrently if
+   either depends on the final results of the other; in particular, a
+   QUERY should not be able to retrieve RRsets which have been partially
+   modified by a concurrent UPDATE, and an UPDATE should not be able to
+   start from prerequisites that might not still hold at the completion
+   of some other concurrent UPDATE.  Finally, if two UPDATE transactions
+   would modify the same names, RRs or RRsets, then such UPDATE
+   transactions must be serialized.
+
+   3.8 - Response
+
+   At the end of UPDATE processing, a response code will be known.  A
+   response message is generated by copying the ID and Opcode fields
+   from the request, and either copying the ZOCOUNT, PRCOUNT, UPCOUNT,
+   and ADCOUNT fields and associated sections, or placing zeros (0) in
+   the these "count" fields and not including any part of the original
+   update.  The QR bit is set to one (1), and the response is sent back
+   to the requestor.  If the requestor used UDP, then the response will
+   be sent to the requestor's source UDP port.  If the requestor used
+   TCP, then the response will be sent back on the requestor's open TCP
+   connection.
+
+4 - Requestor Behaviour
+
+   4.1. From a requestor's point of view, any authoritative server for
+   the zone can appear to be able to process update requests, even
+   though only the primary master server is actually able to modify the
+   zone's master file.  Requestors are expected to know the name of the
+   zone they intend to update and to know or be able to determine the
+   name servers for that zone.
+
+
+
+
+
+
+
+
+
+Vixie, et. al.              Standards Track                    [Page 17]
+
+RFC 2136                       DNS Update                     April 1997
+
+
+   4.2. If update ordering is desired, the requestor will need to know
+   the value of the existing SOA RR.  Requestors who update the SOA RR
+   must update the SOA SERIAL field in a positive direction (as defined
+   by [RFC1982]) and also preserve the other SOA fields unless the
+   requestor's explicit intent is to change them.  The SOA SERIAL field
+   must never be set to zero (0).
+
+   4.3. If the requestor has reasonable cause to believe that all of a
+   zone's servers will be equally reachable, then it should arrange to
+   try the primary master server (as given by the SOA MNAME field if
+   matched by some NS NSDNAME) first to avoid unnecessary forwarding
+   inside the slave servers.  (Note that the primary master will in some
+   cases not be reachable by all requestors, due to firewalls or network
+   partitioning.)
+
+   4.4. Once the zone's name servers been found and possibly sorted so
+   that the ones more likely to be reachable and/or support the UPDATE
+   opcode are listed first, the requestor composes an UPDATE message of
+   the following form and sends it to the first name server on its list:
+
+      ID:                        (new)
+      Opcode:                    UPDATE
+      Zone zcount:               1
+      Zone zname:                (zone name)
+      Zone zclass:               (zone class)
+      Zone ztype:                T_SOA
+      Prerequisite Section:      (see previous text)
+      Update Section:            (see previous text)
+      Additional Data Section:   (empty)
+
+   4.5. If the requestor receives a response, and the response has an
+   RCODE other than SERVFAIL or NOTIMP, then the requestor returns an
+   appropriate response to its caller.
+
+   4.6. If a response is received whose RCODE is SERVFAIL or NOTIMP, or
+   if no response is received within an implementation dependent timeout
+   period, or if an ICMP error is received indicating that the server's
+   port is unreachable, then the requestor will delete the unusable
+   server from its internal name server list and try the next one,
+   repeating until the name server list is empty.  If the requestor runs
+   out of servers to try, an appropriate error will be returned to the
+   requestor's caller.
+
+
+
+
+
+
+
+
+
+Vixie, et. al.              Standards Track                    [Page 18]
+
+RFC 2136                       DNS Update                     April 1997
+
+
+5 - Duplicate Detection, Ordering and Mutual Exclusion
+
+   5.1. For correct operation, mechanisms may be needed to ensure
+   idempotence, order UPDATE requests and provide mutual exclusion.  An
+   UPDATE message or response might be delivered zero times, one time,
+   or multiple times.  Datagram duplication is of particular interest
+   since it covers the case of the so-called "replay attack" where a
+   correct request is duplicated maliciously by an intruder.
+
+   5.2. Multiple UPDATE requests or responses in transit might be
+   delivered in any order, due to network topology changes or load
+   balancing, or to multipath forwarding graphs wherein several slave
+   servers all forward to the primary master.  In some cases, it might
+   be required that the earlier update not be applied after the later
+   update, where "earlier" and "later" are defined by an external time
+   base visible to some set of requestors, rather than by the order of
+   request receipt at the primary master.
+
+   5.3. A requestor can ensure transaction idempotence by explicitly
+   deleting some "marker RR" (rather than deleting the RRset of which it
+   is a part) and then adding a new "marker RR" with a different RDATA
+   field.  The Prerequisite Section should specify that the original
+   "marker RR" must be present in order for this UPDATE message to be
+   accepted by the server.
+
+   5.4. If the request is duplicated by a network error, all duplicate
+   requests will fail since only the first will find the original
+   "marker RR" present and having its known previous value.  The
+   decisions of whether to use such a "marker RR" and what RR to use are
+   left up to the application programmer, though one obvious choice is
+   the zone's SOA RR as described below.
+
+   5.5. Requestors can ensure update ordering by externally
+   synchronizing their use of successive values of the "marker RR."
+   Mutual exclusion can be addressed as a degenerate case, in that a
+   single succession of the "marker RR" is all that is needed.
+
+   5.6. A special case where update ordering and datagram duplication
+   intersect is when an RR validly changes to some new value and then
+   back to its previous value.  Without a "marker RR" as described
+   above, this sequence of updates can leave the zone in an undefined
+   state if datagrams are duplicated.
+
+   5.7. To achieve an atomic multitransaction "read-modify-write" cycle,
+   a requestor could first retrieve the SOA RR, and build an UPDATE
+   message one of whose prerequisites was the old SOA RR.  It would then
+   specify updates that would delete this SOA RR and add a new one with
+   an incremented SOA SERIAL, along with whatever actual prerequisites
+
+
+
+Vixie, et. al.              Standards Track                    [Page 19]
+
+RFC 2136                       DNS Update                     April 1997
+
+
+   and updates were the object of the transaction.  If the transaction
+   succeeds, the requestor knows that the RRs being changed were not
+   otherwise altered by any other requestor.
+
+6 - Forwarding
+
+   When a zone slave forwards an UPDATE message upward toward the zone's
+   primary master server, it must allocate a new ID and prepare to enter
+   the role of "forwarding server," which is a requestor with respect to
+   the forward server.
+
+   6.1. The set of forward servers will be same as the set of servers
+   this zone slave would use as the source of AXFR or IXFR data.  So,
+   while the original requestor might have used the zone's NS RRset to
+   locate its update server, a forwarder always forwards toward its
+   designated zone master servers.
+
+   6.2. If the original requestor used TCP, then the TCP connection from
+   the requestor is still open and the forwarder must use TCP to forward
+   the message.  If the original requestor used UDP, the forwarder may
+   use either UDP or TCP to forward the message, at the whim of the
+   implementor.
+
+   6.3. It is reasonable for forward servers to be forwarders
+   themselves, if the AXFR dependency graph being followed is a deep one
+   involving firewalls and multiple connectivity realms.  In most cases
+   the AXFR dependency graph will be shallow and the forward server will
+   be the primary master server.
+
+   6.4. The forwarder will not respond to its requestor until it
+   receives a response from its forward server.  UPDATE transactions
+   involving forwarders are therefore time synchronized with respect to
+   the original requestor and the primary master server.
+
+   6.5. When there are multiple possible sources of AXFR data and
+   therefore multiple possible forward servers, a forwarder will use the
+   same fallback strategy with respect to connectivity or timeout errors
+   that it would use when performing an AXFR.  This is implementation
+   dependent.
+
+   6.6. When a forwarder receives a response from a forward server, it
+   copies this response into a new response message, assigns its
+   requestor's ID to that message, and sends the response back to the
+   requestor.
+
+
+
+
+
+
+
+Vixie, et. al.              Standards Track                    [Page 20]
+
+RFC 2136                       DNS Update                     April 1997
+
+
+7 - Design, Implementation, Operation, and Protocol Notes
+
+   Some of the principles which guided the design of this UPDATE
+   specification are as follows.  Note that these are not part of the
+   formal specification and any disagreement between this section and
+   any other section of this document should be resolved in favour of
+   the other section.
+
+   7.1. Using metavalues for CLASS is possible only because all RRs in
+   the packet are assumed to be in the same zone, and CLASS is an
+   attribute of a zone rather than of an RRset.  (It is for this reason
+   that the Zone Section is not optional.)
+
+   7.2. Since there are no data-present or data-absent errors possible
+   from processing the Update Section, any necessary data-present and
+   data- absent dependencies should be specified in the Prerequisite
+   Section.
+
+   7.3. The Additional Data Section can be used to supply a server with
+   out of zone glue that will be needed in referrals.  For example, if
+   adding a new NS RR to HOME.VIX.COM specifying a nameserver called
+   NS.AU.OZ, the A RR for NS.AU.OZ can be included in the Additional
+   Data Section.  Servers can use this information or ignore it, at the
+   discretion of the implementor.  We discourage caching this
+   information for use in subsequent DNS responses.
+
+   7.4. The Additional Data Section might be used if some of the RRs
+   later needed for Secure DNS Update are not actually zone updates, but
+   rather ancillary keys or signatures not intended to be stored in the
+   zone (as an update would be), yet necessary for validating the update
+   operation.
+
+   7.5. It is expected that in the absence of Secure DNS Update, a
+   server will only accept updates if they come from a source address
+   that has been statically configured in the server's description of a
+   primary master zone.  DHCP servers would be likely candidates for
+   inclusion in this statically configured list.
+
+   7.6. It is not possible to create a zone using this protocol, since
+   there is no provision for a slave server to be told who its master
+   servers are.  It is expected that this protocol will be extended in
+   the future to cover this case.  Therefore, at this time, the addition
+   of SOA RRs is unsupported.  For similar reasons, deletion of SOA RRs
+   is also unsupported.
+
+
+
+
+
+
+
+Vixie, et. al.              Standards Track                    [Page 21]
+
+RFC 2136                       DNS Update                     April 1997
+
+
+   7.7. The prerequisite for specifying that a name own at least one RR
+   differs semantically from QUERY, in that QUERY would return
+   <NOERROR,ANCOUNT=0> rather than NXDOMAIN if queried for an RRset at
+   this name, while UPDATE's prerequisite condition [Section 2.4.4]
+   would NOT be satisfied.
+
+   7.8. It is possible for a UDP response to be lost in transit and for
+   a request to be retried due to a timeout condition.  In this case an
+   UPDATE that was successful the first time it was received by the
+   primary master might ultimately appear to have failed when the
+   response to a duplicate request is finally received by the requestor.
+   (This is because the original prerequisites may no longer be
+   satisfied after the update has been applied.)  For this reason,
+   requestors who require an accurate response code must use TCP.
+
+   7.9. Because a requestor who requires an accurate response code will
+   initiate their UPDATE transaction using TCP, a forwarder who receives
+   a request via TCP must forward it using TCP.
+
+   7.10. Deferral of SOA SERIAL autoincrements is made possible so that
+   serial numbers can be conserved and wraparound at 2**32 can be made
+   an infrequent occurance.  Visible (to DNS clients) SOA SERIALs need
+   to differ if the zone differs.  Note that the Authority Section SOA
+   in a QUERY response is a form of visibility, for the purposes of this
+   prerequisite.
+
+   7.11. A zone's SOA SERIAL should never be set to zero (0) due to
+   interoperability problems with some older but widely installed
+   implementations of DNS.  When incrementing an SOA SERIAL, if the
+   result of the increment is zero (0) (as will be true when wrapping
+   around 2**32), it is necessary to increment it again or set it to one
+   (1).  See [RFC1982] for more detail on this subject.
+
+   7.12. Due to the TTL minimalization necessary when caching an RRset,
+   it is recommended that all TTLs in an RRset be set to the same value.
+   While the DNS Message Format permits variant TTLs to exist in the
+   same RRset, and this variance can exist inside a zone, such variance
+   will have counterintuitive results and its use is discouraged.
+
+   7.13. Zone cut management presents some obscure corner cases to the
+   add and delete operations in the Update Section.  It is possible to
+   delete an NS RR as long as it is not the last NS RR at the root of a
+   zone.  If deleting all RRs from a name, SOA and NS RRs at the root of
+   a zone are unaffected.  If deleting RRsets, it is not possible to
+   delete either SOA or NS RRsets at the top of a zone.  An attempt to
+   add an SOA will be treated as a replace operation if an SOA already
+   exists, or as a no-op if the SOA would be new.
+
+
+
+
+Vixie, et. al.              Standards Track                    [Page 22]
+
+RFC 2136                       DNS Update                     April 1997
+
+
+   7.14. No semantic checking is required in the primary master server
+   when adding new RRs.  Therefore a requestor can cause CNAME or NS or
+   any other kind of RR to be added even if their target name does not
+   exist or does not have the proper RRsets to make the original RR
+   useful.  Primary master servers that DO implement this kind of
+   checking should take great care to avoid out-of-zone dependencies
+   (whose veracity cannot be authoritatively checked) and should
+   implement all such checking during the prescan phase.
+
+   7.15. Nonterminal or wildcard CNAMEs are not well specified by
+   [RFC1035] and their use will probably lead to unpredictable results.
+   Their use is discouraged.
+
+   7.16. Empty nonterminals (nodes with children but no RRs of their
+   own) will cause <NOERROR,ANCOUNT=0> responses to be sent in response
+   to a query of any type for that name.  There is no provision for
+   empty terminal nodes -- so if all RRs of a terminal node are deleted,
+   the name is no longer in use, and queries of any type for that name
+   will result in an NXDOMAIN response.
+
+   7.17. In a deep AXFR dependency graph, it has not historically been
+   an error for slaves to depend mutually upon each other.  This
+   configuration has been used to enable a zone to flow from the primary
+   master to all slaves even though not all slaves have continuous
+   connectivity to the primary master.  UPDATE's use of the AXFR
+   dependency graph for forwarding prohibits this kind of dependency
+   loop, since UPDATE forwarding has no loop detection analagous to the
+   SOA SERIAL pretest used by AXFR.
+
+   7.18. Previously existing names which are occluded by a new zone cut
+   are still considered part of the parent zone, for the purposes of
+   zone transfers, even though queries for such names will be referred
+   to the new subzone's servers.  If a zone cut is removed, all parent
+   zone names that were occluded by it will again become visible to
+   queries.  (This is a clarification of [RFC1034].)
+
+   7.19. If a server is authoritative for both a zone and its child,
+   then queries for names at the zone cut between them will be answered
+   authoritatively using only data from the child zone.  (This is a
+   clarification of [RFC1034].)
+
+
+
+
+
+
+
+
+
+
+
+Vixie, et. al.              Standards Track                    [Page 23]
+
+RFC 2136                       DNS Update                     April 1997
+
+
+   7.20. Update ordering using the SOA RR is problematic since there is
+   no way to know which of a zone's NS RRs represents the primary
+   master, and the zone slaves can be out of date if their SOA.REFRESH
+   timers have not elapsed since the last time the zone was changed on
+   the primary master.  We recommend that a zone needing ordered updates
+   use only servers which implement NOTIFY (see [RFC1996]) and IXFR (see
+   [RFC1995]), and that a client receiving a prerequisite error while
+   attempting an ordered update simply retry after a random delay period
+   to allow the zone to settle.
+
+8 - Security Considerations
+
+   8.1. In the absence of [RFC2137] or equivilent technology, the
+   protocol described by this document makes it possible for anyone who
+   can reach an authoritative name server to alter the contents of any
+   zones on that server.  This is a serious increase in vulnerability
+   from the current technology.  Therefore it is very strongly
+   recommended that the protocols described in this document not be used
+   without [RFC2137] or other equivalently strong security measures,
+   e.g. IPsec.
+
+   8.2. A denial of service attack can be launched by flooding an update
+   forwarder with TCP sessions containing updates that the primary
+   master server will ultimately refuse due to permission problems.
+   This arises due to the requirement that an update forwarder receiving
+   a request via TCP use a synchronous TCP session for its forwarding
+   operation.  The connection management mechanisms of [RFC1035 4.2.2]
+   are sufficient to prevent large scale damage from such an attack, but
+   not to prevent some queries from going unanswered during the attack.
+
+Acknowledgements
+
+   We would like to thank the IETF DNSIND working group for their input
+   and assistance, in particular, Rob Austein, Randy Bush, Donald
+   Eastlake, Masataka Ohta, Mark Andrews, and Robert Elz.  Special
+   thanks to Bill Simpson, Ken Wallich and Bob Halley for reviewing this
+   document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Vixie, et. al.              Standards Track                    [Page 24]
+
+RFC 2136                       DNS Update                     April 1997
+
+
+References
+
+   [RFC1035]
+      Mockapetris, P., "Domain Names - Implementation and
+      Specification", STD 13, RFC 1035, USC/Information Sciences
+      Institute, November 1987.
+
+   [RFC1982]
+      Elz, R., "Serial Number Arithmetic", RFC 1982, University of
+      Melbourne, August 1996.
+
+   [RFC1995]
+      Ohta, M., "Incremental Zone Transfer", RFC 1995, Tokyo Institute
+      of Technology, August 1996.
+
+   [RFC1996]
+      Vixie, P., "A Mechanism for Prompt Notification of Zone Changes",
+      RFC 1996, Internet Software Consortium, August 1996.
+
+   [RFC2065]
+      Eastlake, D., and C. Kaufman, "Domain Name System Protocol
+      Security Extensions", RFC 2065, January 1997.
+
+   [RFC2137]
+      Eastlake, D., "Secure Domain Name System Dynamic Update", RFC
+      2137, April 1997.
+
+Authors' Addresses
+
+   Yakov Rekhter
+   Cisco Systems
+   170 West Tasman Drive
+   San Jose, CA 95134-1706
+
+   Phone: +1 914 528 0090
+   EMail: yakov@cisco.com
+
+
+   Susan Thomson
+   Bellcore
+   445 South Street
+   Morristown, NJ 07960
+
+   Phone: +1 201 829 4514
+   EMail: set@thumper.bellcore.com
+
+
+
+
+
+
+Vixie, et. al.              Standards Track                    [Page 25]
+
+RFC 2136                       DNS Update                     April 1997
+
+
+   Jim Bound
+   Digital Equipment Corp.
+   110 Spitbrook Rd ZK3-3/U14
+   Nashua, NH 03062-2698
+
+   Phone: +1 603 881 0400
+   EMail: bound@zk3.dec.com
+
+
+   Paul Vixie
+   Internet Software Consortium
+   Star Route Box 159A
+   Woodside, CA 94062
+
+   Phone: +1 415 747 0204
+   EMail: paul@vix.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Vixie, et. al.              Standards Track                    [Page 26]
+
+
diff --git a/doc/rfc/rfc2137.txt b/doc/rfc/rfc2137.txt
new file mode 100644
index 0000000..ceb3613
--- /dev/null
+++ b/doc/rfc/rfc2137.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+Network Working Group                                    D. Eastlake 3rd
+Request for Comments: 2137                               CyberCash, Inc.
+Updates: 1035                                                 April 1997
+Category: Standards Track
+
+
+                Secure Domain Name System Dynamic Update
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Abstract
+
+   Domain Name System (DNS) protocol extensions have been defined to
+   authenticate the data in DNS and provide key distribution services
+   [RFC2065].  DNS Dynamic Update operations have also been defined
+   [RFC2136], but without a detailed description of security for the
+   update operation.  This memo describes how to use DNSSEC digital
+   signatures covering requests and data to secure updates and restrict
+   updates to those authorized to perform them as indicated by the
+   updater's possession of cryptographic keys.
+
+Acknowledgements
+
+   The contributions of the following persons (who are listed in
+   alphabetic order) to this memo are gratefully acknowledged:
+
+         Olafur Gudmundsson (ogud@tis.com>
+         Charlie Kaufman <Charlie_Kaufman@iris.com>
+         Stuart Kwan <skwan@microsoft.com>
+         Edward Lewis <lewis@tis.com>
+
+Table of Contents
+
+      1. Introduction............................................2
+      1.1 Overview of DNS Dynamic Update.........................2
+      1.2 Overview of DNS Security...............................2
+      2. Two Basic Modes.........................................3
+      3. Keys....................................................5
+      3.1 Update Keys............................................6
+      3.1.1 Update Key Name Scope................................6
+      3.1.2 Update Key Class Scope...............................6
+      3.1.3 Update Key Signatory Field...........................6
+
+
+
+Eastlake                    Standards Track                     [Page 1]
+
+RFC 2137                         SDNSDU                       April 1997
+
+
+      3.2 Zone Keys and Update Modes.............................8
+      3.3 Wildcard Key Punch Through.............................9
+      4. Update Signatures.......................................9
+      4.1 Update Request Signatures..............................9
+      4.2 Update Data Signatures................................10
+      5. Security Considerations................................10
+      References................................................10
+      Author's Address..........................................11
+
+1. Introduction
+
+   Dynamic update operations have been defined for the Domain Name
+   System (DNS) in RFC 2136, but without a detailed description of
+   security for those updates.  Means of securing the DNS and using it
+   for key distribution have been defined in RFC 2065.
+
+   This memo proposes techniques based on the defined DNS security
+   mechanisms to authenticate DNS updates.
+
+   Familiarity with the DNS system [RFC 1034, 1035] is assumed.
+   Familiarity with the DNS security and dynamic update proposals will
+   be helpful.
+
+1.1 Overview of DNS Dynamic Update
+
+   DNS dynamic update defines a new DNS opcode, new DNS request and
+   response structure if that opcode is used, and new error codes.  An
+   update can specify complex combinations of deletion and insertion
+   (with or without pre-existence testing) of resource records (RRs)
+   with one or more owner names; however, all testing and changes for
+   any particular DNS update request are restricted to a single zone.
+   Updates occur at the primary server for a zone.
+
+   The primary server for a secure dynamic zone must increment the zone
+   SOA serial number when an update occurs or the next time the SOA is
+   retrieved if one or more updates have occurred since the previous SOA
+   retrieval and the updates themselves did not update the SOA.
+
+1.2 Overview of DNS Security
+
+   DNS security authenticates data in the DNS by also storing digital
+   signatures in the DNS as SIG resource records (RRs).  A SIG RR
+   provides a digital signature on the set of all RRs with the same
+   owner name and class as the SIG and whose type is the type covered by
+   the SIG.  The SIG RR cryptographically binds the covered RR set to
+   the signer, time signed, signature expiration date, etc.  There are
+   one or more keys associated with every secure zone and all data in
+   the secure zone is signed either by a zone key or by a dynamic update
+
+
+
+Eastlake                    Standards Track                     [Page 2]
+
+RFC 2137                         SDNSDU                       April 1997
+
+
+   key tracing its authority to a zone key.
+
+   DNS security also defines transaction SIGs and request SIGs.
+   Transaction SIGs appear at the end of a response.  Transaction SIGs
+   authenticate the response and bind it to the corresponding request
+   with the key of the host where the responding DNS server is.  Request
+   SIGs appear at the end of a request and authenticate the request with
+   the key of the submitting entity.
+
+   Request SIGs are the primary means of authenticating update requests.
+
+   DNS security also permits the storage of public keys in the DNS via
+   KEY RRs.  These KEY RRs are also, of course, authenticated by SIG
+   RRs.  KEY RRs for zones are stored in their superzone and subzone
+   servers, if any, so that the secure DNS tree of zones can be
+   traversed by a security aware resolver.
+
+2. Two Basic Modes
+
+   A dynamic secure zone is any secure DNS zone containing one or more
+   KEY RRs that can authorize dynamic updates, i.e., entity or user KEY
+   RRs with the signatory field non-zero, and whose zone KEY RR
+   signatory field indicates that updates are implemented. There are two
+   basic modes of dynamic secure zone which relate to the update
+   strategy, mode A and mode B.  A summary comparison table is given
+   below and then each mode is described.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake                    Standards Track                     [Page 3]
+
+RFC 2137                         SDNSDU                       April 1997
+
+
+                   SUMMARY OF DYNAMIC SECURE ZONE MODES
+
+   CRITERIA:                |   MODE A           |   MODE B
+   =========================+====================+===================
+   Definition:              | Zone Key Off line  | Zone Key On line
+   =========================+====================+===================
+   Server Workload          |   Low              |   High
+   -------------------------+--------------------+-------------------
+   Static Data Security     |   Very High        |   Medium-High
+   -------------------------+--------------------+-------------------
+   Dynamic Data Security    |   Medium           |   Medium-High
+   -------------------------+--------------------+-------------------
+   Key Restrictions         |   Fine grain       |   Coarse grain
+   -------------------------+--------------------+-------------------
+   Dynamic Data Temporality |   Transient        |   Permanent
+   -------------------------+--------------------+-------------------
+   Dynamic Key Rollover     |   No               |   Yes
+   -------------------------+--------------------+-------------------
+
+   For mode A, the zone owner key and static zone master file are always
+   kept off-line for maximum security of the static zone contents.
+
+   As a consequence, any dynamicly added or changed RRs are signed in
+   the secure zone by their authorizing dynamic update key and they are
+   backed up, along with this SIG RR, in a separate online dynamic
+   master file.  In this type of zone, server computation is minimized
+   since the server need only check signatures on the update data and
+   request, which have already been signed by the updater, generally a
+   much faster operation than signing data.  However, the AXFR SIG and
+   NXT RRs which covers the zone under the zone key will not cover
+   dynamically added data.  Thus, for type A dynamic secure zones, zone
+   transfer security is not automatically provided for dynamically added
+   RRs, where they could be omitted, and authentication is not provided
+   for the server denial of the existence of a dynamically added type.
+   Because the dynamicly added RRs retain their update KEY signed SIG,
+   finer grained control of updates can be implemented via bits in the
+   KEY RR signatory field.  Because dynamic data is only stored in the
+   online dynamic master file and only authenticated by dynamic keys
+   which expire, updates are transient in nature.  Key rollover for an
+   entity that can authorize dynamic updates is more cumbersome since
+   the authority of their key must be traceable to a zone key and so, in
+   general, they must securely communicate a new key to the zone
+   authority for manual transfer to the off line static master file.
+   NOTE: for this mode the zone SOA must be signed by a dynamic update
+   key and that private key must be kept on line so that the SOA can be
+   changed for updates.
+
+
+
+
+
+Eastlake                    Standards Track                     [Page 4]
+
+RFC 2137                         SDNSDU                       April 1997
+
+
+   For mode B, the zone owner key and master file are kept on-line at
+   the zone primary server. When authenticated updates succeed, SIGs
+   under the zone key for the resulting data (including the possible NXT
+   type bit map changes) are calculated and these SIG (and possible NXT)
+   changes are entered into the zone and the unified on-line master
+   file.  (The zone transfer AXFR SIG may be recalculated for each
+   update or on demand when a zone transfer is requested and it is out
+   of date.)
+
+   As a consequence, this mode requires considerably more computational
+   effort on the part of the server as the public/private keys are
+   generally arranged so that signing (calculating a SIG) is more effort
+   than verifying a signature.  The security of static data in the zone
+   is decreased because the ultimate state of the static data being
+   served and the ultimate zone authority private key are all on-line on
+   the net.  This means that if the primary server is subverted, false
+   data could be authenticated to secondaries and other
+   servers/resolvers.  On the other hand, this mode of operation means
+   that data added dynamically is more secure than in mode A.  Dynamic
+   data will be covered by the AXFR SIG and thus always protected during
+   zone transfers and will be included in NXT RRs so that it can be
+   falsely denied by a server only to the same extent that static data
+   can (i.e., if it is within a wild card scope). Because the zone key
+   is used to sign all the zone data, the information as to who
+   originated the current state of dynamic RR sets is lost, making
+   unavailable the effects of some of the update control bits in the KEY
+   RR signatory field.  In addition, the incorporation of the updates
+   into the primary master file and their authentication by the zone key
+   makes then permanent in nature.  Maintaining the zone key on-line
+   also means that dynamic update keys which are signed by the zone key
+   can be dynamically updated since the zone key is available to
+   dynamically sign new values.
+
+   NOTE:  The Mode A / Mode B distinction only effects the validation
+   and performance of update requests.  It has no effect on retrievals.
+   One reasonable operational scheme may be to keep a mostly static main
+   zone operating in Mode A and have one or more dynamic subzones
+   operating in Mode B.
+
+3. Keys
+
+   Dynamic update requests depend on update keys as described in section
+   3.1 below.  In addition, the zone secure dynamic update mode and
+   availability of some options is indicated in the zone key.  Finally,
+   a special rule is used in searching for KEYs to validate updates as
+   described in section 3.3.
+
+
+
+
+
+Eastlake                    Standards Track                     [Page 5]
+
+RFC 2137                         SDNSDU                       April 1997
+
+
+3.1 Update Keys
+
+   All update requests to a secure zone must include signatures by one
+   or more key(s) that together can authorize that update.  In order for
+   the Domain Name System (DNS) server receiving the request to confirm
+   this, the key or keys must be available to and authenticated by that
+   server as a specially flagged KEY Resource Record.
+
+   The scope of authority of such keys is indicated by their KEY RR
+   owner name, class, and signatory field flags as described below. In
+   addition, such KEY RRs must be entity or user keys and not have the
+   authentication use prohibited bit on.  All parts of the actual update
+   must be within the scope of at least one of the keys used for a
+   request SIG on the update request as described in section 4.
+
+3.1.1 Update Key Name Scope
+
+   The owner name of any update authorizing KEY RR must (1) be the same
+   as the owner name of any RRs being added or deleted or (2) a wildcard
+   name including within its extended scope (see section 3.3) the name
+   of any RRs being added or deleted and those RRs must be in the same
+   zone.
+
+3.1.2 Update Key Class Scope
+
+   The class of any update authorizing KEY RR must be the same as the
+   class of any RR's being added or deleted.
+
+3.1.3 Update Key Signatory Field
+
+   The four bit "signatory field" (see RFC 2065) of any update
+   authorizing KEY RR must be non-zero.  The bits have the meanings
+   described below for non-zone keys (see section 3.2 for zone type
+   keys).
+
+                    UPDATE KEY RR SIGNATORY FIELD BITS
+
+         0           1           2           3
+   +-----------+-----------+-----------+-----------+
+   |   zone    |  strong   |  unique   |  general  |
+   +-----------+-----------+-----------+-----------+
+
+   Bit 0, zone control - If nonzero, this key is authorized to attach,
+        detach, and move zones by creating and deleting NS, glue A, and
+        zone KEY RR(s).  If zero, the key can not authorize any update
+        that would effect such RRs.  This bit is meaningful for both
+        type A and type B dynamic secure zones.
+
+
+
+
+Eastlake                    Standards Track                     [Page 6]
+
+RFC 2137                         SDNSDU                       April 1997
+
+
+        NOTE:  do not confuse the "zone" signatory field bit with the
+        "zone" key type bit.
+
+   Bit 1, strong update - If nonzero, this key is authorized to add and
+        delete RRs even if there are other RRs with the same owner name
+        and class that are authenticated by a SIG signed with a
+        different dynamic update KEY. If zero, the key can only
+        authorize updates where any existing RRs of the same owner and
+        class are authenticated by a SIG using the same key.  This bit
+        is meaningful only for type A dynamic zones and is ignored in
+        type B dynamic zones.
+
+        Keeping this bit zero on multiple KEY RRs with the same or
+        nested wild card owner names permits multiple entities to exist
+        that can create and delete names but can not effect RRs with
+        different owner names from any they created.  In effect, this
+        creates two levels of dynamic update key, strong and weak, where
+        weak keys are limited in interfering with each other but a
+        strong key can interfere with any weak keys or other strong
+        keys.
+
+   Bit 2, unique name update - If nonzero, this key is authorized to add
+        and update RRs for only a single owner name.  If there already
+        exist RRs with one or more names signed by this key, they may be
+        updated but no new name created until the number of existing
+        names is reduced to zero.  This bit is meaningful only for mode
+        A dynamic zones and is ignored in mode B dynamic zones. This bit
+        is meaningful only if the owner name is a wildcard.  (Any
+        dynamic update KEY with a non-wildcard name is, in effect, a
+        unique name update key.)
+
+        This bit can be used to restrict a KEY from flooding a zone with
+        new names.  In conjunction with a local administratively imposed
+        limit on the number of dynamic RRs with a particular name, it
+        can completely restrict a KEY from flooding a zone with RRs.
+
+   Bit 3, general update - The general update signatory field bit has no
+        special meaning.  If the other three bits are all zero, it must
+        be one so that the field is non-zero to designate that the key
+        is an update key.  The meaning of all values of the signatory
+        field with the general bit and one or more other signatory field
+        bits on is reserved.
+
+   All the signatory bit update authorizations described above only
+   apply if the update is within the name and class scope as per
+   sections 3.1.1 and 3.1.2.
+
+
+
+
+
+Eastlake                    Standards Track                     [Page 7]
+
+RFC 2137                         SDNSDU                       April 1997
+
+
+3.2 Zone Keys and Update Modes
+
+   Zone type keys are automatically authorized to sign anything in their
+   zone, of course, regardless of the value of their signatory field.
+   For zone keys, the signatory field bits have different means than
+   they they do for update keys, as shown below.  The signatory field
+   MUST be zero if dynamic update is not supported for a zone and MUST
+   be non-zero if it is.
+
+                     ZONE KEY RR SIGNATORY FIELD BITS
+
+                  0           1           2           3
+            +-----------+-----------+-----------+-----------+
+            |   mode    |  strong   |  unique   |  general  |
+            +-----------+-----------+-----------+-----------+
+
+   Bit 0, mode - This bit indicates the update mode for this zone.  Zero
+        indicates mode A while a one indicates mode B.
+
+   Bit 1, strong update - If nonzero, this indicates that the "strong"
+        key feature described in section 3.1.3 above is implemented and
+        enabled for this secure zone.  If zero, the feature is not
+        available.  Has no effect if the zone is a mode B secure update
+        zone.
+
+   Bit 2, unique name update - If nonzero, this indicates that the
+        "unique name" feature described in section 3.1.3 above is
+        implemented and enabled for this secure zone.  If zero, this
+        feature is not available.  Has no effect if the zone is a mode B
+        secure update zone.
+
+   Bit 3, general - This bit has no special meeting.  If dynamic update
+        for a zone is supported and the other bits in the zone key
+        signatory field are zero, it must be a one.  The meaning of zone
+        keys where the signatory field has the general bit and one or
+        more other bits on is reserved.
+
+   If there are multiple dynamic update KEY RRs for a zone and zone
+   policy is in transition, they might have different non-zero signatory
+   fields.  In that case, strong and unique name restrictions must be
+   enforced as long as there is a non-expired zone key being advertised
+   that indicates mode A with the strong or unique name bit on
+   respectively.  Mode B updates MUST be supported as long as there is a
+   non-expired zone key that indicates mode B.  Mode A updates may be
+   treated as mode B updates at server option if non-expired zone keys
+   indicate that both are supported.
+
+
+
+
+
+Eastlake                    Standards Track                     [Page 8]
+
+RFC 2137                         SDNSDU                       April 1997
+
+
+   A server that will be executing update operations on a zone, that is,
+   the primary master server, MUST not advertize a zone key that will
+   attract requests for a mode or features that it can not support.
+
+3.3 Wildcard Key Punch Through
+
+   Just as a zone key is valid throughout the entire zone, update keys
+   with wildcard names are valid throughout their extended scope, within
+   the zone. That is, they remain valid for any name that would match
+   them, even existing specific names within their apparent scope.
+
+   If this were not so, then whenever a name within a wildcard scope was
+   created by dynamic update, it would be necessary to first create a
+   copy of the KEY RR with this name, because otherwise the existence of
+   the more specific name would hide the authorizing KEY RR and would
+   make later updates impossible.  An updater could create such a KEY RR
+   but could not zone sign it with their authorizing signer.  They would
+   have to sign it with the same key using the wildcard name as signer.
+   Thus in creating, for example, one hundred type A RRs authorized by a
+   *.1.1.1.in-addr.arpa. KEY RR, without key punch through 100 As, 100
+   KEYs, and 200 SIGs would have to be created as opposed to merely 100
+   As and 100 SIGs with key punch through.
+
+4. Update Signatures
+
+   Two kinds of signatures can appear in updates.  Request signatures,
+   which are always required, cover the entire request and authenticate
+   the DNS header, including opcode, counts, etc., as well as the data.
+   Data signatures, on the other hand, appear only among the RRs to be
+   added and are only required for mode A operation.  These two types of
+   signatures are described further below.
+
+4.1 Update Request Signatures
+
+   An update can effect multiple owner names in a zone.  It may be that
+   these different names are covered by different dynamic update keys.
+   For every owner name effected, the updater must know a private key
+   valid for that name (and the zone's class) and must prove this by
+   appending request SIG RRs under each such key.
+
+   As specified in RFC 2065, a request signature is a SIG RR occurring
+   at the end of a request with a type covered field of zero.  For an
+   update, request signatures occur in the Additional information
+   section.  Each request SIG signs the entire request, including DNS
+   header, but excluding any other request SIG(s) and with the ARCOUNT
+   in the DNS header set to what it wold be without the request SIGs.
+
+
+
+
+
+Eastlake                    Standards Track                     [Page 9]
+
+RFC 2137                         SDNSDU                       April 1997
+
+
+4.2 Update Data Signatures
+
+   Mode A dynamic secure zones require that the update requester provide
+   SIG RRs that will authenticate the after update state of all RR sets
+   that are changed by the update and are non-empty after the update.
+   These SIG RRs appear in the request as RRs to be added and the
+   request must delete any previous data SIG RRs that are invalidated by
+   the request.
+
+   In Mode B dynamic secure zones, all zone data is authenticated by
+   zone key SIG RRs.  In this case, data signatures need not be included
+   with the update.  A resolver can determine which mode an updatable
+   secure zone is using by examining the signatory field bits of the
+   zone KEY RR (see section 3.2).
+
+5. Security Considerations
+
+   Any zone permitting dynamic updates is inherently less secure than a
+   static secure zone maintained off line as recommended in RFC 2065. If
+   nothing else, secure dynamic update requires on line change to and
+   re-signing of the zone SOA resource record (RR) to increase the SOA
+   serial number.  This means that compromise of the primary server host
+   could lead to arbitrary serial number changes.
+
+   Isolation of dynamic RRs to separate zones from those holding most
+   static RRs can limit the damage that could occur from breach of a
+   dynamic zone's security.
+
+References
+
+   [RFC2065] Eastlake, D., and C. Kaufman, "Domain Name System Security
+   Extensions", RFC 2065, CyberCash, Iris, January 1997.
+
+   [RFC2136] Vixie, P., Editor, Thomson, T., Rekhter, Y., and J. Bound,
+   "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
+   April 1997.
+
+   [RFC1035] Mockapetris, P., "Domain Names - Implementation and
+   Specifications", STD 13, RFC 1035, November 1987.
+
+   [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
+   STD 13, RFC 1034, November 1987.
+
+
+
+
+
+
+
+
+
+Eastlake                    Standards Track                    [Page 10]
+
+RFC 2137                         SDNSDU                       April 1997
+
+
+Author's Address
+
+   Donald E. Eastlake, 3rd
+   CyberCash, Inc.
+   318 Acton Street
+   Carlisle, MA 01741 USA
+
+   Phone:   +1 508-287-4877
+            +1 508-371-7148 (fax)
+            +1 703-620-4200 (main office, Reston, Virginia, USA)
+   EMail:   dee@cybercash.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake                    Standards Track                    [Page 11]
+
diff --git a/doc/rfc/rfc2163.txt b/doc/rfc/rfc2163.txt
new file mode 100644
index 0000000..00fcee7
--- /dev/null
+++ b/doc/rfc/rfc2163.txt
@@ -0,0 +1,1459 @@
+
+
+
+
+
+
+Network Working Group                                       C. Allocchio
+Request for Comments: 2163                                    GARR-Italy
+Obsoletes: 1664                                             January 1998
+Category: Standards Track
+
+
+                  Using the Internet DNS to Distribute
+            MIXER Conformant Global Address Mapping (MCGAM)
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1998).  All Rights Reserved.
+
+Abstract
+
+   This memo is the complete technical specification to store in the
+   Internet Domain Name System (DNS) the mapping information (MCGAM)
+   needed by MIXER conformant e-mail gateways and other tools to map
+   RFC822 domain names into X.400 O/R names and vice versa.  Mapping
+   information can be managed in a distributed rather than a centralised
+   way. Organizations can publish their MIXER mapping or preferred
+   gateway routing information using just local resources (their local
+   DNS server), avoiding the need for a strong coordination with any
+   centralised organization. MIXER conformant gateways and tools located
+   on Internet hosts can retrieve the mapping information querying the
+   DNS instead of having fixed tables which need to be centrally updated
+   and distributed.
+
+   This memo obsoletes RFC1664. It includes the changes introduced by
+   MIXER specification with respect to RFC1327: the new 'gate1' (O/R
+   addresses to domain) table is fully supported. Full backward
+   compatibility with RFC1664 specification is mantained, too.
+
+   RFC1664 was a joint effort of IETF X400 operation working group
+   (x400ops) and TERENA (formely named "RARE") Mail and Messaging
+   working group (WG-MSG). This update was performed by the IETF MIXER
+   working group.
+
+
+
+
+
+
+Allocchio                   Standards Track                     [Page 1]
+
+RFC 2163                      MIXER MCGAM                   January 1998
+
+
+1. Introduction
+
+   The connectivity between the Internet SMTP mail and other mail
+   services, including the Internet X.400 mail and the commercial X.400
+   service providers, is assured by the Mail eXchanger (MX) record
+   information distributed via the Internet Domain Name System (DNS). A
+   number of documents then specify in details how to convert or encode
+   addresses from/to RFC822 style to the other mail system syntax.
+   However, only conversion methods provide, via some algorithm or a set
+   of mapping rules, a smooth translation, resulting in addresses
+   indistinguishable from the native ones in both RFC822 and foreign
+   world.
+
+   MIXER describes a set of mappings (MIXER Conformant Global Address
+   Mapping - MCGAM) which will enable interworking between systems
+   operating the CCITT X.400 (1984/88/92) Recommendations and systems
+   using using the RFC822 mail protocol, or protocols derived from
+   RFC822. That document addresses conversion of services, addresses,
+   message envelopes, and message bodies between the two mail systems.
+   This document is concerned with one aspect of MIXER: the mechanism
+   for mapping between X.400 O/R addresses and RFC822 domain names. As
+   described in Appendix F of MIXER, implementation of the mappings
+   requires a database which maps between X.400 O/R addresses and domain
+   names; in RFC1327 this database was statically defined.
+
+   The original approach in RFC1327 required many efforts to maintain
+   the correct mapping: all the gateways needed to get coherent tables
+   to apply the same mappings, the conversion tables had to be
+   distributed among all the operational gateways, and also every update
+   needed to be distributed.
+
+   The concept of mapping rules distribution and use has been revised in
+   the new MIXER specification, introducing the concept of MIXER
+   Conformant Global Address Mapping (MCGAM). A MCGAM does not need to
+   be globally installed by any MIXER conformant gateway in the world
+   any more. However MIXER requires now efficient methods to publish its
+   MCGAM.
+
+   Static tables are one of the possible methods to publish MCGAM.
+   However this static mechanism requires quite a long time to be spent
+   modifying and distributing the information, putting heavy constraints
+   on the time schedule of every update.  In fact it does not appear
+   efficient compared to the Internet Domain Name Service (DNS).  More
+   over it does not look feasible to distribute the database to a large
+   number of other useful applications, like local address converters,
+   e-mail User Agents or any other tool requiring the mapping rules to
+   produce correct results.
+
+
+
+
+Allocchio                   Standards Track                     [Page 2]
+
+RFC 2163                      MIXER MCGAM                   January 1998
+
+
+   Two much more efficient methods are proposed by MIXER for publication
+   of MCGAM: the Internet DNS and X.500. This memo is the complete
+   technical specification for publishing MCGAM via Internet DNS.
+
+   A first proposal to use the Internet DNS to store, retrieve and
+   maintain those mappings was introduced by two of the authors of
+   RFC1664 (B. Cole and R. Hagens) adopting two new DNS resource record
+   (RR)  types: TO-X400 and TO-822. This proposal now adopts a more
+   complete strategy, and requires one new RR only. The distribution of
+   MCGAMs via DNS is in fact an important service for the whole Internet
+   community: it completes the information given by MX resource record
+   and it allows to produce clean addresses when messages are exchanged
+   among the Internet RFC822 world and the X.400 one (both Internet and
+   Public X.400 service providers).
+
+   A first experiment in using the DNS without expanding the current set
+   of RR and using available ones was deployed by some of the authors of
+   RFC1664 at the time of its development. The existing PTR resource
+   records were used to store the mapping rules, and a new DNS tree was
+   created under the ".it" top level domain. The result of the
+   experiment was positive, and a few test applications ran under this
+   provisional set up. This test was also very useful in order to define
+   a possible migration strategy during the deployment of the new DNS
+   containing the new RR. The Internet DNS nameservers wishing to
+   provide this mapping information need in fact to be modified to
+   support the new RR type, and in the real Internet, due to the large
+   number of different implementations, this takes some time.
+
+   The basic idea is to adopt a new DNS RR to store the mapping
+   information. The RFC822 to X.400 mapping rules (including the so
+   called 'gate2' rules) will be stored in the ordinary DNS tree, while
+   the definition of a new branch of the name space defined under each
+   national top level domain is envisaged in order to contain the X.400
+   to RFC822 mappings ('table1' and 'gate1'). A "two-way" mapping
+   resolution schema is thus fully implemented.
+
+   The creation of the new domain name space representing the X.400 O/R
+   names structure also provides the chance to use the DNS to distribute
+   dynamically other X.400 related information, thus solving other
+   efficiency problems currently affecting the X.400 MHS service.
+
+   In this paper we will adopt the MCGAM syntax, showing how it can be
+   stored into the Internet DNS.
+
+
+
+
+
+
+
+
+Allocchio                   Standards Track                     [Page 3]
+
+RFC 2163                      MIXER MCGAM                   January 1998
+
+
+1.1 Definitions syntax
+
+   The definitions in this document is given in BNF-like syntax, using
+   the following conventions:
+
+      |   means choice
+      \   is used for continuation of a definition over several lines
+      []  means optional
+      {}  means repeated one or more times
+
+   The definitions, however, are detailed only until a certain level,
+   and below it self-explaining character text strings will be used.
+
+2. Motivation
+
+   Implementations of MIXER gateways require that a database store
+   address mapping information for X.400 and RFC822. This information
+   must be made available (published) to all MIXER gateways. In the
+   Internet community, the DNS has proven to be a practical mean for
+   providing a distributed name service. Advantages of using a DNS based
+   system over a table based approach for mapping between O/R addresses
+   and domain names are:
+
+     - It avoids fetching and storing of entire mapping tables by every
+       host that wishes to implement MIXER gateways and/or tools
+
+     - Modifications to the DNS based mapping information can be made
+       available in a more timely manner than with a table driven
+       approach.
+
+     - It allows full authority delegation, in agreement with the
+       Internet regionalization process.
+
+     - Table management is not necessarily required for DNS-based
+       MIXER gateways.
+
+     - One can determine the mappings in use by a remote gateway by
+       querying the DNS (remote debugging).
+
+   Also many other tools, like address converters and User Agents can
+   take advantage of the real-time availability of MIXER tables,
+   allowing a much easier maintenance of the information.
+
+3. The domain space for X.400 O/R name addresses
+
+   Usual domain names (the ones normally used as the global part of an
+   RFC822 e-mail address) and their associated information, i.e., host
+   IP addresses, mail exchanger names, etc., are stored in the DNS as a
+
+
+
+Allocchio                   Standards Track                     [Page 4]
+
+RFC 2163                      MIXER MCGAM                   January 1998
+
+
+   distributed database under a number of top-level domains. Some top-
+   level domains are used for traditional categories or international
+   organisations (EDU, COM, NET, ORG, INT, MIL...). On the other hand
+   any country has its own two letter ISO country code as top-level
+   domain (FR, DE, GB, IT, RU, ...), including "US" for USA.  The
+   special top-level/second-level couple IN-ADDR.ARPA is used to store
+   the IP address to domain name relationship. This memo defines in the
+   above structure the appropriate way to locate the X.400 O/R name
+   space, thus enabling to store in DNS the MIXER mappings (MCGAMs).
+
+   The MIXER mapping information is composed by four tables:
+
+    - 'table1' and 'gate1' gives the translation from X.400 to RFC822;
+    - 'table2' and 'gate2' tables map RFC822 into X.400.
+
+   Each mapping table is composed by mapping rules, and a single mapping
+   rule is composed by a keyword (the argument of the mapping function
+   derived from the address to be translated) and a translator (the
+   mapping function parameter):
+
+                            keyword#translator#
+
+   the '#' sign is a delimiter enclosing the translator. An example:
+
+                 foo.bar.us#PRMD$foo\.bar.ADMD$intx.C$us#
+
+   Local mappings are not intended for use outside their restricted
+   environment, thus they should not be included in DNS. If local
+   mappings are used, they should be stored using static local tables,
+   exactly as local static host tables can be used with DNS.
+
+   The keyword of a 'table2' and 'gate2' table entry is a valid RFC822
+   domain; thus the usual domain name space can be used without problems
+   to store these entries.
+   On the other hand, the keyword of a 'table1' and 'gate1' entry
+   belongs to the X.400 O/R name space. The X.400 O/R name space does
+   not usually fit into the usual domain name space, although there are
+   a number of similarities; a new name structure is thus needed to
+   represent it. This new name structure contains the X.400 mail
+   domains.
+
+   To ensure the correct functioning of the DNS system, the new X.400
+   name structure must be hooked to the existing domain name space in a
+   way which respects the existing name hierarchy.
+
+   A possible solution was to create another special branch, starting
+   from the root of the DNS tree, somehow similar to the in-addr.arpa
+   tree. This idea would have required to establish a central authority
+
+
+
+Allocchio                   Standards Track                     [Page 5]
+
+RFC 2163                      MIXER MCGAM                   January 1998
+
+
+   to coordinate at international level the management of each national
+   X.400 name tree, including the X.400 public service providers. This
+   coordination problem is a heavy burden if approached globally. More
+   over the X.400 name structure is very 'country oriented': thus while
+   it requires a coordination at national level, it does not have
+   concepts like the international root. In fact the X.400 international
+   service is based  on a large number of bilateral agreements, and only
+   within some communities an international coordination service exists.
+
+   The X.400 two letter ISO country codes, however, are the same used
+   for the RFC822 country top-level domains and this gives us an
+   appropriate hook to insert the new branches. The proposal is, in
+   fact, to create under each national top level ISO country code a new
+   branch in the name space. This branch represents exactly the X.400
+   O/R name structure as defined in each single country, following the
+   ADMD, PRMD, O, OU hierarchy. A unique reserved label 'X42D' is placed
+   under each country top-level domain, and hence the national X.400
+   name space derives its own structure:
+
+                                    . (root)
+                                    |
+      +-----------------+-----------+--------+-----------------+...
+      |                 |                    |                 |
+     edu                it                   us                fr
+      |                 |                    |                 |
+  +---+---+...    +-----+-----+...     +-----+-----+...     +--+---+...
+  |       |       |     |     |        |     |     |        |      |
+ ...     ...     cnr   X42D  infn      va    ca   X42D     X42D  inria
+                        |                    |     |        |
+           +------------+------------+...   ...   ...  +----+-------+...
+           |            |            |                 |            |
+    ADMD-PtPostel  ADMD-garr  ADMD-Master400        ADMD-atlas  ADMD-red
+                        |            |                 |            |
+             +----------+----+...   ...        +-------+------+... ...
+             |               |                 |              |
+         PRMD-infn       PRMD-STET        PRMD-Telecom   PRMD-Renault
+             |               |                 |              |
+            ...             ...               ...            ...
+
+
+   The creation of the X.400 new name tree at national level solves the
+   problem of the international coordination. Actually the coordination
+   problem is just moved at national level, but it thus becomes easier
+   to solve. The coordination at national level between the X.400
+   communities and the Internet world is already a requirement for the
+   creation of the national static MIXER mapping tables; the use of the
+   Internet DNS gives further motivations for this coordination.
+
+
+
+
+Allocchio                   Standards Track                     [Page 6]
+
+RFC 2163                      MIXER MCGAM                   January 1998
+
+
+   The coordination at national level also fits in the new concept of
+   MCGAM pubblication. The DNS in fact allows a step by step authority
+   distribution, up to a final complete delegation: thus organizations
+   whishing to publish their MCGAM just need to receive delegation also
+   for their branch of the new X.400 name space. A further advantage of
+   the national based solution is to allow each country to set up its
+   own X.400 name structure in DNS and to deploy its own authority
+   delegation according to its local time scale and requirements, with
+   no loss of global service in the mean time. And last, placing the new
+   X.400 name tree and coordination process at national level fits into
+   the Internet regionalization and internationalisation process, as it
+   requires local bodies to take care of local coordination problems.
+
+   The DNS name space thus contains completely the information required
+   by an e-mail gateway or tool to perform the X.400-RFC822 mapping: a
+   simple query to the nearest nameserver provides it. Moreover there is
+   no more any need to store, maintain and distribute manually any
+   mapping table. The new X.400 name space can also contain further
+   information about the X.400 community, as DNS allows for it a
+   complete set of resource records, and thus it allows further
+   developments. This set of RRs in the new X.400 name space must be
+   considered 'reserved' and thus not used until further specifications.
+
+   The construction of the new domain space trees will follow the same
+   procedures used when organising at first the already existing DNS
+   space: at first the information will be stored in a quite centralised
+   way, and distribution of authority will be gradually achieved. A
+   separate document will describe the implementation phase and the
+   methods to assure a smooth introduction of the new service.
+
+4. The new DNS resource record for MIXER mapping rules: PX
+
+   The specification of the Internet DNS (RFC1035) provides a number of
+   specific resource records (RRs) to contain specific pieces of
+   information. In particular they contain the Mail eXchanger (MX) RR
+   and the host Address (A) records which are used by the Internet SMTP
+   mailers. As we will store the RFC822 to X.400 mapping information in
+   the already existing DNS name tree, we need to define a new DNS RR in
+   order to avoid any possible clash or misuse of already existing data
+   structures. The same new RR will also be used to store the mappings
+   from X.400 to RFC822. More over the mapping information, i.e., the
+   MCGAMs, has a specific format and syntax which require an appropriate
+   data structure and processing. A further advantage of defining a new
+   RR is the ability to include flexibility for some eventual future
+   development.
+
+
+
+
+
+
+Allocchio                   Standards Track                     [Page 7]
+
+RFC 2163                      MIXER MCGAM                   January 1998
+
+
+   The definition of the new 'PX' DNS resource record is:
+
+      class:        IN   (Internet)
+
+      name:         PX   (pointer to X.400/RFC822 mapping information)
+
+      value:        26
+
+   The PX RDATA format is:
+
+          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+          |                  PREFERENCE                   |
+          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+          /                    MAP822                     /
+          /                                               /
+          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+          /                    MAPX400                    /
+          /                                               /
+          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+   where:
+
+   PREFERENCE   A 16 bit integer which specifies the preference given to
+                this RR among others at the same owner.  Lower values
+                are preferred;
+
+   MAP822       A <domain-name> element containing <rfc822-domain>, the
+                RFC822 part of the MCGAM;
+
+   MAPX400      A <domain-name> element containing the value of
+                <x400-in-domain-syntax> derived from the X.400 part of
+                the MCGAM (see sect. 4.2);
+
+   PX records cause no additional section processing. The PX RR format
+   is the usual one:
+
+             <name> [<class>] [<TTL>] <type> <RDATA>
+
+   When we store in DNS a 'table1' or a 'gate1' entry, then <name> will
+   be an X.400 mail domain name in DNS syntax (see sect. 4.2). When we
+   store a 'table2' or a 'gate2' table entry, <name> will be an RFC822
+   mail domain name, including both fully qualified DNS domains and mail
+   only domains (MX-only domains). All normal DNS conventions, like
+   default values, wildcards, abbreviations and message compression,
+   apply also for all the components of the PX RR. In particular <name>,
+   MAP822 and MAPX400, as <domain-name> elements, must have the final
+   "." (root) when they are fully qualified.
+
+
+
+
+Allocchio                   Standards Track                     [Page 8]
+
+RFC 2163                      MIXER MCGAM                   January 1998
+
+
+4.1 Additional features of the PX resource record
+
+   The definition of the RDATA for the PX resource record, and the fact
+   that DNS allows a distinction between an exact value and a wildcard
+   match for the <name> parameter, represent an extension of the MIXER
+   specification for mapping rules. In fact, any MCGAM entry is an
+   implicit wildcard entry, i.e., the rule
+
+      net2.it#PRMD$net2.ADMD$p400.C$it#
+
+   covers any RFC822 domain ending with 'net2.it', unless more detailed
+   rules for some subdomain in 'net2.it' are present. Thus there is no
+   possibility to specify explicitly a MCGAM as an exact match only
+   rule. In DNS an entry like
+
+      *.net2.it.   IN  PX  10   net2.it.  PRMD-net2.ADMD-p400.C-it.
+
+   specify the usual wildcard match as for MIXER tables. However an
+   entry like
+
+      ab.net2.it.  IN  PX  10   ab.net2.it.  O-ab.PRMD-net2.ADMDb.C-it.
+
+   is valid only for an exact match of 'ab.net2.it' RFC822 domain.
+
+   Note also that in DNS syntax there is no '#' delimiter around MAP822
+   and MAPX400 fields: the syntax defined in sect. 4.2 in fact does not
+   allow the <blank> (ASCII decimal 32) character within these fields,
+   making unneeded the use of an explicit delimiter as required in the
+   MIXER original syntax.
+
+   Another extension to the MIXER specifications is the PREFERENCE value
+   defined as part of the PX RDATA section. This numeric value has
+   exactly the same meaning than the similar one used for the MX RR. It
+   is thus possible to specify more than one single mapping for a domain
+   (both from RFC822 to X.400 and vice versa), giving as the preference
+   order. In MIXER static tables, however, you cannot specify more than
+   one mapping per each RFC822 domain, and the same restriction apply
+   for any X.400 domain mapping to an RFC822 one.
+
+   More over, in the X.400 recommendations a note suggests than an
+   ADMD=<blank> should be reserved for some special cases. Various
+   national functional profile specifications for an X.400 MHS states
+   that if an X.400 PRMD is reachable via any of its national ADMDs,
+   independently of its actual single or multiple connectivity with
+   them, it should use ADMD=<blank> to advertise this fact. Again, if a
+   PRMD has no connections to any ADMD it should use ADMD=0 to notify
+   its status, etc. However, in most of the current real situations, the
+   ADMD service providers do not accept messages coming from their
+
+
+
+Allocchio                   Standards Track                     [Page 9]
+
+RFC 2163                      MIXER MCGAM                   January 1998
+
+
+   subscribers if they have a blank ADMD, forcing them to have their own
+   ADMD value. In such a situation there are problems in indicating
+   properly the actually working mappings for domains with multiple
+   connectivity. The PX RDATA 'PREFERENCE' extension was introduced to
+   take in consideration these problems.
+
+   However, as these extensions are not available with MIXER static
+   tables, it is strongly discouraged to use them when interworking with
+   any table based gateway or application. The extensions were in fact
+   introduced just to add more flexibility, like the PREFERENCE value,
+    or they were already implicit in the DNS mechanism, like the
+   wildcard specification. They should be used very carefully or just
+   considered 'reserved for future use'. In particular, for current use,
+   the PREFERENCE value in the PX record specification should be fixed
+   to a value of 50, and only wildcard specifications should be used
+   when specifying <name> values.
+
+4.2 The DNS syntax for an X.400 'domain'
+
+   The syntax definition of the MCGAM rules is defined in appendix F of
+   that document. However that syntax is not very human oriented and
+   contains a number of characters which have a special meaning in other
+   fields of the Internet DNS. Thus in order to avoid any possible
+   problem, especially due to some old DNS implementations still being
+   used in the Internet, we define a syntax for the X.400 part of any
+   MCGAM rules (and hence for any X.400 O/R name) which makes it
+   compatible with a <domain-name> element, i.e.,
+
+   <domain-name>    ::= <subdomain> | " "
+   <subdomain>      ::= <label> | <label> "." <subdomain>
+   <label>          ::= <alphanum>|
+                        <alphanum> {<alphanumhyphen>} <alphanum>
+   <alphanum>       ::= "0".."9" | "A".."Z" | "a".."z"
+   <alphanumhyphen> ::= "0".."9" | "A".."Z" | "a".."z" | "-"
+
+   (see RFC1035, section 2.3.1, page 8).  The legal character set for
+   <label> does not correspond to the IA5 Printablestring one used in
+   MIXER to define MCGAM rules. However a very simple "escape mechanism"
+   can be applied in order to bypass the problem. We can in fact simply
+   describe the X.400 part of a MCGAM rule format as:
+
+     <map-rule>   ::= <map-elem> | <map-elem> { "." <map-elem> }
+     <map-elem>   ::= <attr-label> "$" <attr-value>
+     <attr-label> ::= "C" | "ADMD" | "PRMD" | "O" | "OU"
+     <attr-value> ::= " " | "@" | IA5-Printablestring
+
+
+
+
+
+
+Allocchio                   Standards Track                    [Page 10]
+
+RFC 2163                      MIXER MCGAM                   January 1998
+
+
+   As you can notice <domain-name> and <map-rule> look similar, and also
+   <label> and <map-elem> look the same. If we define the correct method
+   to transform a <map-elem> into a <label> and vice versa the problem
+   to write a MCGAM rule in <domain-name> syntax is solved.
+
+   The RFC822 domain part of any MCGAM rule is of course already in
+   <domain-name> syntax, and thus remains unchanged.
+
+   In particular, in a 'table1' or 'gate1' mapping rule the 'keyword'
+   value must be converted into <x400-in-domain-syntax> (X.400 mail DNS
+   mail domain), while the 'translator' value is already a valid RFC822
+   domain.  Vice versa in a 'table2' or 'gate2' mapping rule, the
+   'translator' must be converted into <x400-in-domain-syntax>, while
+   the 'keyword' is already a valid RFC822 domain.
+
+4.2.1 IA5-Printablestring to <alphanumhyphen> mappings
+
+   The problem of unmatching IA5-Printablestring and <label> character
+   set definition is solved by a simple character mapping rule: whenever
+   an IA5 character does not belong to <alphanumhyphen>, then it is
+   mapped using its 3 digit decimal ASCII code, enclosed in hyphens. A
+   small set of special rules is also defined for the most frequent
+   cases. Moreover some frequent characters combinations used in MIXER
+   rules are also mapped as special cases.
+
+   Let's then define the following simple rules:
+
+    MCGAM rule            DNS store translation    conditions
+    -----------------------------------------------------------------
+    <attr-label>$@        <attr-label>             missing attribute
+    <attr-label>$<blank>  <attr-label>"b"          blank attribute
+    <attr-label>$xxx      <attr-label>-xxx         elsewhere
+
+   Non <alphanumhyphen> characters in <attr-value>:
+
+    MCGAM rule            DNS store translation    conditions
+    -----------------------------------------------------------------
+    -                     -h-                      hyphen
+    \.                    -d-                      quoted dot
+    <blank>               -b-                      blank
+    <non A/N character>   -<3digit-decimal>-       elsewhere
+
+   If the DNS store translation of <attr-value> happens to end with an
+   hyphen, then this last hyphen is omitted.
+
+   Let's now have some examples:
+
+
+
+
+
+Allocchio                   Standards Track                    [Page 11]
+
+RFC 2163                      MIXER MCGAM                   January 1998
+
+
+    MCGAM rule            DNS store translation    conditions
+    -----------------------------------------------------------------
+    PRMD$@                PRMD                     missing attribute
+    ADMD$<blank>          ADMDb                    blank attribute
+    ADMD$400-net          ADMD-400-h-net           hyphen mapping
+    PRMD$UK\.BD           PRMD-UK-d-BD             quoted dot mapping
+    O$ACME Inc\.          O-ACME-b-Inc-d           blank & final hyphen
+    PRMD$main-400-a       PRMD-main-h-400-h-a      hyphen mapping
+    O$-123-b              O--h-123-h-b             hyphen mapping
+    OU$123-x              OU-123-h-x               hyphen mapping
+    PRMD$Adis+co          PRMD-Adis-043-co         3digit mapping
+
+   Thus, an X.400 part from a MCGAM like
+
+     OU$uuu.O$@.PRMD$ppp\.rrr.ADMD$aaa ddd-mmm.C$cc
+
+   translates to
+
+     OU-uuu.O.PRMD-ppp-d-rrr.ADMD-aaa-b-ddd-h-mmm.C-cc
+
+   Another example:
+
+     OU$sales dept\..O$@.PRMD$ACME.ADMD$ .C$GB
+
+   translates to
+
+     OU-sales-b-dept-d.O.PRMD-ACME.ADMDb.C-GB
+
+4.2.2 Flow chart
+
+   In order to achieve the proper DNS store translations of the X.400
+   part of a MCGAM or any other X.400 O/R name, some software tools will
+   be used. It is in fact evident that the above rules for converting
+   mapping table from MIXER to DNS format (and vice versa) are not user
+   friendly enough to think of a human made conversion.
+
+   To help in designing such tools, we describe hereunder a small flow
+   chart. The fundamental rule to be applied during translation is,
+   however, the following:
+
+      "A string must be parsed from left to right, moving appropriately
+      the pointer in order not to consider again the already translated
+      left section of the string in subsequent analysis."
+
+
+
+
+
+
+
+
+Allocchio                   Standards Track                    [Page 12]
+
+RFC 2163                      MIXER MCGAM                   January 1998
+
+
+   Flow chart 1 - Translation from MIXER to DNS format:
+
+                 parse  single attribute
+              (enclosed in "." separators)
+                           |
+            (yes)  ---  <label>$@ ?  ---  (no)
+              |                             |
+        map to <label>        (no)  <label>$<blank> ?  (yes)
+              |                 |                        |
+              |           map to <label>-        map to <label>"b"
+              |                 |                        |
+              |           map "\." to -d-                |
+              |                 |                        |
+              |           map "-" to -h-                 |
+              |                 |                        |
+              |    map non A/N char to -<3digit>-        |
+  restart     |                 |                        |
+     ^        |      remove (if any) last "-"            |
+     |        |                 |                        |
+     |        \------->     add a  "."    <--------------/
+     |                          |
+     \----------  take  next  attribute  (if  any)
+
+
+   Flow chart 2 - Translation from DNS to MIXER format:
+
+
+                parse single attribute
+            (enclosed in "." separators)
+                          |
+            (yes) ---- <label> ? ---- (no)
+              |                          |
+      map to <label>$@        (no) <label>"b" ? (yes)
+              |                 |                 |
+              |           map to <label>$    map to <label>$<blank>
+              |                 |                 |
+              |           map -d- to "\."         |
+              |                 |                 |
+              |           map -h- to "-"          |
+              |                 |                 |
+              |           map -b- to " "          |
+  restart     |                 |                 |
+     ^        |   map -<3digit>- to non A/N char  |
+     |        |                 |                 |
+     |        \-------->   add a "."   <----------/
+     |                         |
+     \------------- take next attribute (if any)
+
+
+
+
+Allocchio                   Standards Track                    [Page 13]
+
+RFC 2163                      MIXER MCGAM                   January 1998
+
+
+   Note that the above flow charts deal with the translation of the
+   attributes syntax, only.
+
+4.2.3 The Country Code convention in the <name> value.
+
+   The RFC822 domain space and the X.400 O/R address space, as said in
+   section 3, have one specific common feature: the X.400 ISO country
+   codes are the same as the RFC822 ISO top level domains for countries.
+   In the previous sections we have also defined a method to write in
+   <domain-name> syntax any X.400 domain, while in section 3 we
+   described the new name space starting at each country top level
+   domain under the X42D.cc (where 'cc' is then two letter ISO country
+   code).
+
+   The <name> value for a 'table1' or 'gate1' entry in DNS should thus
+   be derived from the X.400 domain value, translated to <domain-name>
+   syntax, adding the 'X42D.cc.' post-fix to it, i.e.,
+
+     ADMD$acme.C$fr
+
+   produces in <domain-name> syntax the key:
+
+     ADMD-acme.C-fr
+
+   which is post-fixed by 'X42D.fr.' resulting in:
+
+     ADMD-acme.C-fr.X42D.fr.
+
+   However, due to the identical encoding for X.400 country codes and
+   RFC822 country top level domains, the string 'C-fr.X42D.fr.' is
+   clearly redundant.
+
+   We thus define the 'Country Code convention' for the <name> key,
+   i.e.,
+
+     "The C-cc section of an X.400 domain in <domain-name> syntax must
+     be omitted when creating a <name> key, as it is identical to the
+     top level country code used to identify the DNS zone where the
+     information is stored".
+
+   Thus we obtain the following <name> key examples:
+
+   X.400 domain                       DNS <name> key
+   --------------------------------------------------------------------
+   ADMD$acme.C$fr                     ADMD-acme.X42D.fr.
+   PRMD$ux\.av.ADMD$ .C$gb            PRMD-ux-d-av.ADMDb.X42D.gb.
+   PRMD$ppb.ADMD$Dat 400.C$de         PRMD-ppb.ADMD-Dat-b-400.X42D.de.
+
+
+
+
+Allocchio                   Standards Track                    [Page 14]
+
+RFC 2163                      MIXER MCGAM                   January 1998
+
+
+4.3 Creating the appropriate DNS files
+
+   Using MIXER's assumption of an asymmetric mapping between X.400 and
+   RFC822 addresses, two separate relations are required to store the
+   mapping database: MIXER 'table1' and MIXER 'table2'; thus also in DNS
+   we will maintain the two different sections, even if they will both
+   use the PX resource record. More over MIXER also specify two
+   additional tables: MIXER 'gate1' and 'gate2' tables. These additional
+   tables, however, have the same syntax rules than MIXER 'table1' and
+   'table2' respectively, and thus the same translation procedure as
+   'table1' and 'table2' will be applied; some details about the MIXER
+   'gate1' and 'gate2' tables are discussed in section 4.4.
+
+   Let's now check how to create, from an MCGAM entry, the appropriate
+   DNS entry in a DNS data file. We can again define an MCGAM entry as
+   defined in appendix F of that document as:
+
+     <x400-domain>#<rfc822-domain>#  (case A: 'table1' and 'gate1'
+     entry)
+
+   and
+
+     <rfc822-domain>#<x400-domain>#  (case B: 'table2' and 'gate2'
+     entry)
+
+   The two cases must be considered separately. Let's consider case A.
+
+    - take <x400-domain> and translate it into <domain-name> syntax,
+     obtaining <x400-in-domain-syntax>;
+    - create the <name> key from <x400-in-domain-syntax> i.e., apply
+     the Country Code convention described in sect. 4.2.3;
+    - construct the DNS PX record as:
+
+      *.<name>  IN  PX  50  <rfc822-domain>  <x400-in-domain-syntax>
+
+   Please note that within PX RDATA the <rfc822-domain> precedes the
+   <x400-in-domain-syntax> also for a 'table1' and 'gate1' entry.
+
+   an example: from the 'table1' rule
+
+     PRMD$ab.ADMD$ac.C$fr#ab.fr#
+
+   we obtain
+
+     *.PRMD-ab.ADMD-ac.X42D.fr. IN PX 50  ab.fr.  PRMD-ab.ADMD-ac.C-fr.
+
+   Note that <name>, <rfc822-domain> and <x400-in-domain-syntax> are
+   fully qualified <domain-name> elements, thus ending with a ".".
+
+
+
+Allocchio                   Standards Track                    [Page 15]
+
+RFC 2163                      MIXER MCGAM                   January 1998
+
+
+   Let's now consider case B.
+
+    - take <rfc822-domain> as <name> key;
+    - translate <x400-domain> into <x400-in-domain-syntax>;
+    - construct the DNS PX record as:
+
+     *.<name>  IN  PX  50  <rfc822-domain>  <x400-in-domain-syntax>
+
+   an example: from the 'table2' rule
+
+     ab.fr#PRMD$ab.ADMD$ac.C$fr#
+
+   we obtain
+
+     *.ab.fr.  IN  PX  50  ab.fr.  PRMD-ab.ADMD-ac.C-fr.
+
+   Again note the fully qualified <domain-name> elements.
+
+   A file containing the MIXER mapping rules and MIXER 'gate1' and
+   'gate2' table written in DNS format will look like the following
+   fictious example:
+
+     !
+     ! MIXER table 1: X.400 --> RFC822
+     !
+     *.ADMD-acme.X42D.it.               IN  PX  50  it. ADMD-acme.C-it.
+     *.PRMD-accred.ADMD-tx400.X42D.it.  IN  PX  50   \
+                                accred.it. PRMD-accred.ADMD-tx400.C-it.
+     *.O-u-h-newcity.PRMD-x4net.ADMDb.X42D.it.  IN  PX  50   \
+                       cs.ncty.it. O-u-h-newcity.PRMD-x4net.ADMDb.C-it.
+     !
+     ! MIXER table 2: RFC822 --> X.400
+     !
+     *.nrc.it.    IN  PX  50   nrc.it. PRMD-nrc.ADMD-acme.C-it.
+     *.ninp.it.   IN  PX  50   ninp.it. O.PRMD-ninp.ADMD-acme.C-it.
+     *.bd.it.     IN  PX  50   bd.it. PRMD-uk-d-bd.ADMDb.C-it.
+     !
+     ! MIXER Gate 1 Table
+     !
+     *.ADMD-XKW-h-Mail.X42D.it.         IN  PX  50   \
+                            XKW-gateway.it. ADMD-XKW-h-Mail.C-it.G.
+     *.PRMD-Super-b-Inc.ADMDb.X42D.it.  IN  PX  50   \
+                            GlobalGw.it. PRMD-Super-b-Inc.ADMDb.C-it.G.
+     !
+     ! MIXER Gate 2 Table
+     !
+     my.it.  IN PX 50  my.it. OU-int-h-gw.O.PRMD-ninp.ADMD-acme.C-it.G.
+     co.it.  IN PX 50  co.it. O-mhs-h-relay.PRMD-x4net.ADMDb.C-it.G.
+
+
+
+Allocchio                   Standards Track                    [Page 16]
+
+RFC 2163                      MIXER MCGAM                   January 1998
+
+
+   (here the "\" indicates continuation on the same line, as wrapping is
+   done only due to typographical reasons).
+
+   Note the special suffix ".G." on the right side of the 'gate1' and
+   'gate2' Tables section whose aim is described in section 4.4. The
+   corresponding MIXER tables are:
+
+     #
+     # MIXER table 1: X.400 --> RFC822
+     #
+     ADMD$acme.C$it#it#
+     PRMD$accred.ADMD$tx400.C$it#accred.it#
+     O$u-newcity.PRMD$x4net.ADMD$ .C$it#cs.ncty.it#
+     #
+     # MIXER table 2: RFC822 --> X.400
+     #
+     nrc.it#PRMD$nrc.ADMD$acme.C$it#
+     ninp.it#O.PRMD$ninp.ADMD$acme.C$it#
+     bd.it#PRMD$uk\.bd.ADMD$ .C$it#
+     #
+     # MIXER Gate 1 Table
+     #
+     ADMD$XKW-Mail.C$it#XKW-gateway.it#
+     PRMD$Super Inc.ADMD$ .C$it#GlobalGw.it#
+     #
+     # MIXER Gate 2 Table
+     #
+     my.it#OU$int-gw.O$@.PRMD$ninp.ADMD$acme.C$it#
+     co.it#O$mhs-relay.PRMD$x4net.ADMD$ .C$t#
+
+4.4 Storing the MIXER 'gate1' and 'gate2' tables
+
+   Section 4.3.4 of MIXER also specify how an address should be
+   converted between RFC822 and X.400 in case a complete mapping is
+   impossible. To allow the use of DDAs for non mappable domains, the
+   MIXER 'gate2' table is thus introduced.
+
+   In a totally similar way, when an X.400 address cannot be completely
+   converted in RFC822, section 4.3.5 of MIXER specifies how to encode
+   (LHS encoding) the address itself, pointing then to the appropriate
+   MIXER conformant gateway, indicated in the MIXER 'gate1' table.
+
+   DNS must store and distribute also these 'gate1' and 'gate2' data.
+
+   One of the major features of the DNS is the ability to distribute the
+   authority: a certain site runs the "primary" nameserver for one
+   determined sub-tree and thus it is also the only place allowed to
+   update information regarding that sub-tree. This fact allows, in our
+
+
+
+Allocchio                   Standards Track                    [Page 17]
+
+RFC 2163                      MIXER MCGAM                   January 1998
+
+
+   case, a further additional feature to the table based approach. In
+   fact we can avoid one possible ambiguity about the use of the 'gate1'
+   and 'gate2' tables (and thus of LHS and DDAs encoding).
+
+   The authority maintaining a DNS entry in the usual RFC822 domain
+   space is the only one allowed to decide if its domain should be
+   mapped using Standard Attributes (SA) syntax or Domain Defined
+   Attributes (DDA) one. If the authority decides that its RFC822 domain
+   should be mapped using SA, then the PX RDATA will be a 'table2'
+   entry, otherwise it will be a 'gate2' table entry. Thus for an RFC822
+   domain we cannot have any more two possible entries, one from 'table2
+   and another one from 'gate2' table, and the action for a gateway
+   results clearly stated.
+
+   Similarly, the authority mantaining a DNS entry in the new X.400 name
+   space is the only one allowed to decide if its X.400 domain should be
+   mapped using SA syntax or Left Hand Side (LHS) encoding. If the
+   authority decides that its X.400 domain should be mapped using SA,
+   then the PX RDATA will be a 'table1' entry, otherwise it will be a
+   'gate1' table entry. Thus also for an X.400 domain we cannot have any
+   more two possible entries, one from 'table1' and another one from
+   'gate1' table, and the action for a gateway results clearly stated.
+
+   The MIXER 'gate1' table syntax is actually identical to MIXER
+   'table1', and 'gate2' table syntax is identical to MIXER 'table2'.
+   Thus the same syntax translation rules from MIXER to DNS format can
+   be applied in both cases. However a gateway or any other application
+   must know if the answer it got from DNS contains some 'table1',
+   'table2' or some 'gate1', 'gate2' table information. This is easily
+   obtained flagging with an additional ".G." post-fix the PX RDATA
+   value when it contains a 'gate1' or 'gate2' table entry. The example
+   in section 4.3 shows clearly the result. As any X.400 O/R domain must
+   end with a country code ("C-xx" in our DNS syntax) the additional
+   ".G." creates no conflicts or ambiguities at all. This postfix must
+   obviously be removed before using the MIXER 'gate1' or 'gate2' table
+   data.
+
+5. Finding MIXER mapping information from DNS
+
+   The MIXER mapping information is stored in DNS both in the normal
+   RFC822 domain name space, and in the newly defined X.400 name space.
+   The information, stored in PX resource records, does not represent a
+   full RFC822 or X.400 O/R address: it is a template which specifies
+   the fields of the domain that are used by the mapping algorithm.
+
+   When mapping information is stored in the DNS, queries to the DNS are
+   issued whenever an iterative search through the mapping table would
+   be performed (MIXER: section 4.3.4, State I; section 4.3.5, mapping
+
+
+
+Allocchio                   Standards Track                    [Page 18]
+
+RFC 2163                      MIXER MCGAM                   January 1998
+
+
+   B). Due to the DNS search mechanism, DNS by itself returns the
+   longest possible match in the stored mapping rule with a single
+   query, thus no iteration and/or multiple queries are needed. As
+   specified in MIXER, a search of the mapping table will result in
+   either success (mapping found) or failure (query failed, mapping not
+   found).
+
+   When a DNS query is issued, a third possible result is timeout. If
+   the result is timeout, the gateway operation is delayed and then
+   retried at a later time. A result of success or failure is processed
+   according to the algorithms specified in MIXER. If a DNS error code
+   is returned, an error message should be logged and the gateway
+   operation is delayed as for timeout. These pathological situations,
+   however, should be avoided with a careful duplication and chaching
+   mechanism which DNS itself provides.
+
+   Searching the nameserver which can authoritatively solve the query is
+   automatically performed by the DNS distributed name service.
+
+5.1 A DNS query example
+
+   An MIXER mail-gateway located in the Internet, when translating
+   addresses from RFC822 to X.400, can get information about the MCGAM
+   rule asking the DNS. As an example, when translating the address
+   SUN.CCE.NRC.IT, the gateway will just query DNS for the associated PX
+   resource record. The DNS should contain a PX record like this:
+
+   *.cce.nrc.it.  IN PX 50   cce.nrc.it.  O-cce.PRMD-nrc.ADMD-acme.C-it.
+
+   The first query will return immediately the appropriate mapping rule
+   in DNS store format.
+
+   There is no ".G." at the end of the obtained PX RDATA value, thus
+   applying the syntax translation specified in paragraph 4.2 the MIXER
+   Table 2 mapping rule will be obtained.
+
+   Let's now take another example where a 'gate2' table rule is
+   returned.  If we are looking for an RFC822 domain ending with top
+   level domain "MW", and the DNS contains a PX record like this,
+
+      *.mw.   IN  PX  50  mw.  O-cce.PRMD-nrc.ADMD-acme.C-it.G.
+
+   DNS will return 'mw.' and 'O-cce.PRMD-nrc.ADMD-acme.C-it.G.', i.e., a
+   'gate2' table entry in DNS store format. Dropping the final ".G." and
+   applying the syntax translation specified in paragraph 4.2 the
+   original rule will be available. More over, the ".G." flag also tells
+   the gateway to use DDA encoding for the inquired RFC822 domain.
+
+
+
+
+Allocchio                   Standards Track                    [Page 19]
+
+RFC 2163                      MIXER MCGAM                   January 1998
+
+
+   On the other hand, translating from X.400 to RFC822 the address
+
+      C=de; ADMD=pkz; PRMD=nfc; O=top;
+
+   the mail gateway should convert the syntax according to paragraph
+   4.2, apply the 'Country code convention' described in 4.2.3 to derive
+   the appropriate DNS translation of the X.400 O/R name and then query
+   DNS for the corresponding PX resource record. The obtained record for
+   which the PX record must be queried is thus:
+
+      O-top.PRMD-nfc.ADMD-pkz.X42D.de.
+
+   The DNS could contain:
+
+      *.ADMD-pkz.X42D.de.  IN  PX  50  pkz.de.  ADMD-pkz.C-de.
+
+   Assuming that there are not more specific records in DNS, the
+   wildcard mechanism will return the MIXER 'table1' rule in encoded
+   format.
+
+   Finally, an example where a 'gate1' rule is involved. If we are
+   looking for an X.400 domain ending with ADMD=PWT400; C=US; , and the
+   DNS contains a PX record like this,
+
+      *.ADMD-PWT400.X42D.us.  IN  PX  50  intGw.com. ADMD-PWT400.C-us.G.
+
+   DNS will return 'intGw.com.' and 'ADMD-PWT400.C-us.G.', i.e., a
+   'gate1' table entry in DNS store format. Dropping the final ".G." and
+   applying the syntax translation specified in paragraph 4.2 the
+   original rule will be available. More over, the ".G." flag also tells
+   the gateway to use LHS encoding for the inquired X.400 domain.
+
+6. Administration of mapping information
+
+   The DNS, using the PX RR, is able to distribute the MCGAM rules to
+   all MIXER gateways located on the Internet. However, not all MIXER
+   gateways will be able to use the Internet DNS. It is expected that
+   some gateways in a particular management domain will conform to one
+   of the following models:
+
+     (a) Table-based, (b) DNS-based, (c) X.500-based
+
+   Table-based management domains will continue to publish their MCGAM
+   rules and retrieve the mapping tables via the International Mapping
+   Table coordinator, manually or via some automated procedures. Their
+   MCGAM information can be made available also in DNS by the
+   appropriate DNS authorities, using the same mechanism already in
+   place for MX records: if a branch has not yet in place its own DNS
+
+
+
+Allocchio                   Standards Track                    [Page 20]
+
+RFC 2163                      MIXER MCGAM                   January 1998
+
+
+   server, some higher authority in the DNS tree will provide the
+   service for it. A transition procedure similar to the one used to
+   migrate from the 'hosts.txt' tables to DNS can be applied also to the
+   deployment phase of this specification. An informational document
+   describing the implementation phase and the detailed coordination
+   procedures is expected.
+
+   Another distributed directory service which can distribute the MCGAM
+   information is X.500. Coordination with table-based domains can be
+   obtained in an identical way as for the DNS case.
+
+   Coordination of MCGAM information between DNS and X.500 is more
+   complex, as it requies some kind of uploading information between the
+   two systems. The ideal solution is a dynamic alignment mechanism
+   which transparently makes the DNS mapping information available in
+   X.500 and vice versa. Some work in this specific field is already
+   being done [see Costa] which can result in a global transparent
+   directory service, where the information is stored in DNS or in
+   X.500, but is visible completely by any of the two systems.
+
+   However we must remind that MIXER concept of MCGAM rules publication
+   is different from the old RFC1327 concept of globally distributed,
+   coordinated and unique mapping rules. In fact MIXER does not requires
+   any more for any conformant gateway or tool to know the complete set
+   of MCGAM: it only requires to use some set (eventually empty) of
+   valid MCGAM rules, published either by Tables, DNS or X.500
+   mechanisms or any combination of these methods. More over MIXER
+   specifies that also incomplete sets of MCGAM can be used, and
+   supplementary local unpublished (but valid) MCGAM can also be used.
+   As a consequence, the problem of coordination between the three
+   systems proposed by MIXER for MCGAM publication is non essential, and
+   important only for efficient operational matters. It does not in fact
+   affect the correct behaviour of MIXER conformant gateways and tools.
+
+7. Conclusion
+
+   The introduction of the new PX resource record and the definition of
+   the X.400 O/R name space in the DNS structure provide a good
+   repository for MCGAM information. The mapping information is stored
+   in the DNS tree structure so that it can be easily obtained using the
+   DNS distributed name service. At the same time the definition of the
+   appropriate DNS space for X.400 O/R names provide a repository where
+   to store and distribute some other X.400 MHS information. The use of
+   the DNS has many known advantages in storing, managing and updating
+   the information. A successful number of tests were been performed
+   under the provisional top level domain "X400.IT" when RFC1664 was
+   developed, and their results confirmed the advantages of the method.
+   Operational exeprience for over 2 years with RFC1664 specification
+
+
+
+Allocchio                   Standards Track                    [Page 21]
+
+RFC 2163                      MIXER MCGAM                   January 1998
+
+
+   confirmed the feasibility of the method, and helped identifying some
+   operational procedures to deploy the insertion of MCGAM into DNS.
+
+   Software to query the DNS and then to convert between the textual
+   representation of DNS resource records and the address format defined
+   in MIXER was developed with RFC1664. This software also allows a
+   smooth implementation and deployment period, eventually taking care
+   of the transition phase. This software can be easily used (with
+   little or null modification) also for this updated specification,
+   supporting the new 'gate1' MIXER table. DNS software implementations
+   supporting RFC1664 also supports with no modification this memo new
+   specification.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Allocchio                   Standards Track                    [Page 22]
+
+RFC 2163                      MIXER MCGAM                   January 1998
+
+
+   A further informational document describing operational and
+   implementation of the service is expected.
+
+8. Acknowledgements
+
+   We wish to thanks all those who contributed to the discussion and
+   revision of this document: many of their ideas and suggestions
+   constitute essential parts of this work. In particular thanks to Jon
+   Postel, Paul Mockapetris, Rob Austin and the whole IETF x400ops,
+   TERENA wg-msg and IETF namedroppers groups. A special mention to
+   Christian Huitema for his fundamental contribution to this work.
+
+   This document is a revision of RFC1664, edited by one of its authors
+   on behalf of the IETF MIXER working group. The current editor wishes
+   to thank here also the authors of RFC1664:
+
+     Antonio Blasco Bonito     RFC822: bonito@cnuce.cnr.it
+     CNUCE - CNR               X.400:  C=it;A=garr;P=cnr;
+     Reparto infr. reti                O=cnuce;S=bonito;
+     Viale S. Maria 36
+     I 56126 Pisa
+     Italy
+
+
+     Bruce Cole                RFC822: bcole@cisco.com
+     Cisco Systems Inc.        X.400:  C=us;A= ;P=Internet;
+     P.O. Box 3075                     DD.rfc-822=bcole(a)cisco.com;
+     1525 O'Brien Drive
+     Menlo Park, CA 94026
+     U.S.A.
+
+
+     Silvia Giordano           RFC822: giordano@cscs.ch
+     Centro Svizzero di        X.400:  C=ch;A=arcom;P=switch;O=cscs;
+     Calcolo Scientifico               S=giordano;
+     Via Cantonale
+     CH 6928 Manno
+     Switzerland
+
+
+     Robert Hagens                   RFC822: hagens@ans.net
+     Advanced Network and Services   X.400:  C=us;A= ;P=Internet;
+     1875 Campus Commons Drive               DD.rfc-822=hagens(a)ans.net;
+     Reston, VA 22091
+     U.S.A.
+
+
+
+
+
+
+Allocchio                   Standards Track                    [Page 23]
+
+RFC 2163                      MIXER MCGAM                   January 1998
+
+
+9. References
+
+   [CCITT] CCITT SG 5/VII, "Recommendation X.400, Message Handling
+       Systems: System Model - Service Elements", October 1988.
+
+   [RFC 1327] Kille, S., "Mapping between X.400(1988)/ISO 10021 and RFC
+       822", RFC 1327, March 1992.
+
+   [RFC 1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
+       STD 13, RFC 1034, USC/Information Sciences Institute, November
+       1987.
+
+   [RFC 1035] Mockapetris, P., "Domain names - Implementation and
+       Specification", STD 13, RFC 1035, USC/Information Sciences
+       Institute, November 1987.
+
+   [RFC 1033] Lottor, M., "Domain Administrators Operation Guide", RFC
+       1033, SRI International, November 1987.
+
+   [RFC 2156] Kille, S. E., " MIXER (Mime Internet X.400 Enhanced
+       Relay): Mapping between X.400 and RFC 822/MIME", RFC 2156,
+       January 1998.
+
+   [Costa] Costa, A., Macedo, J., and V. Freitas, "Accessing and
+       Managing DNS Information in the X.500 Directory", Proceeding of
+       the 4th Joint European Networking Conference, Trondheim, NO, May
+       1993.
+
+10. Security Considerations
+
+   This document specifies a means by which DNS "PX" records can direct
+   the translation between X.400 and Internet mail addresses.
+
+   This can indirectly affect the routing of mail across an gateway
+   between X.400 and Internet Mail.  A succesful attack on this service
+   could cause incorrect translation of an originator address (thus
+   "forging" the originator address), or incorrect translation of a
+   recipient address (thus directing the mail to an unauthorized
+   recipient, or making it appear to an authorized recipient, that the
+   message was intended for recipients other than those chosen by the
+   originator) or could force the mail path via some particular gateway
+   or message transfer agent where mail security can be affected by
+   compromised software.
+
+
+
+
+
+
+
+
+Allocchio                   Standards Track                    [Page 24]
+
+RFC 2163                      MIXER MCGAM                   January 1998
+
+
+   There are several means by which an attacker might be able to deliver
+   incorrect PX records to a client.  These include: (a) compromise of a
+   DNS server,  (b) generating a counterfeit response to a client's DNS
+   query, (c) returning incorrect "additional information" in response
+   to an unrelated query.
+
+   Clients using PX records SHOULD ensure that routing and address
+   translations are based only on authoritative answers.  Once DNS
+   Security mechanisms [RFC 2065] become more widely deployed, clients
+   SHOULD employ those mechanisms to verify the authenticity and
+   integrity of PX records.
+
+11. Author's Address
+
+   Claudio Allocchio
+   Sincrotrone Trieste
+   SS 14 Km 163.5 Basovizza
+   I 34012 Trieste
+   Italy
+
+   RFC822: Claudio.Allocchio@elettra.trieste.it
+   X.400:  C=it;A=garr;P=Trieste;O=Elettra;
+   S=Allocchio;G=Claudio;
+   Phone:  +39 40 3758523
+   Fax:    +39 40 3758565
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Allocchio                   Standards Track                    [Page 25]
+
+RFC 2163                      MIXER MCGAM                   January 1998
+
+
+12.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (1998).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Allocchio                   Standards Track                    [Page 26]
+
diff --git a/doc/rfc/rfc2168.txt b/doc/rfc/rfc2168.txt
new file mode 100644
index 0000000..3eed1bd
--- /dev/null
+++ b/doc/rfc/rfc2168.txt
@@ -0,0 +1,1123 @@
+
+
+
+
+
+
+Network Working Group                                       R. Daniel
+Request for Comments: 2168             Los Alamos National Laboratory
+Category: Experimental                                    M. Mealling
+                                              Network Solutions, Inc.
+                                                            June 1997
+
+
+               Resolution of Uniform Resource Identifiers
+                      using the Domain Name System
+
+Status of this Memo
+===================
+
+   This memo defines an Experimental Protocol for the Internet
+   community.  This memo does not specify an Internet standard of any
+   kind.  Discussion and suggestions for improvement are requested.
+   Distribution of this memo is unlimited.
+
+Abstract:
+=========
+
+   Uniform Resource Locators (URLs) are the foundation of the World Wide
+   Web, and are a vital Internet technology. However, they have proven
+   to be brittle in practice. The basic problem is that URLs typically
+   identify a particular path to a file on a particular host. There is
+   no graceful way of changing the path or host once the URL has been
+   assigned. Neither is there a graceful way of replicating the resource
+   located by the URL to achieve better network utilization and/or fault
+   tolerance. Uniform Resource Names (URNs) have been hypothesized as a
+   adjunct to URLs that would overcome such problems. URNs and URLs are
+   both instances of a broader class of identifiers known as Uniform
+   Resource Identifiers (URIs).
+
+   The requirements document for URN resolution systems[15] defines the
+   concept of a "resolver discovery service". This document describes
+   the first, experimental, RDS. It is implemented by a new DNS Resource
+   Record, NAPTR (Naming Authority PoinTeR), that provides rules for
+   mapping parts of URIs to domain names.  By changing the mapping
+   rules, we can change the host that is contacted to resolve a URI.
+   This will allow a more graceful handling of URLs over long time
+   periods, and forms the foundation for a new proposal for Uniform
+   Resource Names.
+
+
+
+
+
+
+
+
+
+Daniel & Mealling             Experimental                      [Page 1]
+
+RFC 2168            Resolution of URIs Using the DNS           June 1997
+
+
+   In addition to locating resolvers, the NAPTR provides for other
+   naming systems to be grandfathered into the URN world, provides
+   independence between the name assignment system and the resolution
+   protocol system, and allows multiple services (Name to Location, Name
+   to Description, Name to Resource, ...) to be offered.  In conjunction
+   with the SRV RR, the NAPTR record allows those services to be
+   replicated for the purposes of fault tolerance and load balancing.
+
+Introduction:
+=============
+
+   Uniform Resource Locators have been a significant advance in
+   retrieving Internet-accessible resources. However, their  brittle
+   nature over time has been recognized for several years. The Uniform
+   Resource Identifier working group proposed the development of Uniform
+   Resource Names to serve as persistent, location-independent
+   identifiers for Internet resources in order to overcome most of the
+   problems with URLs. RFC-1737 [1] sets forth requirements on URNs.
+
+   During the lifetime of the URI-WG, a number of URN proposals were
+   generated. The developers of several of those proposals met in a
+   series of meetings, resulting in a compromise known as the Knoxville
+   framework.  The major principle behind the Knoxville framework is
+   that the resolution system must be separate from the way names are
+   assigned. This is in marked contrast to most URLs, which identify the
+   host to contact and the protocol to use. Readers are referred to [2]
+   for background on the Knoxville framework and for additional
+   information on the context and purpose of this proposal.
+
+   Separating the way names are resolved from the way they are
+   constructed provides several benefits. It allows multiple naming
+   approaches and resolution approaches to compete, as it allows
+   different protocols and resolvers to be used. There is just one
+   problem with such a separation - how do we resolve a name when it
+   can't give us directions to its resolver?
+
+   For the short term, DNS is the obvious candidate for the resolution
+   framework, since it is widely deployed and understood. However, it is
+   not appropriate to use DNS to maintain information on a per-resource
+   basis. First of all, DNS was never intended to handle that many
+   records. Second, the limited record size is inappropriate for catalog
+   information. Third, domain names are not appropriate as URNs.
+
+   Therefore our approach is to use DNS to locate "resolvers" that can
+   provide information on individual resources, potentially including
+   the resource itself. To accomplish this, we "rewrite" the URI into a
+   domain name following the rules provided in NAPTR records. Rewrite
+   rules provide considerable power, which is important when trying to
+
+
+
+Daniel & Mealling             Experimental                      [Page 2]
+
+RFC 2168            Resolution of URIs Using the DNS           June 1997
+
+
+   meet the goals listed above. However, collections of rules can become
+   difficult to understand. To lessen this problem, the NAPTR rules are
+   *always* applied to the original URI, *never* to the output of
+   previous rules.
+
+   Locating a resolver through the rewrite procedure may take multiple
+   steps, but the beginning is always the same. The start of the URI is
+   scanned to extract its colon-delimited prefix. (For URNs, the prefix
+   is always "urn:" and we extract the following colon-delimited
+   namespace identifier [3]). NAPTR resolution begins by taking the
+   extracted string, appending the well-known suffix ".urn.net", and
+   querying the DNS for NAPTR records at that domain name.  Based on the
+   results of this query, zero or more additional DNS queries may be
+   needed to locate resolvers for the URI. The details of the
+   conversation between the client and the resolver thus located are
+   outside the bounds of this draft. Three brief examples of this
+   procedure are given in the next section.
+
+   The NAPTR RR provides the level of indirection needed to keep the
+   naming system independent of the resolution system, its protocols,
+   and services.  Coupled with the new SRV resource record proposal[4]
+   there is also the potential for replicating the resolver on multiple
+   hosts, overcoming some of the most significant problems of URLs. This
+   is an important and subtle point. Not only do the NAPTR and SRV
+   records allow us to replicate the resource, we can replicate the
+   resolvers that know about the replicated resource. Preventing a
+   single point of failure at the resolver level is a significant
+   benefit. Separating the resolution procedure from the way names are
+   constructed has additional benefits.  Different resolution procedures
+   can be used over time, and resolution procedures that are determined
+   to be useful can be extended to deal with additional namespaces.
+
+Caveats
+=======
+
+   The NAPTR proposal is the first resolution procedure to be considered
+   by the URN-WG. There are several concerns about the proposal which
+   have motivated the group to recommend it for publication as an
+   Experimental rather than a standards-track RFC.
+
+   First, URN resolution is new to the IETF and we wish to gain
+   operational experience before recommending any procedure for the
+   standards track. Second, the NAPTR proposal is based on DNS and
+   consequently inherits concerns about security and administration. The
+   recent advancement of the DNSSEC and secure update drafts to Proposed
+   Standard reduce these concerns, but we wish to experiment with those
+   new capabilities in the context of URN administration.  A third area
+   of concern is the potential for a noticeable impact on the DNS.  We
+
+
+
+Daniel & Mealling             Experimental                      [Page 3]
+
+RFC 2168            Resolution of URIs Using the DNS           June 1997
+
+
+   believe that the proposal makes appropriate use of caching and
+   additional information, but it is best to go slow where the potential
+   for impact on a core system like the DNS is concerned. Fourth, the
+   rewrite rules in the NAPTR proposal are based on regular expressions.
+   Since regular expressions are difficult for humans to construct
+   correctly, concerns exist about the usability and maintainability of
+   the rules. This is especially true where international character sets
+   are concerned. Finally, the URN-WG is developing a requirements
+   document for URN Resolution Services[15], but that document is not
+   complete. That document needs to precede any resolution service
+   proposals on the standards track.
+
+Terminology
+===========
+
+   "Must" or "Shall" - Software that does not behave in the manner that
+              this document says it must is not conformant to this
+              document.
+   "Should" - Software that does not follow the behavior that this
+              document says it should may still be conformant, but is
+              probably broken in some fundamental way.
+   "May" -    Implementations may or may not provide the described
+              behavior, while still remaining conformant to this
+              document.
+
+Brief overview and examples of the NAPTR RR:
+============================================
+
+   A detailed description of the NAPTR RR will be given later, but to
+   give a flavor for the proposal we first give a simple description of
+   the record and three examples of its use.
+
+   The key fields in the NAPTR RR are order, preference, service, flags,
+   regexp, and replacement:
+
+   * The order field specifies the order in which records MUST be
+     processed when multiple NAPTR records are returned in response to a
+     single query.  A naming authority may have delegated a portion of
+     its namespace to another agency. Evaluating the NAPTR records in
+     the correct order is necessary for delegation to work properly.
+
+   * The preference field specifies the order in which records SHOULD be
+     processed when multiple NAPTR records have the same value of
+     "order".  This field lets a service provider specify the order in
+     which resolvers are contacted, so that more capable machines are
+     contacted in preference to less capable ones.
+
+
+
+
+
+Daniel & Mealling             Experimental                      [Page 4]
+
+RFC 2168            Resolution of URIs Using the DNS           June 1997
+
+
+   * The service field specifies the resolution protocol and resolution
+     service(s) that will be available if the rewrite specified by the
+     regexp or replacement fields is applied. Resolution protocols are
+     the protocols used to talk with a resolver. They will be specified
+     in other documents, such as [5]. Resolution services are operations
+     such as N2R (URN to Resource), N2L (URN to URL), N2C (URN to URC),
+     etc.  These will be discussed in the URN Resolution Services
+     document[6], and their behavior in a particular resolution protocol
+     will be given in the specification for that protocol (see [5] for a
+     concrete example).
+
+   * The flags field contains modifiers that affect what happens in the
+     next DNS lookup, typically for optimizing the process. Flags may
+     also affect the interpretation of the other fields in the record,
+     therefore, clients MUST skip NAPTR records which contain an unknown
+     flag value.
+
+   * The regexp field is one of two fields used for the rewrite rules,
+     and is the core concept of the NAPTR record. The regexp field is a
+     String containing a sed-like substitution expression. (The actual
+     grammar for the substitution expressions is given later in this
+     draft). The substitution expression is applied to the original URN
+     to determine the next domain name to be queried. The regexp field
+     should be used when the domain name to be generated is conditional
+     on information in the URI. If the next domain name is always known,
+     which is anticipated to be a common occurrence, the replacement
+     field should be used instead.
+
+   * The replacement field is the other field that may be used for the
+     rewrite rule. It is an optimization of the rewrite process for the
+     case where the next domain name is fixed instead of being
+     conditional on the content of the URI. The replacement field is a
+     domain name (subject to compression if a DNS sender knows that a
+     given recipient is able to decompress names in this RR type's RDATA
+     field). If the rewrite is more complex than a simple substitution
+     of a domain name, the replacement field should be set to . and the
+     regexp field used.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Daniel & Mealling             Experimental                      [Page 5]
+
+RFC 2168            Resolution of URIs Using the DNS           June 1997
+
+
+   Note that the client applies all the substitutions and performs all
+   lookups, they are not performed in the DNS servers. Note also that it
+   is the belief of the developers of this document that regexps should
+   rarely be used. The replacement field seems adequate for the vast
+   majority of situations. Regexps are only necessary when portions of a
+   namespace are to be delegated to different resolvers. Finally, note
+   that the regexp and replacement fields are, at present, mutually
+   exclusive. However, developers of client software should be aware
+   that a new flag might be defined which requires values in both
+   fields.
+
+Example 1
+---------
+
+   Consider a URN that uses the hypothetical DUNS namespace. DUNS
+   numbers are identifiers for approximately 30 million registered
+   businesses around the world, assigned and maintained by Dunn and
+   Bradstreet. The URN might look like:
+
+                   urn:duns:002372413:annual-report-1997
+
+   The first step in the resolution process is to find out about the
+   DUNS namespace. The namespace identifier, "duns", is extracted from
+   the URN, prepended to urn.net, and the NAPTRs for duns.urn.net looked
+   up. It might return records of the form:
+
+duns.urn.net
+;;      order pref flags service          regexp        replacement
+ IN NAPTR 100  10  "s" "dunslink+N2L+N2C" ""  dunslink.udp.isi.dandb.com
+ IN NAPTR 100  20  "s" "rcds+N2C"         ""  rcds.udp.isi.dandb.com
+ IN NAPTR 100  30  "s" "http+N2L+N2C+N2R" ""  http.tcp.isi.dandb.com
+
+   The order field contains equal values, indicating that no name
+   delegation order has to be followed. The preference field indicates
+   that the provider would like clients to use the special dunslink
+   protocol, followed by the RCDS protocol, and that HTTP is offered as
+   a last resort. All the records specify the "s" flag, which will be
+   explained momentarily.  The service fields say that if we speak
+   dunslink, we will be able to issue either the N2L or N2C requests to
+   obtain a URL or a URC (description) of the resource. The Resource
+   Cataloging and Distribution Service (RCDS)[7] could be used to get a
+   URC for the resource, while HTTP could be used to get a URL, URC, or
+   the resource itself.  All the records supply the next domain name to
+   query, none of them need to be rewritten with the aid of regular
+   expressions.
+
+
+
+
+
+
+Daniel & Mealling             Experimental                      [Page 6]
+
+RFC 2168            Resolution of URIs Using the DNS           June 1997
+
+
+   The general case might require multiple NAPTR rewrites to locate a
+   resolver, but eventually we will come to the "terminal NAPTR". Once
+   we have the terminal NAPTR, our next probe into the DNS will be for a
+   SRV or A record instead of another NAPTR. Rather than probing for a
+   non-existent NAPTR record to terminate the loop, the flags field is
+   used to indicate a terminal lookup. If it has a value of "s", the
+   next lookup should be for SRV RRs, "a" denotes that A records should
+   sought.  A "p" flag is also provided to indicate that the next action
+   is Protocol-specific, but that looking up another NAPTR will not be
+   part of it.
+
+   Since our example RR specified the "s" flag, it was terminal.
+   Assuming our client does not know the dunslink protocol, our next
+   action is to lookup SRV RRs for rcds.udp.isi.dandb.com, which will
+   tell us hosts that can provide the necessary resolution service. That
+   lookup might return:
+
+    ;;                          Pref Weight Port Target
+    rcds.udp.isi.dandb.com IN SRV 0    0    1000 defduns.isi.dandb.com
+                           IN SRV 0    0    1000 dbmirror.com.au
+                           IN SRV 0    0    1000 ukmirror.com.uk
+
+   telling us three hosts that could actually do the resolution, and
+   giving us the port we should use to talk to their RCDS server.  (The
+   reader is referred to the SRV proposal [4] for the interpretation of
+   the fields above).
+
+   There is opportunity for significant optimization here. We can return
+   the SRV records as additional information for terminal NAPTRs (and
+   the A records as additional information for those SRVs). While this
+   recursive provision of additional information is not explicitly
+   blessed in the DNS specifications, it is not forbidden, and BIND does
+   take advantage of it [8]. This is a significant optimization. In
+   conjunction with a long TTL for *.urn.net records, the average number
+   of probes to DNS for resolving DUNS URNs would approach one.
+   Therefore, DNS server implementors SHOULD provide additional
+   information with NAPTR responses. The additional information will be
+   either SRV or A records.  If SRV records are available, their A
+   records should be provided as recursive additional information.
+
+   Note that the example NAPTR records above are intended to represent
+   the reply the client will see. They are not quite identical to what
+   the domain administrator would put into the zone files. For one
+   thing, the administrator should supply the trailing '.' character on
+   any FQDNs.
+
+
+
+
+
+
+Daniel & Mealling             Experimental                      [Page 7]
+
+RFC 2168            Resolution of URIs Using the DNS           June 1997
+
+
+Example 2
+---------
+
+   Consider a URN namespace based on MIME Content-Ids. The URN might
+   look like this:
+
+                 urn:cid:199606121851.1@mordred.gatech.edu
+
+   (Note that this example is chosen for pedagogical purposes, and does
+   not conform to the recently-approved CID URL scheme.)
+
+   The first step in the resolution process is to find out about the CID
+   namespace. The namespace identifier, cid, is extracted from the URN,
+   prepended to urn.net, and the NAPTR for cid.urn.net looked up. It
+   might return records of the form:
+
+ cid.urn.net
+  ;;       order pref flags service        regexp           replacement
+   IN NAPTR 100   10   ""  ""  "/urn:cid:.+@([^\.]+\.)(.*)$/\2/i"    .
+
+   We have only one NAPTR response, so ordering the responses is not a
+   problem.  The replacement field is empty, so we check the regexp
+   field and use the pattern provided there. We apply that regexp to the
+   entire URN to see if it matches, which it does.  The \2 part of the
+   substitution expression returns the string "gatech.edu". Since the
+   flags field does not contain "s" or "a", the lookup is not terminal
+   and our next probe to DNS is for more NAPTR records:
+   lookup(query=NAPTR, "gatech.edu").
+
+   Note that the rule does not extract the full domain name from the
+   CID, instead it assumes the CID comes from a host and extracts its
+   domain.  While all hosts, such as mordred, could have their very own
+   NAPTR, maintaining those records for all the machines at a site as
+   large as Georgia Tech would be an intolerable burden. Wildcards are
+   not appropriate here since they only return results when there is no
+   exactly matching names already in the system.
+
+   The record returned from the query on "gatech.edu" might look like:
+
+gatech.edu IN NAPTR
+;;       order pref flags service           regexp  replacement
+  IN NAPTR 100  50  "s"  "z3950+N2L+N2C"     ""    z3950.tcp.gatech.edu
+  IN NAPTR 100  50  "s"  "rcds+N2C"          ""    rcds.udp.gatech.edu
+  IN NAPTR 100  50  "s"  "http+N2L+N2C+N2R"  ""    http.tcp.gatech.edu
+
+
+
+
+
+
+
+Daniel & Mealling             Experimental                      [Page 8]
+
+RFC 2168            Resolution of URIs Using the DNS           June 1997
+
+
+   Continuing with our example, we note that the values of the order and
+   preference fields are equal in all records, so the client is free to
+   pick any record. The flags field tells us that these are the last
+   NAPTR patterns we should see, and after the rewrite (a simple
+   replacement in this case) we should look up SRV records to get
+   information on the hosts that can provide the necessary service.
+
+   Assuming we prefer the Z39.50 protocol, our lookup might return:
+
+   ;;                        Pref Weight   Port Target
+   z3950.tcp.gatech.edu IN SRV 0    0      1000 z3950.gatech.edu
+                        IN SRV 0    0      1000 z3950.cc.gatech.edu
+                        IN SRV 0    0      1000 z3950.uga.edu
+
+   telling us three hosts that could actually do the resolution, and
+   giving us the port we should use to talk to their Z39.50 server.
+
+   Recall that the regular expression used \2 to extract a domain name
+   from the CID, and \. for matching the literal '.' characters
+   seperating the domain name components. Since '\' is the escape
+   character, literal occurances of a backslash must be escaped by
+   another backslash. For the case of the cid.urn.net record above, the
+   regular expression entered into the zone file should be
+   "/urn:cid:.+@([^\\.]+\\.)(.*)$/\\2/i".  When the client code actually
+   receives the record, the pattern will have been converted to
+   "/urn:cid:.+@([^.]+\.)(.*)$/\2/i".
+
+Example 3
+---------
+
+   Even if URN systems were in place now, there would still be a
+   tremendous number of URLs.  It should be possible to develop a URN
+   resolution system that can also provide location independence for
+   those URLs.  This is related to the requirement in [1] to be able to
+   grandfather in names from other naming systems, such as ISO Formal
+   Public Identifiers, Library of Congress Call Numbers, ISBNs, ISSNs,
+   etc.
+
+   The NAPTR RR could also be used for URLs that have already been
+   assigned.  Assume we have the URL for a very popular piece of
+   software that the publisher wishes to mirror at multiple sites around
+   the world:
+
+        http://www.foo.com/software/latest-beta.exe
+
+
+
+
+
+
+
+Daniel & Mealling             Experimental                      [Page 9]
+
+RFC 2168            Resolution of URIs Using the DNS           June 1997
+
+
+   We extract the prefix, "http", and lookup NAPTR records for
+   http.urn.net. This might return a record of the form
+
+   http.urn.net IN NAPTR
+   ;;  order   pref flags service      regexp             replacement
+        100     90   ""      ""   "!http://([^/:]+)!\1!i"       .
+
+   This expression returns everything after the first double slash and
+   before the next slash or colon. (We use the '!' character to delimit
+   the parts of the substitution expression. Otherwise we would have to
+   use backslashes to escape the forward slashes, and would have a
+   regexp in the zone file that looked like
+   "/http:\\/\\/([^\\/:]+)/\\1/i".).
+
+   Applying this pattern to the URL extracts "www.foo.com". Looking up
+   NAPTR records for that might return:
+
+   www.foo.com
+   ;;       order pref flags   service  regexp     replacement
+    IN NAPTR 100  100  "s"   "http+L2R"   ""    http.tcp.foo.com
+    IN NAPTR 100  100  "s"   "ftp+L2R"    ""    ftp.tcp.foo.com
+
+   Looking up SRV records for http.tcp.foo.com would return information
+   on the hosts that foo.com has designated to be its mirror sites. The
+   client can then pick one for the user.
+
+NAPTR RR Format
+===============
+
+   The format of the NAPTR RR is given below. The DNS type code for
+   NAPTR is 35.
+
+       Domain TTL Class Order Preference Flags Service Regexp
+       Replacement
+
+   where:
+
+   Domain
+          The domain name this resource record refers to.
+   TTL
+          Standard DNS Time To Live field
+   Class
+          Standard DNS meaning
+
+
+
+
+
+
+
+
+Daniel & Mealling             Experimental                     [Page 10]
+
+RFC 2168            Resolution of URIs Using the DNS           June 1997
+
+
+   Order
+          A 16-bit integer specifying the order in which the NAPTR
+          records MUST be processed to ensure correct delegation of
+          portions of the namespace over time. Low numbers are processed
+          before high numbers, and once a NAPTR is found that "matches"
+          a URN, the client MUST NOT consider any NAPTRs with a higher
+          value for order.
+
+   Preference
+          A 16-bit integer which specifies the order in which NAPTR
+          records with equal "order" values SHOULD be processed, low
+          numbers being processed before high numbers.  This is similar
+          to the preference field in an MX record, and is used so domain
+          administrators can direct clients towards more capable hosts
+          or lighter weight protocols.
+
+   Flags
+          A String giving flags to control aspects of the rewriting and
+          interpretation of the fields in the record. Flags are single
+          characters from the set [A-Z0-9]. The case of the alphabetic
+          characters is not significant.
+
+          At this time only three flags, "S", "A", and "P", are defined.
+          "S" means that the next lookup should be for SRV records
+          instead of NAPTR records. "A" means that the next lookup
+          should be for A records. The "P" flag says that the remainder
+          of the resolution shall be carried out in a Protocol-specific
+          fashion, and we should not do any more DNS queries.
+
+          The remaining alphabetic flags are reserved. The numeric flags
+          may be used for local experimentation. The S, A, and P flags
+          are all mutually exclusive, and resolution libraries MAY
+          signal an error if more than one is given. (Experimental code
+          and code for assisting in the creation of NAPTRs would be more
+          likely to signal such an error than a client such as a
+          browser). We anticipate that multiple flags will be allowed in
+          the future, so implementers MUST NOT assume that the flags
+          field can only contain 0 or 1 characters. Finally, if a client
+          encounters a record with an unknown flag, it MUST ignore it
+          and move to the next record. This test takes precedence even
+          over the "order" field. Since flags can control the
+          interpretation placed on fields, a novel flag might change the
+          interpretation of the regexp and/or replacement fields such
+          that it is impossible to determine if a record matched a URN.
+
+
+
+
+
+
+
+Daniel & Mealling             Experimental                     [Page 11]
+
+RFC 2168            Resolution of URIs Using the DNS           June 1997
+
+
+   Service
+          Specifies the resolution service(s) available down this
+          rewrite path. It may also specify the particular protocol that
+          is used to talk with a resolver. A protocol MUST be specified
+          if the flags field states that the NAPTR is terminal. If a
+          protocol is specified, but the flags field does not state that
+          the NAPTR is terminal, the next lookup MUST be for a NAPTR.
+          The client MAY choose not to perform the next lookup if the
+          protocol is unknown, but that behavior MUST NOT be relied
+          upon.
+
+          The service field may take any of the values below (using the
+          Augmented BNF of RFC 822[9]):
+
+           service_field = [ [protocol] *("+" rs)]
+           protocol      = ALPHA *31ALPHANUM
+           rs            = ALPHA *31ALPHANUM
+        // The protocol and rs fields are limited to 32
+        // characters and must start with an alphabetic.
+        // The current set of "known" strings are:
+        // protocol      = "rcds" / "thttp" / "hdl" / "rwhois" / "z3950"
+        // rs            = "N2L" / "N2Ls" / "N2R" / "N2Rs" / "N2C"
+        //               / "N2Ns" / "L2R" / "L2Ns" / "L2Ls" / "L2C"
+
+          i.e. an optional protocol specification followed by 0 or more
+          resolution services. Each resolution service is indicated by
+          an initial '+' character.
+
+          Note that the empty string is also a valid service field. This
+          will typically be seen at the top levels of a namespace, when
+          it is impossible to know what services and protocols will be
+          offered by a particular publisher within that name space.
+
+          At this time the known protocols are rcds[7], hdl[10] (binary,
+          UDP-based protocols),  thttp[5] (a textual, TCP-based
+          protocol), rwhois[11] (textual, UDP or TCP based), and
+          Z39.50[12] (binary, TCP-based). More will be allowed later.
+          The names of the protocols must be formed from the characters
+          [a-Z0-9]. Case of the characters is not significant.
+
+          The service requests currently allowed will be described in
+          more detail in [6], but in brief they are:
+                N2L  - Given a URN, return a URL
+                N2Ls - Given a URN, return a set of URLs
+                N2R  - Given a URN, return an instance of the resource.
+                N2Rs - Given a URN, return multiple instances of the
+                       resource, typically encoded using
+                       multipart/alternative.
+
+
+
+Daniel & Mealling             Experimental                     [Page 12]
+
+RFC 2168            Resolution of URIs Using the DNS           June 1997
+
+
+                N2C  - Given a URN, return a collection of meta-
+                       information on the named resource. The format of
+                       this response is the subject of another document.
+                N2Ns - Given a URN, return all URNs that are also
+                       identifers for the resource.
+                L2R  - Given a URL, return the resource.
+                L2Ns - Given a URL, return all the URNs that are
+                       identifiers for the resource.
+                L2Ls - Given a URL, return all the URLs for instances of
+                       of the same resource.
+                L2C  - Given a URL, return a description of the
+                       resource.
+
+          The actual format of the service request and response will be
+          determined by the resolution protocol, and is the subject for
+          other documents (e.g. [5]). Protocols need not offer all
+          services. The labels for service requests shall be formed from
+          the set of characters [A-Z0-9]. The case of the alphabetic
+          characters is not significant.
+
+   Regexp
+          A STRING containing a substitution expression that is applied
+          to the original URI in order to construct the next domain name
+          to lookup. The grammar of the substitution expression is given
+          in the next section.
+
+   Replacement
+          The next NAME to query for NAPTR, SRV, or A records depending
+          on the value of the flags field. As mentioned above, this may
+          be compressed.
+
+Substitution Expression Grammar:
+================================
+
+   The content of the regexp field is a substitution expression. True
+   sed(1) substitution expressions are not appropriate for use in this
+   application for a variety of reasons, therefore the contents of the
+   regexp field MUST follow the grammar below:
+
+subst_expr   = delim-char  ere  delim-char  repl  delim-char  *flags
+delim-char   = "/" / "!" / ... (Any non-digit or non-flag character other
+               than backslash '\'. All occurances of a delim_char in a
+               subst_expr must be the same character.)
+ere          = POSIX Extended Regular Expression (see [13], section
+               2.8.4)
+repl         = dns_str /  backref / repl dns_str  / repl backref
+dns_str      = 1*DNS_CHAR
+backref      = "\" 1POS_DIGIT
+
+
+
+Daniel & Mealling             Experimental                     [Page 13]
+
+RFC 2168            Resolution of URIs Using the DNS           June 1997
+
+
+flags        = "i"
+DNS_CHAR     = "-" / "0" / ... / "9" / "a" / ... / "z" / "A" / ... / "Z"
+POS_DIGIT    = "1" / "2" / ... / "9"  ; 0 is not an allowed backref
+value domain name (see RFC-1123 [14]).
+
+   The result of applying the substitution expression to the original
+   URI MUST result in a string that obeys the syntax for DNS host names
+   [14]. Since it is possible for the regexp field to be improperly
+   specified, such that a non-conforming host name can be constructed,
+   client software SHOULD verify that the result is a legal host name
+   before making queries on it.
+
+   Backref expressions in the repl portion of the substitution
+   expression are replaced by the (possibly empty) string of characters
+   enclosed by '(' and ')' in the ERE portion of the substitution
+   expression. N is a single digit from 1 through 9, inclusive. It
+   specifies the N'th backref expression, the one that begins with the
+   N'th '(' and continues to the matching ')'.  For example, the ERE
+                      (A(B(C)DE)(F)G)
+   has backref expressions:
+                      \1  = ABCDEFG
+                      \2  = BCDE
+                      \3  = C
+                      \4  = F
+                 \5..\9  = error - no matching subexpression
+
+   The "i" flag indicates that the ERE matching SHALL be performed in a
+   case-insensitive fashion. Furthermore, any backref replacements MAY
+   be normalized to lower case when the "i" flag is given.
+
+   The first character in the substitution expression shall be used as
+   the character that delimits the components of the substitution
+   expression.  There must be exactly three non-escaped occurrences of
+   the delimiter character in a substitution expression. Since escaped
+   occurrences of the delimiter character will be interpreted as
+   occurrences of that character, digits MUST NOT be used as delimiters.
+   Backrefs would be confused with literal digits were this allowed.
+   Similarly, if flags are specified in the substitution expression, the
+   delimiter character must not also be a flag character.
+
+
+
+
+
+
+
+
+
+
+
+
+Daniel & Mealling             Experimental                     [Page 14]
+
+RFC 2168            Resolution of URIs Using the DNS           June 1997
+
+
+Advice to domain administrators:
+================================
+
+   Beware of regular expressions. Not only are they a pain to get
+   correct on their own, but there is the previously mentioned
+   interaction with DNS. Any backslashes in a regexp must be entered
+   twice in a zone file in order to appear once in a query response.
+   More seriously, the need for double backslashes has probably not been
+   tested by all implementors of DNS servers. We anticipate that urn.net
+   will be the heaviest user of regexps. Only when delegating portions
+   of namespaces should the typical domain administrator need to use
+   regexps.
+
+   On a related note, beware of interactions with the shell when
+   manipulating regexps from the command line. Since '\' is a common
+   escape character in shells, there is a good chance that when you
+   think you are saying "\\" you are actually saying "\".  Similar
+   caveats apply to characters such as
+
+   The "a" flag allows the next lookup to be for A records rather than
+   SRV records. Since there is no place for a port specification in the
+   NAPTR record, when the "A" flag is used the specified protocol must
+   be running on its default port.
+
+   The URN Sytnax draft defines a canonical form for each URN, which
+   requires %encoding characters outside a limited repertoire. The
+   regular expressions MUST be written to operate on that canonical
+   form. Since international character sets will end up with extensive
+   use of %encoded characters, regular expressions operating on them
+   will be essentially impossible to read or write by hand.
+
+Usage
+=====
+
+   For the edification of implementers, pseudocode for a client routine
+   using NAPTRs is given below. This code is provided merely as a
+   convience, it does not have any weight as a standard way to process
+   NAPTR records. Also, as is the case with pseudocode, it has never
+   been executed and may contain logical errors. You have been warned.
+
+    //
+    // findResolver(URN)
+    // Given a URN, find a host that can resolve it.
+    //
+    findResolver(string URN) {
+      // prepend prefix to urn.net
+      sprintf(key, "%s.urn.net", extractNS(URN));
+      do {
+
+
+
+Daniel & Mealling             Experimental                     [Page 15]
+
+RFC 2168            Resolution of URIs Using the DNS           June 1997
+
+
+        rewrite_flag = false;
+        terminal = false;
+        if (key has been seen) {
+          quit with a loop detected error
+        }
+        add key to list of "seens"
+        records = lookup(type=NAPTR, key); // get all NAPTR RRs for 'key'
+
+        discard any records with an unknown value in the "flags" field.
+        sort NAPTR records by "order" field and "preference" field
+            (with "order" being more significant than "preference").
+        n_naptrs = number of NAPTR records in response.
+        curr_order = records[0].order;
+        max_order = records[n_naptrs-1].order;
+
+        // Process current batch of NAPTRs according to "order" field.
+        for (j=0; j < n_naptrs && records[j].order <= max_order; j++) {
+          if (unknown_flag) // skip this record and go to next one
+             continue;
+          newkey = rewrite(URN, naptr[j].replacement, naptr[j].regexp);
+          if (!newkey) // Skip to next record if the rewrite didn't
+             match continue;
+          // We did do a rewrite, shrink max_order to current value
+          // so that delegation works properly
+          max_order = naptr[j].order;
+          // Will we know what to do with the protocol and services
+          // specified in the NAPTR? If not, try next record.
+          if(!isKnownProto(naptr[j].services)) {
+            continue;
+          }
+          if(!isKnownService(naptr[j].services)) {
+            continue;
+          }
+
+          // At this point we have a successful rewrite and we will
+          // know how to speak the protocol and request a known
+          // resolution service. Before we do the next lookup, check
+          // some optimization possibilities.
+
+          if (strcasecmp(flags, "S")
+           || strcasecmp(flags, "P"))
+           || strcasecmp(flags, "A")) {
+             terminal = true;
+             services = naptr[j].services;
+             addnl = any SRV and/or A records returned as additional
+                     info for naptr[j].
+          }
+          key = newkey;
+
+
+
+Daniel & Mealling             Experimental                     [Page 16]
+
+RFC 2168            Resolution of URIs Using the DNS           June 1997
+
+
+          rewriteflag = true;
+          break;
+        }
+      } while (rewriteflag && !terminal);
+
+      // Did we not find our way to a resolver?
+      if (!rewrite_flag) {
+         report an error
+         return NULL;
+      }
+
+
+      // Leave rest to another protocol?
+      if (strcasecmp(flags, "P")) {
+         return key as host to talk to;
+      }
+
+      // If not, keep plugging
+      if (!addnl) { // No SRVs came in as additional info, look them up
+        srvs = lookup(type=SRV, key);
+      }
+
+      sort SRV records by preference, weight, ...
+      foreach (SRV record) { // in order of preference
+        try contacting srv[j].target using the protocol and one of the
+            resolution service requests from the "services" field of the
+            last NAPTR record.
+        if (successful)
+          return (target, protocol, service);
+          // Actually we would probably return a result, but this
+          // code was supposed to just tell us a good host to talk to.
+      }
+      die with an "unable to find a host" error;
+    }
+
+Notes:
+======
+
+     -  A client MUST process multiple NAPTR records in the order
+        specified by the "order" field, it MUST NOT simply use the first
+        record that provides a known protocol and service combination.
+
+
+
+
+
+
+
+
+
+
+Daniel & Mealling             Experimental                     [Page 17]
+
+RFC 2168            Resolution of URIs Using the DNS           June 1997
+
+
+     -  If a record at a particular order matches the URI, but the
+        client doesn't know the specified protocol and service, the
+        client SHOULD continue to examine records that have the same
+        order. The client MUST NOT consider records with a higher value
+        of order. This is necessary to make delegation of portions of
+        the namespace work.  The order field is what lets site
+        administrators say "all requests for URIs matching pattern x go
+        to server 1, all others go to server 2".
+        (A match is defined as:
+          1)  The NAPTR provides a replacement domain name
+          or
+          2) The regular expression matches the URN
+           )
+
+     -  When multiple RRs have the same "order", the client should use
+        the value of the preference field to select the next NAPTR to
+        consider. However, because of preferred protocols or services,
+        estimates of network distance and bandwidth, etc. clients may
+        use different criteria to sort the records.
+     -  If the lookup after a rewrite fails, clients are strongly
+        encouraged to report a failure, rather than backing up to pursue
+        other rewrite paths.
+     -  When a namespace is to be delegated among a set of resolvers,
+        regexps must be used. Each regexp appears in a separate NAPTR
+        RR.  Administrators should do as little delegation as possible,
+        because of limitations on the size of DNS responses.
+     -  Note that SRV RRs impose additional requirements on clients.
+
+Acknowledgments:
+=================
+
+   The editors would like to thank Keith Moore for all his consultations
+   during the development of this draft. We would also like to thank
+   Paul Vixie for his assistance in debugging our implementation, and
+   his answers on our questions. Finally, we would like to acknowledge
+   our enormous intellectual debt to the participants in the Knoxville
+   series of meetings, as well as to the participants in the URI and URN
+   working groups.
+
+References:
+===========
+
+   [1]  Sollins, Karen and Larry Masinter, "Functional Requirements
+        for Uniform Resource Names", RFC-1737, Dec. 1994.
+
+   [2]  The URN Implementors, Uniform Resource Names: A Progress Report,
+        http://www.dlib.org/dlib/february96/02arms.html, D-Lib Magazine,
+        February 1996.
+
+
+
+Daniel & Mealling             Experimental                     [Page 18]
+
+RFC 2168            Resolution of URIs Using the DNS           June 1997
+
+
+   [3]  Moats, Ryan, "URN Syntax", RFC-2141, May 1997.
+
+   [4]  Gulbrandsen, A. and P. Vixie, "A DNS RR for specifying
+        the location of services (DNS SRV)", RFC-2052, October 1996.
+
+   [5]  Daniel, Jr., Ron, "A Trivial Convention for using HTTP in URN
+        Resolution", RFC-2169, June 1997.
+
+   [6]  URN-WG, "URN Resolution Services", Work in Progress.
+
+   [7]  Moore, Keith,  Shirley Browne, Jason Cox, and Jonathan Gettler,
+        Resource Cataloging and Distribution System, Technical Report
+        CS-97-346, University of Tennessee, Knoxville, December 1996
+
+   [8]  Paul Vixie, personal communication.
+
+   [9]  Crocker, Dave H. "Standard for the Format of ARPA Internet Text
+        Messages", RFC-822, August 1982.
+
+   [10] Orth, Charles and Bill Arms; Handle Resolution Protocol
+        Specification, http://www.handle.net/docs/client_spec.html
+
+   [11] Williamson, S., M. Kosters, D. Blacka, J. Singh, K. Zeilstra,
+        "Referral Whois Protocol (RWhois)", RFC-2167, June 1997.
+
+   [12] Information Retrieval (Z39.50): Application Service Definition
+        and Protocol Specification, ANSI/NISO Z39.50-1995, July 1995.
+
+   [13] IEEE Standard for Information Technology - Portable Operating
+        System Interface (POSIX) - Part 2: Shell and Utilities (Vol. 1);
+        IEEE Std 1003.2-1992; The Institute of Electrical and
+        Electronics Engineers; New York; 1993. ISBN:1-55937-255-9
+
+   [14] Braden, R., "Requirements for Internet Hosts - Application and
+        and Support", RFC-1123, Oct. 1989.
+
+   [15] Sollins, Karen, "Requirements and a Framework for URN Resolution
+        Systems", November 1996, Work in Progress.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Daniel & Mealling             Experimental                     [Page 19]
+
+RFC 2168            Resolution of URIs Using the DNS           June 1997
+
+
+Security Considerations
+=======================
+
+   The use of "urn.net" as the registry for URN namespaces is subject to
+   denial of service attacks, as well as other DNS spoofing attacks. The
+   interactions with DNSSEC are currently being studied. It is expected
+   that NAPTR records will be signed with SIG records once the DNSSEC
+   work is deployed.
+
+   The rewrite rules make identifiers from other namespaces subject to
+   the same attacks as normal domain names. Since they have not been
+   easily resolvable before, this may or may not be considered a
+   problem.
+
+   Regular expressions should be checked for sanity, not blindly passed
+   to something like PERL.
+
+   This document has discussed a way of locating a resolver, but has not
+   discussed any detail of how the communication with the resolver takes
+   place. There are significant security considerations attached to the
+   communication with a resolver. Those considerations are outside the
+   scope of this document, and must be addressed by the specifications
+   for particular resolver communication protocols.
+
+Author Contact Information:
+===========================
+
+   Ron Daniel
+   Los Alamos National Laboratory
+   MS B287
+   Los Alamos, NM, USA, 87545
+   voice:  +1 505 665 0597
+   fax:    +1 505 665 4939
+   email:  rdaniel@lanl.gov
+
+
+   Michael Mealling
+   Network Solutions
+   505 Huntmar Park Drive
+   Herndon, VA  22070
+   voice: (703) 742-0400
+   fax: (703) 742-9552
+   email: michaelm@internic.net
+   URL: http://www.netsol.com/
+
+
+
+
+
+
+
+Daniel & Mealling             Experimental                     [Page 20]
+
diff --git a/doc/rfc/rfc2181.txt b/doc/rfc/rfc2181.txt
new file mode 100644
index 0000000..7899e1c
--- /dev/null
+++ b/doc/rfc/rfc2181.txt
@@ -0,0 +1,842 @@
+
+
+
+
+
+
+Network Working Group                                             R. Elz
+Request for Comments: 2181                       University of Melbourne
+Updates: 1034, 1035, 1123                                        R. Bush
+Category: Standards Track                                    RGnet, Inc.
+                                                               July 1997
+
+
+                Clarifications to the DNS Specification
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+1. Abstract
+
+   This document considers some areas that have been identified as
+   problems with the specification of the Domain Name System, and
+   proposes remedies for the defects identified.  Eight separate issues
+   are considered:
+
+     + IP packet header address usage from multi-homed servers,
+     + TTLs in sets of records with the same name, class, and type,
+     + correct handling of zone cuts,
+     + three minor issues concerning SOA records and their use,
+     + the precise definition of the Time to Live (TTL)
+     + Use of the TC (truncated) header bit
+     + the issue of what is an authoritative, or canonical, name,
+     + and the issue of what makes a valid DNS label.
+
+   The first six of these are areas where the correct behaviour has been
+   somewhat unclear, we seek to rectify that.  The other two are already
+   adequately specified, however the specifications seem to be sometimes
+   ignored.  We seek to reinforce the existing specifications.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Elz & Bush                  Standards Track                     [Page 1]
+
+RFC 2181        Clarifications to the DNS Specification        July 1997
+
+
+
+
+Contents
+
+    1  Abstract  ...................................................   1
+    2  Introduction  ...............................................   2
+    3  Terminology  ................................................   3
+    4  Server Reply Source Address Selection  ......................   3
+    5  Resource Record Sets  .......................................   4
+    6  Zone Cuts  ..................................................   8
+    7  SOA RRs  ....................................................  10
+    8  Time to Live (TTL)  .........................................  10
+    9  The TC (truncated) header bit  ..............................  11
+   10  Naming issues  ..............................................  11
+   11  Name syntax  ................................................  13
+   12  Security Considerations  ....................................  14
+   13  References  .................................................  14
+   14  Acknowledgements  ...........................................  15
+   15  Authors' Addresses  .........................................  15
+
+
+
+
+2. Introduction
+
+   Several problem areas in the Domain Name System specification
+   [RFC1034, RFC1035] have been noted through the years [RFC1123].  This
+   document addresses several additional problem areas.  The issues here
+   are independent.  Those issues are the question of which source
+   address a multi-homed DNS server should use when replying to a query,
+   the issue of differing TTLs for DNS records with the same label,
+   class and type, and the issue of canonical names, what they are, how
+   CNAME records relate, what names are legal in what parts of the DNS,
+   and what is the valid syntax of a DNS name.
+
+   Clarifications to the DNS specification to avoid these problems are
+   made in this memo.  A minor ambiguity in RFC1034 concerned with SOA
+   records is also corrected, as is one in the definition of the TTL
+   (Time To Live) and some possible confusion in use of the TC bit.
+
+
+
+
+
+
+
+
+
+
+
+
+Elz & Bush                  Standards Track                     [Page 2]
+
+RFC 2181        Clarifications to the DNS Specification        July 1997
+
+
+3. Terminology
+
+   This memo does not use the oft used expressions MUST, SHOULD, MAY, or
+   their negative forms.  In some sections it may seem that a
+   specification is worded mildly, and hence some may infer that the
+   specification is optional.  That is not correct.  Anywhere that this
+   memo suggests that some action should be carried out, or must be
+   carried out, or that some behaviour is acceptable, or not, that is to
+   be considered as a fundamental aspect of this specification,
+   regardless of the specific words used.  If some behaviour or action
+   is truly optional, that will be clearly specified by the text.
+
+4. Server Reply Source Address Selection
+
+   Most, if not all, DNS clients, expect the address from which a reply
+   is received to be the same address as that to which the query
+   eliciting the reply was sent.  This is true for servers acting as
+   clients for the purposes of recursive query resolution, as well as
+   simple resolver clients.  The address, along with the identifier (ID)
+   in the reply is used for disambiguating replies, and filtering
+   spurious responses.  This may, or may not, have been intended when
+   the DNS was designed, but is now a fact of life.
+
+   Some multi-homed hosts running DNS servers generate a reply using a
+   source address that is not the same as the destination address from
+   the client's request packet.  Such replies will be discarded by the
+   client because the source address of the reply does not match that of
+   a host to which the client sent the original request.  That is, it
+   appears to be an unsolicited response.
+
+4.1. UDP Source Address Selection
+
+   To avoid these problems, servers when responding to queries using UDP
+   must cause the reply to be sent with the source address field in the
+   IP header set to the address that was in the destination address
+   field of the IP header of the packet containing the query causing the
+   response.  If this would cause the response to be sent from an IP
+   address that is not permitted for this purpose, then the response may
+   be sent from any legal IP address allocated to the server.  That
+   address should be chosen to maximise the possibility that the client
+   will be able to use it for further queries.  Servers configured in
+   such a way that not all their addresses are equally reachable from
+   all potential clients need take particular care when responding to
+   queries sent to anycast, multicast, or similar, addresses.
+
+
+
+
+
+
+
+Elz & Bush                  Standards Track                     [Page 3]
+
+RFC 2181        Clarifications to the DNS Specification        July 1997
+
+
+4.2. Port Number Selection
+
+   Replies to all queries must be directed to the port from which they
+   were sent.  When queries are received via TCP this is an inherent
+   part of the transport protocol.  For queries received by UDP the
+   server must take note of the source port and use that as the
+   destination port in the response.  Replies should always be sent from
+   the port to which they were directed.  Except in extraordinary
+   circumstances, this will be the well known port assigned for DNS
+   queries [RFC1700].
+
+5. Resource Record Sets
+
+   Each DNS Resource Record (RR) has a label, class, type, and data.  It
+   is meaningless for two records to ever have label, class, type and
+   data all equal - servers should suppress such duplicates if
+   encountered.  It is however possible for most record types to exist
+   with the same label, class and type, but with different data.  Such a
+   group of records is hereby defined to be a Resource Record Set
+   (RRSet).
+
+5.1. Sending RRs from an RRSet
+
+   A query for a specific (or non-specific) label, class, and type, will
+   always return all records in the associated RRSet - whether that be
+   one or more RRs.  The response must be marked as "truncated" if the
+   entire RRSet will not fit in the response.
+
+5.2. TTLs of RRs in an RRSet
+
+   Resource Records also have a time to live (TTL).  It is possible for
+   the RRs in an RRSet to have different TTLs.  No uses for this have
+   been found that cannot be better accomplished in other ways.  This
+   can, however, cause partial replies (not marked "truncated") from a
+   caching server, where the TTLs for some but not all the RRs in the
+   RRSet have expired.
+
+   Consequently the use of differing TTLs in an RRSet is hereby
+   deprecated, the TTLs of all RRs in an RRSet must be the same.
+
+   Should a client receive a response containing RRs from an RRSet with
+   differing TTLs, it should treat this as an error.  If the RRSet
+   concerned is from a non-authoritative source for this data, the
+   client should simply ignore the RRSet, and if the values were
+   required, seek to acquire them from an authoritative source.  Clients
+   that are configured to send all queries to one, or more, particular
+   servers should treat those servers as authoritative for this purpose.
+   Should an authoritative source send such a malformed RRSet, the
+
+
+
+Elz & Bush                  Standards Track                     [Page 4]
+
+RFC 2181        Clarifications to the DNS Specification        July 1997
+
+
+   client should treat the RRs for all purposes as if all TTLs in the
+   RRSet had been set to the value of the lowest TTL in the RRSet.  In
+   no case may a server send an RRSet with TTLs not all equal.
+
+5.3. DNSSEC Special Cases
+
+   Two of the record types added by DNS Security (DNSSEC) [RFC2065]
+   require special attention when considering the formation of Resource
+   Record Sets.  Those are the SIG and NXT records.  It should be noted
+   that DNS Security is still very new, and there is, as yet, little
+   experience with it.  Readers should be prepared for the information
+   related to DNSSEC contained in this document to become outdated as
+   the DNS Security specification matures.
+
+5.3.1. SIG records and RRSets
+
+   A SIG record provides signature (validation) data for another RRSet
+   in the DNS.  Where a zone has been signed, every RRSet in the zone
+   will have had a SIG record associated with it.  The data type of the
+   RRSet is included in the data of the SIG RR, to indicate with which
+   particular RRSet this SIG record is associated.  Were the rules above
+   applied, whenever a SIG record was included with a response to
+   validate that response, the SIG records for all other RRSets
+   associated with the appropriate node would also need to be included.
+   In some cases, this could be a very large number of records, not
+   helped by their being rather large RRs.
+
+   Thus, it is specifically permitted for the authority section to
+   contain only those SIG RRs with the "type covered" field equal to the
+   type field of an answer being returned.  However, where SIG records
+   are being returned in the answer section, in response to a query for
+   SIG records, or a query for all records associated with a name
+   (type=ANY) the entire SIG RRSet must be included, as for any other RR
+   type.
+
+   Servers that receive responses containing SIG records in the
+   authority section, or (probably incorrectly) as additional data, must
+   understand that the entire RRSet has almost certainly not been
+   included.  Thus, they must not cache that SIG record in a way that
+   would permit it to be returned should a query for SIG records be
+   received at that server.  RFC2065 actually requires that SIG queries
+   be directed only to authoritative servers to avoid the problems that
+   could be caused here, and while servers exist that do not understand
+   the special properties of SIG records, this will remain necessary.
+   However, careful design of SIG record processing in new
+   implementations should permit this restriction to be relaxed in the
+   future, so resolvers do not need to treat SIG record queries
+   specially.
+
+
+
+Elz & Bush                  Standards Track                     [Page 5]
+
+RFC 2181        Clarifications to the DNS Specification        July 1997
+
+
+   It has been occasionally stated that a received request for a SIG
+   record should be forwarded to an authoritative server, rather than
+   being answered from data in the cache.  This is not necessary - a
+   server that has the knowledge of SIG as a special case for processing
+   this way would be better to correctly cache SIG records, taking into
+   account their characteristics.  Then the server can determine when it
+   is safe to reply from the cache, and when the answer is not available
+   and the query must be forwarded.
+
+5.3.2. NXT RRs
+
+   Next Resource Records (NXT) are even more peculiar.  There will only
+   ever be one NXT record in a zone for a particular label, so
+   superficially, the RRSet problem is trivial.  However, at a zone cut,
+   both the parent zone, and the child zone (superzone and subzone in
+   RFC2065 terminology) will have NXT records for the same name.  Those
+   two NXT records do not form an RRSet, even where both zones are
+   housed at the same server.  NXT RRSets always contain just a single
+   RR.  Where both NXT records are visible, two RRSets exist.  However,
+   servers are not required to treat this as a special case when
+   receiving NXT records in a response.  They may elect to notice the
+   existence of two different NXT RRSets, and treat that as they would
+   two different RRSets of any other type.  That is, cache one, and
+   ignore the other.  Security aware servers will need to correctly
+   process the NXT record in the received response though.
+
+5.4. Receiving RRSets
+
+   Servers must never merge RRs from a response with RRs in their cache
+   to form an RRSet.  If a response contains data that would form an
+   RRSet with data in a server's cache the server must either ignore the
+   RRs in the response, or discard the entire RRSet currently in the
+   cache, as appropriate.  Consequently the issue of TTLs varying
+   between the cache and a response does not cause concern, one will be
+   ignored.  That is, one of the data sets is always incorrect if the
+   data from an answer differs from the data in the cache.  The
+   challenge for the server is to determine which of the data sets is
+   correct, if one is, and retain that, while ignoring the other.  Note
+   that if a server receives an answer containing an RRSet that is
+   identical to that in its cache, with the possible exception of the
+   TTL value, it may, optionally, update the TTL in its cache with the
+   TTL of the received answer.  It should do this if the received answer
+   would be considered more authoritative (as discussed in the next
+   section) than the previously cached answer.
+
+
+
+
+
+
+
+Elz & Bush                  Standards Track                     [Page 6]
+
+RFC 2181        Clarifications to the DNS Specification        July 1997
+
+
+5.4.1. Ranking data
+
+   When considering whether to accept an RRSet in a reply, or retain an
+   RRSet already in its cache instead, a server should consider the
+   relative likely trustworthiness of the various data.  An
+   authoritative answer from a reply should replace cached data that had
+   been obtained from additional information in an earlier reply.
+   However additional information from a reply will be ignored if the
+   cache contains data from an authoritative answer or a zone file.
+
+   The accuracy of data available is assumed from its source.
+   Trustworthiness shall be, in order from most to least:
+
+     + Data from a primary zone file, other than glue data,
+     + Data from a zone transfer, other than glue,
+     + The authoritative data included in the answer section of an
+       authoritative reply.
+     + Data from the authority section of an authoritative answer,
+     + Glue from a primary zone, or glue from a zone transfer,
+     + Data from the answer section of a non-authoritative answer, and
+       non-authoritative data from the answer section of authoritative
+       answers,
+     + Additional information from an authoritative answer,
+       Data from the authority section of a non-authoritative answer,
+       Additional information from non-authoritative answers.
+
+   Note that the answer section of an authoritative answer normally
+   contains only authoritative data.  However when the name sought is an
+   alias (see section 10.1.1) only the record describing that alias is
+   necessarily authoritative.  Clients should assume that other records
+   may have come from the server's cache.  Where authoritative answers
+   are required, the client should query again, using the canonical name
+   associated with the alias.
+
+   Unauthenticated RRs received and cached from the least trustworthy of
+   those groupings, that is data from the additional data section, and
+   data from the authority section of a non-authoritative answer, should
+   not be cached in such a way that they would ever be returned as
+   answers to a received query.  They may be returned as additional
+   information where appropriate.  Ignoring this would allow the
+   trustworthiness of relatively untrustworthy data to be increased
+   without cause or excuse.
+
+   When DNS security [RFC2065] is in use, and an authenticated reply has
+   been received and verified, the data thus authenticated shall be
+   considered more trustworthy than unauthenticated data of the same
+   type.  Note that throughout this document, "authoritative" means a
+   reply with the AA bit set.  DNSSEC uses trusted chains of SIG and KEY
+
+
+
+Elz & Bush                  Standards Track                     [Page 7]
+
+RFC 2181        Clarifications to the DNS Specification        July 1997
+
+
+   records to determine the authenticity of data, the AA bit is almost
+   irrelevant.  However DNSSEC aware servers must still correctly set
+   the AA bit in responses to enable correct operation with servers that
+   are not security aware (almost all currently).
+
+   Note that, glue excluded, it is impossible for data from two
+   correctly configured primary zone files, two correctly configured
+   secondary zones (data from zone transfers) or data from correctly
+   configured primary and secondary zones to ever conflict.  Where glue
+   for the same name exists in multiple zones, and differs in value, the
+   nameserver should select data from a primary zone file in preference
+   to secondary, but otherwise may choose any single set of such data.
+   Choosing that which appears to come from a source nearer the
+   authoritative data source may make sense where that can be
+   determined.  Choosing primary data over secondary allows the source
+   of incorrect glue data to be discovered more readily, when a problem
+   with such data exists.  Where a server can detect from two zone files
+   that one or more are incorrectly configured, so as to create
+   conflicts, it should refuse to load the zones determined to be
+   erroneous, and issue suitable diagnostics.
+
+   "Glue" above includes any record in a zone file that is not properly
+   part of that zone, including nameserver records of delegated sub-
+   zones (NS records), address records that accompany those NS records
+   (A, AAAA, etc), and any other stray data that might appear.
+
+5.5. Sending RRSets (reprise)
+
+   A Resource Record Set should only be included once in any DNS reply.
+   It may occur in any of the Answer, Authority, or Additional
+   Information sections, as required.  However it should not be repeated
+   in the same, or any other, section, except where explicitly required
+   by a specification.  For example, an AXFR response requires the SOA
+   record (always an RRSet containing a single RR) be both the first and
+   last record of the reply.  Where duplicates are required this way,
+   the TTL transmitted in each case must be the same.
+
+6. Zone Cuts
+
+   The DNS tree is divided into "zones", which are collections of
+   domains that are treated as a unit for certain management purposes.
+   Zones are delimited by "zone cuts".  Each zone cut separates a
+   "child" zone (below the cut) from a "parent" zone (above the cut).
+   The domain name that appears at the top of a zone (just below the cut
+   that separates the zone from its parent) is called the zone's
+   "origin".  The name of the zone is the same as the name of the domain
+   at the zone's origin.  Each zone comprises that subset of the DNS
+   tree that is at or below the zone's origin, and that is above the
+
+
+
+Elz & Bush                  Standards Track                     [Page 8]
+
+RFC 2181        Clarifications to the DNS Specification        July 1997
+
+
+   cuts that separate the zone from its children (if any).  The
+   existence of a zone cut is indicated in the parent zone by the
+   existence of NS records specifying the origin of the child zone.  A
+   child zone does not contain any explicit reference to its parent.
+
+6.1. Zone authority
+
+   The authoritative servers for a zone are enumerated in the NS records
+   for the origin of the zone, which, along with a Start of Authority
+   (SOA) record are the mandatory records in every zone.  Such a server
+   is authoritative for all resource records in a zone that are not in
+   another zone.  The NS records that indicate a zone cut are the
+   property of the child zone created, as are any other records for the
+   origin of that child zone, or any sub-domains of it.  A server for a
+   zone should not return authoritative answers for queries related to
+   names in another zone, which includes the NS, and perhaps A, records
+   at a zone cut, unless it also happens to be a server for the other
+   zone.
+
+   Other than the DNSSEC cases mentioned immediately below, servers
+   should ignore data other than NS records, and necessary A records to
+   locate the servers listed in the NS records, that may happen to be
+   configured in a zone at a zone cut.
+
+6.2. DNSSEC issues
+
+   The DNS security mechanisms [RFC2065] complicate this somewhat, as
+   some of the new resource record types added are very unusual when
+   compared with other DNS RRs.  In particular the NXT ("next") RR type
+   contains information about which names exist in a zone, and hence
+   which do not, and thus must necessarily relate to the zone in which
+   it exists.  The same domain name may have different NXT records in
+   the parent zone and the child zone, and both are valid, and are not
+   an RRSet.  See also section 5.3.2.
+
+   Since NXT records are intended to be automatically generated, rather
+   than configured by DNS operators, servers may, but are not required
+   to, retain all differing NXT records they receive regardless of the
+   rules in section 5.4.
+
+   For a secure parent zone to securely indicate that a subzone is
+   insecure, DNSSEC requires that a KEY RR indicating that the subzone
+   is insecure, and the parent zone's authenticating SIG RR(s) be
+   present in the parent zone, as they by definition cannot be in the
+   subzone.  Where a subzone is secure, the KEY and SIG records will be
+   present, and authoritative, in that zone, but should also always be
+   present in the parent zone (if secure).
+
+
+
+
+Elz & Bush                  Standards Track                     [Page 9]
+
+RFC 2181        Clarifications to the DNS Specification        July 1997
+
+
+   Note that in none of these cases should a server for the parent zone,
+   not also being a server for the subzone, set the AA bit in any
+   response for a label at a zone cut.
+
+7. SOA RRs
+
+   Three minor issues concerning the Start of Zone of Authority (SOA)
+   Resource Record need some clarification.
+
+7.1. Placement of SOA RRs in authoritative answers
+
+   RFC1034, in section 3.7, indicates that the authority section of an
+   authoritative answer may contain the SOA record for the zone from
+   which the answer was obtained.  When discussing negative caching,
+   RFC1034 section 4.3.4 refers to this technique but mentions the
+   additional section of the response.  The former is correct, as is
+   implied by the example shown in section 6.2.5 of RFC1034.  SOA
+   records, if added, are to be placed in the authority section.
+
+7.2. TTLs on SOA RRs
+
+   It may be observed that in section 3.2.1 of RFC1035, which defines
+   the format of a Resource Record, that the definition of the TTL field
+   contains a throw away line which states that the TTL of an SOA record
+   should always be sent as zero to prevent caching.  This is mentioned
+   nowhere else, and has not generally been implemented.
+   Implementations should not assume that SOA records will have a TTL of
+   zero, nor are they required to send SOA records with a TTL of zero.
+
+7.3. The SOA.MNAME field
+
+   It is quite clear in the specifications, yet seems to have been
+   widely ignored, that the MNAME field of the SOA record should contain
+   the name of the primary (master) server for the zone identified by
+   the SOA.  It should not contain the name of the zone itself.  That
+   information would be useless, as to discover it, one needs to start
+   with the domain name of the SOA record - that is the name of the
+   zone.
+
+8. Time to Live (TTL)
+
+   The definition of values appropriate to the TTL field in STD 13 is
+   not as clear as it could be, with respect to how many significant
+   bits exist, and whether the value is signed or unsigned.  It is
+   hereby specified that a TTL value is an unsigned number, with a
+   minimum value of 0, and a maximum value of 2147483647.  That is, a
+   maximum of 2^31 - 1.  When transmitted, this value shall be encoded
+   in the less significant 31 bits of the 32 bit TTL field, with the
+
+
+
+Elz & Bush                  Standards Track                    [Page 10]
+
+RFC 2181        Clarifications to the DNS Specification        July 1997
+
+
+   most significant, or sign, bit set to zero.
+
+   Implementations should treat TTL values received with the most
+   significant bit set as if the entire value received was zero.
+
+   Implementations are always free to place an upper bound on any TTL
+   received, and treat any larger values as if they were that upper
+   bound.  The TTL specifies a maximum time to live, not a mandatory
+   time to live.
+
+9. The TC (truncated) header bit
+
+   The TC bit should be set in responses only when an RRSet is required
+   as a part of the response, but could not be included in its entirety.
+   The TC bit should not be set merely because some extra information
+   could have been included, but there was insufficient room.  This
+   includes the results of additional section processing.  In such cases
+   the entire RRSet that will not fit in the response should be omitted,
+   and the reply sent as is, with the TC bit clear.  If the recipient of
+   the reply needs the omitted data, it can construct a query for that
+   data and send that separately.
+
+   Where TC is set, the partial RRSet that would not completely fit may
+   be left in the response.  When a DNS client receives a reply with TC
+   set, it should ignore that response, and query again, using a
+   mechanism, such as a TCP connection, that will permit larger replies.
+
+10. Naming issues
+
+   It has sometimes been inferred from some sections of the DNS
+   specification [RFC1034, RFC1035] that a host, or perhaps an interface
+   of a host, is permitted exactly one authoritative, or official, name,
+   called the canonical name.  There is no such requirement in the DNS.
+
+10.1. CNAME resource records
+
+   The DNS CNAME ("canonical name") record exists to provide the
+   canonical name associated with an alias name.  There may be only one
+   such canonical name for any one alias.  That name should generally be
+   a name that exists elsewhere in the DNS, though there are some rare
+   applications for aliases with the accompanying canonical name
+   undefined in the DNS.  An alias name (label of a CNAME record) may,
+   if DNSSEC is in use, have SIG, NXT, and KEY RRs, but may have no
+   other data.  That is, for any label in the DNS (any domain name)
+   exactly one of the following is true:
+
+
+
+
+
+
+Elz & Bush                  Standards Track                    [Page 11]
+
+RFC 2181        Clarifications to the DNS Specification        July 1997
+
+
+     + one CNAME record exists, optionally accompanied by SIG, NXT, and
+       KEY RRs,
+     + one or more records exist, none being CNAME records,
+     + the name exists, but has no associated RRs of any type,
+     + the name does not exist at all.
+
+10.1.1. CNAME terminology
+
+   It has been traditional to refer to the label of a CNAME record as "a
+   CNAME".  This is unfortunate, as "CNAME" is an abbreviation of
+   "canonical name", and the label of a CNAME record is most certainly
+   not a canonical name.  It is, however, an entrenched usage.  Care
+   must therefore be taken to be very clear whether the label, or the
+   value (the canonical name) of a CNAME resource record is intended.
+   In this document, the label of a CNAME resource record will always be
+   referred to as an alias.
+
+10.2. PTR records
+
+   Confusion about canonical names has lead to a belief that a PTR
+   record should have exactly one RR in its RRSet.  This is incorrect,
+   the relevant section of RFC1034 (section 3.6.2) indicates that the
+   value of a PTR record should be a canonical name.  That is, it should
+   not be an alias.  There is no implication in that section that only
+   one PTR record is permitted for a name.  No such restriction should
+   be inferred.
+
+   Note that while the value of a PTR record must not be an alias, there
+   is no requirement that the process of resolving a PTR record not
+   encounter any aliases.  The label that is being looked up for a PTR
+   value might have a CNAME record.  That is, it might be an alias.  The
+   value of that CNAME RR, if not another alias, which it should not be,
+   will give the location where the PTR record is found.  That record
+   gives the result of the PTR type lookup.  This final result, the
+   value of the PTR RR, is the label which must not be an alias.
+
+10.3. MX and NS records
+
+   The domain name used as the value of a NS resource record, or part of
+   the value of a MX resource record must not be an alias.  Not only is
+   the specification clear on this point, but using an alias in either
+   of these positions neither works as well as might be hoped, nor well
+   fulfills the ambition that may have led to this approach.  This
+   domain name must have as its value one or more address records.
+   Currently those will be A records, however in the future other record
+   types giving addressing information may be acceptable.  It can also
+   have other RRs, but never a CNAME RR.
+
+
+
+
+Elz & Bush                  Standards Track                    [Page 12]
+
+RFC 2181        Clarifications to the DNS Specification        July 1997
+
+
+   Searching for either NS or MX records causes "additional section
+   processing" in which address records associated with the value of the
+   record sought are appended to the answer.  This helps avoid needless
+   extra queries that are easily anticipated when the first was made.
+
+   Additional section processing does not include CNAME records, let
+   alone the address records that may be associated with the canonical
+   name derived from the alias.  Thus, if an alias is used as the value
+   of an NS or MX record, no address will be returned with the NS or MX
+   value.  This can cause extra queries, and extra network burden, on
+   every query.  It is trivial for the DNS administrator to avoid this
+   by resolving the alias and placing the canonical name directly in the
+   affected record just once when it is updated or installed.  In some
+   particular hard cases the lack of the additional section address
+   records in the results of a NS lookup can cause the request to fail.
+
+11. Name syntax
+
+   Occasionally it is assumed that the Domain Name System serves only
+   the purpose of mapping Internet host names to data, and mapping
+   Internet addresses to host names.  This is not correct, the DNS is a
+   general (if somewhat limited) hierarchical database, and can store
+   almost any kind of data, for almost any purpose.
+
+   The DNS itself places only one restriction on the particular labels
+   that can be used to identify resource records.  That one restriction
+   relates to the length of the label and the full name.  The length of
+   any one label is limited to between 1 and 63 octets.  A full domain
+   name is limited to 255 octets (including the separators).  The zero
+   length full name is defined as representing the root of the DNS tree,
+   and is typically written and displayed as ".".  Those restrictions
+   aside, any binary string whatever can be used as the label of any
+   resource record.  Similarly, any binary string can serve as the value
+   of any record that includes a domain name as some or all of its value
+   (SOA, NS, MX, PTR, CNAME, and any others that may be added).
+   Implementations of the DNS protocols must not place any restrictions
+   on the labels that can be used.  In particular, DNS servers must not
+   refuse to serve a zone because it contains labels that might not be
+   acceptable to some DNS client programs.  A DNS server may be
+   configurable to issue warnings when loading, or even to refuse to
+   load, a primary zone containing labels that might be considered
+   questionable, however this should not happen by default.
+
+   Note however, that the various applications that make use of DNS data
+   can have restrictions imposed on what particular values are
+   acceptable in their environment.  For example, that any binary label
+   can have an MX record does not imply that any binary name can be used
+   as the host part of an e-mail address.  Clients of the DNS can impose
+
+
+
+Elz & Bush                  Standards Track                    [Page 13]
+
+RFC 2181        Clarifications to the DNS Specification        July 1997
+
+
+   whatever restrictions are appropriate to their circumstances on the
+   values they use as keys for DNS lookup requests, and on the values
+   returned by the DNS.  If the client has such restrictions, it is
+   solely responsible for validating the data from the DNS to ensure
+   that it conforms before it makes any use of that data.
+
+   See also [RFC1123] section 6.1.3.5.
+
+12. Security Considerations
+
+   This document does not consider security.
+
+   In particular, nothing in section 4 is any way related to, or useful
+   for, any security related purposes.
+
+   Section 5.4.1 is also not related to security.  Security of DNS data
+   will be obtained by the Secure DNS [RFC2065], which is mostly
+   orthogonal to this memo.
+
+   It is not believed that anything in this document adds to any
+   security issues that may exist with the DNS, nor does it do anything
+   to that will necessarily lessen them.  Correct implementation of the
+   clarifications in this document might play some small part in
+   limiting the spread of non-malicious bad data in the DNS, but only
+   DNSSEC can help with deliberate attempts to subvert DNS data.
+
+13. References
+
+   [RFC1034]   Mockapetris, P., "Domain Names - Concepts and Facilities",
+               STD 13, RFC 1034, November 1987.
+
+   [RFC1035]   Mockapetris, P., "Domain Names - Implementation and
+               Specification", STD 13, RFC 1035, November 1987.
+
+   [RFC1123]   Braden, R., "Requirements for Internet Hosts - application
+               and support", STD 3, RFC 1123, January 1989.
+
+   [RFC1700]   Reynolds, J., Postel, J., "Assigned Numbers",
+               STD 2, RFC 1700, October 1994.
+
+   [RFC2065]   Eastlake, D., Kaufman, C., "Domain Name System Security
+               Extensions", RFC 2065, January 1997.
+
+
+
+
+
+
+
+
+
+Elz & Bush                  Standards Track                    [Page 14]
+
+RFC 2181        Clarifications to the DNS Specification        July 1997
+
+
+14. Acknowledgements
+
+   This memo arose from discussions in the DNSIND working group of the
+   IETF in 1995 and 1996, the members of that working group are largely
+   responsible for the ideas captured herein.  Particular thanks to
+   Donald E. Eastlake, 3rd, and Olafur Gudmundsson, for help with the
+   DNSSEC issues in this document, and to John Gilmore for pointing out
+   where the clarifications were not necessarily clarifying.  Bob Halley
+   suggested clarifying the placement of SOA records in authoritative
+   answers, and provided the references.  Michael Patton, as usual, and
+   Mark Andrews, Alan Barrett and Stan Barber provided much assistance
+   with many details.  Josh Littlefield helped make sure that the
+   clarifications didn't cause problems in some irritating corner cases.
+
+15. Authors' Addresses
+
+   Robert Elz
+   Computer Science
+   University of Melbourne
+   Parkville, Victoria, 3052
+   Australia.
+
+   EMail: kre@munnari.OZ.AU
+
+
+   Randy Bush
+   RGnet, Inc.
+   5147 Crystal Springs Drive NE
+   Bainbridge Island, Washington,  98110
+   United States.
+
+   EMail: randy@psg.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Elz & Bush                  Standards Track                    [Page 15]
diff --git a/doc/rfc/rfc2230.txt b/doc/rfc/rfc2230.txt
new file mode 100644
index 0000000..03995fe
--- /dev/null
+++ b/doc/rfc/rfc2230.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+Network Working Group                                         R. Atkinson
+Request for Comments: 2230                                            NRL
+Category: Informational                                     November 1997
+
+
+               Key Exchange Delegation Record for the DNS
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1997).  All Rights Reserved.
+
+ABSTRACT
+
+   This note describes a mechanism whereby authorisation for one node to
+   act as key exchanger for a second node is delegated and made
+   available via the Secure DNS.  This mechanism is intended to be used
+   only with the Secure DNS.  It can be used with several security
+   services.  For example, a system seeking to use IP Security [RFC-
+   1825, RFC-1826, RFC-1827] to protect IP packets for a given
+   destination can use this mechanism to determine the set of authorised
+   remote key exchanger systems for that destination.
+
+1. INTRODUCTION
+
+
+   The Domain Name System (DNS) is the standard way that Internet nodes
+   locate information about addresses, mail exchangers, and other data
+   relating to remote Internet nodes. [RFC-1035, RFC-1034] More
+   recently, Eastlake and Kaufman have defined standards-track security
+   extensions to the DNS. [RFC-2065] These security extensions can be
+   used to authenticate signed DNS data records and can also be used to
+   store signed public keys in the DNS.
+
+   The KX record is useful in providing an authenticatible method of
+   delegating authorisation for one node to provide key exchange
+   services on behalf of one or more, possibly different, nodes.  This
+   note specifies the syntax and semantics of the KX record, which is
+   currently in limited deployment in certain IP-based networks.  The
+
+
+
+
+
+
+
+Atkinson                     Informational                      [Page 1]
+
+RFC 2230           DNS Key Exchange Delegation Record      November 1997
+
+
+   reader is assumed to be familiar with the basics of DNS, including
+   familiarity with [RFC-1035, RFC-1034].  This document is not on the
+   IETF standards-track and does not specify any level of standard.
+   This document merely provides information for the Internet community.
+
+1.1 Identity Terminology
+
+   This document relies upon the concept of "identity domination".  This
+   concept might be new to the reader and so is explained in this
+   section.  The subject of endpoint naming for security associations
+   has historically been somewhat contentious.  This document takes no
+   position on what forms of identity should be used.  In a network,
+   there are several forms of identity that are possible.
+
+   For example, IP Security has defined notions of identity that
+   include: IP Address, IP Address Range, Connection ID, Fully-Qualified
+   Domain Name (FQDN), and User with Fully Qualified Domain Name (USER
+   FQDN).
+
+   A USER FQDN identity dominates a FQDN identity.  A FQDN identity in
+   turn dominates an IP Address identity.  Similarly, a Connection ID
+   dominates an IP Address identity.  An IP Address Range dominates each
+   IP Address identity for each IP address within that IP address range.
+   Also, for completeness, an IP Address identity is considered to
+   dominate itself.
+
+2. APPROACH
+
+   This document specifies a new kind of DNS Resource Record (RR), known
+   as the Key Exchanger (KX) record.  A Key Exchanger Record has the
+   mnemonic "KX" and the type code of 36.  Each KX record is associated
+   with a fully-qualified domain name.  The KX record is modeled on the
+   MX record described in [Part86]. Any given domain, subdomain, or host
+   entry in the DNS might have a KX record.
+
+2.1 IPsec Examples
+
+   In these two examples, let S be the originating node and let D be the
+   destination node.  S2 is another node on the same subnet as S.  D2 is
+   another node on the same subnet as D.  R1 and R2 are IPsec-capable
+   routers.  The path from S to D goes via first R1 and later R2.  The
+   return path from D to S goes via first R2 and later R1.
+
+   IETF-standard IP Security uses unidirectional Security Associations
+   [RFC-1825].  Therefore, a typical IP session will use a pair of
+   related Security Associations, one in each direction.  The examples
+   below talk about how to setup an example Security Association, but in
+   practice a pair of matched Security Associations will normally be
+
+
+
+Atkinson                     Informational                      [Page 2]
+
+RFC 2230           DNS Key Exchange Delegation Record      November 1997
+
+
+   used.
+
+2.1.1 Subnet-to-Subnet Example
+
+   If neither S nor D implements IPsec, security can still be provided
+   between R1 and R2 by building a secure tunnel.  This can use either
+   AH or ESP.
+
+       S ---+                                          +----D
+            |                                          |
+            +- R1 -----[zero or more routers]-------R2-+
+            |                                          |
+       S2---+                                          +----D2
+
+       Figure 1:  Network Diagram for Subnet-to-Subnet Example
+
+   In this example, R1 makes the policy decision to provide the IPsec
+   service for traffic from R1 destined for R2.  Once R1 has decided
+   that the packet from S to D should be protected, it performs a secure
+   DNS lookup for the records associated with domain D.  If R1 only
+   knows the IP address for D, then a secure reverse DNS lookup will be
+   necessary to determine the domain D, before that forward secure DNS
+   lookup for records associated with domain D.  If these DNS records of
+   domain D include a KX record for the IPsec service, then R1 knows
+   which set of nodes are authorised key exchanger nodes for the
+   destination D.
+
+   In this example, let there be at least one KX record for D and let
+   the most preferred KX record for D point at R2.  R1 then selects a
+   key exchanger (in this example, R2) for D from the list obtained from
+   the secure DNS.  Then R1 initiates a key management session with that
+   key exchanger (in this example, R2) to setup an IPsec Security
+   Association between R1 and D.  In this example, R1 knows (either by
+   seeing an outbound packet arriving from S destined to D or via other
+   methods) that S will be sending traffic to D.  In this example R1's
+   policy requires that traffic from S to D should be segregated at
+   least on a host-to-host basis, so R1 desires an IPsec Security
+   Association with source identity that dominates S, proxy identity
+   that dominates R1, and destination identity that dominates R2.
+
+   In turn, R2 is able to authenticate the delegation of Key Exchanger
+   authorisation for target S to R1 by making an authenticated forward
+   DNS lookup for KX records associated with S and verifying that at
+   least one such record points to R1.  The identity S is typically
+   given to R2 as part of the key management process between R1 and R2.
+
+
+
+
+
+
+Atkinson                     Informational                      [Page 3]
+
+RFC 2230           DNS Key Exchange Delegation Record      November 1997
+
+
+   If D initially only knows the IP address of S, then it will need to
+   perform a secure reverse DNS lookup to obtain the fully-qualified
+   domain name for S prior to that secure forward DNS lookup.
+
+   If R2 does not receive an authenticated DNS response indicating that
+   R1 is an authorised key exchanger for S, then D will not accept the
+   SA negotiation from R1 on behalf of identity S.
+
+   If the proposed IPsec Security Association is acceptable to both R1
+   and R2, each of which might have separate policies, then they create
+   that IPsec Security Association via Key Management.
+
+   Note that for unicast traffic, Key Management will typically also
+   setup a separate (but related) IPsec Security Association for the
+   return traffic.  That return IPsec Security Association will have
+   equivalent identities.  In this example, that return IPsec Security
+   Association will have a source identity that dominates D, a proxy
+   identity that dominates R2, and a destination identity that dominates
+   R1.
+
+   Once the IPsec Security Association has been created, then R1 uses it
+   to protect traffic from S destined for D via a secure tunnel that
+   originates at R1 and terminates at R2.  For the case of unicast, R2
+   will use the return IPsec Security Association to protect traffic
+   from D destined for S via a secure tunnel that originates at R2 and
+   terminates at R1.
+
+2.1.2 Subnet-to-Host Example
+
+   Consider the case where D and R1 implement IPsec, but S does not
+   implement IPsec, which is an interesting variation on the previous
+   example.  This example is shown in Figure 2 below.
+
+       S ---+
+            |
+            +- R1 -----[zero or more routers]-------D
+            |
+       S2---+
+
+       Figure 2:  Network Diagram for Subnet-to-Host Example
+
+   In this example, R1 makes the policy decision that IP Security is
+   needed for the packet travelling from S to D.  Then, R1 performs the
+   secure DNS lookup for D and determines that D is its own key
+   exchanger, either from the existence of a KX record for D pointing to
+   D or from an authenticated DNS response indicating that no KX record
+   exists for D.  If R1 does not initially know the domain name of D,
+   then prior to the above forward secure DNS lookup, R1 performs a
+
+
+
+Atkinson                     Informational                      [Page 4]
+
+RFC 2230           DNS Key Exchange Delegation Record      November 1997
+
+
+   secure reverse DNS lookup on the IP address of D to determine the
+   fully-qualified domain name for that IP address.  R1 then initiates
+   key management with D to create an IPsec Security Association on
+   behalf of S.
+
+   In turn, D can verify that R1 is authorised to create an IPsec
+   Security Association on behalf of S by performing a DNS KX record
+   lookup for target S.  R1 usually provides identity S to D via key
+   management.  If D only has the IP address of S, then D will need to
+   perform a secure reverse lookup on the IP address of S to determine
+   domain name S prior to the secure forward DNS lookup on S to locate
+   the KX records for S.
+
+   If D does not receive an authenticated DNS response indicating that
+   R1 is an authorised key exchanger for S, then D will not accept the
+   SA negotiation from R1 on behalf of identity S.
+
+   If the IPsec Security Association is successfully established between
+   R1 and D, that IPsec Security Association has a source identity that
+   dominates S's IP address, a proxy identity that dominates R1's IP
+   address, and a destination identity that dominates D's IP address.
+
+   Finally, R1 begins providing the security service for packets from S
+   that transit R1 destined for D.  When D receives such packets, D
+   examines the SA information during IPsec input processing and sees
+   that R1's address is listed as valid proxy address for that SA and
+   that S is the source address for that SA.  Hence, D knows at input
+   processing time that R1 is authorised to provide security on behalf
+   of S.  Therefore packets coming from R1 with valid IP security that
+   claim to be from S are trusted by D to have really come from S.
+
+2.1.3 Host to Subnet Example
+
+   Now consider the above case from D's perspective (i.e. where D is
+   sending IP packets to S).  This variant is sometimes known as the
+   Mobile Host or "roadwarrier" case. The same basic concepts apply, but
+   the details are covered here in hope of improved clarity.
+
+       S ---+
+            |
+            +- R1 -----[zero or more routers]-------D
+            |
+       S2---+
+
+       Figure 3:  Network Diagram for Host-to-Subnet Example
+
+
+
+
+
+
+Atkinson                     Informational                      [Page 5]
+
+RFC 2230           DNS Key Exchange Delegation Record      November 1997
+
+
+   In this example, D makes the policy decision that IP Security is
+   needed for the packets from D to S.  Then D performs the secure DNS
+   lookup for S and discovers that a KX record for S exists and points
+   at R1.  If D only has the IP address of S, then it performs a secure
+   reverse DNS lookup on the IP address of S prior to the forward secure
+   DNS lookup for S.
+
+   D then initiates key management with R1, where R1 is acting on behalf
+   of S, to create an appropriate Security Association.  Because D is
+   acting as its own key exchanger, R1 does not need to perform a secure
+   DNS lookup for KX records associated with D.
+
+   D and R1 then create an appropriate IPsec Security Security
+   Association.  This IPsec Security Association is setup as a secure
+   tunnel with a source identity that dominates D's IP Address and a
+   destination identity that dominates R1's IP Address.  Because D
+   performs IPsec for itself, no proxy identity is needed in this IPsec
+   Security Association.  If the proxy identity is non-null in this
+   situation, then the proxy identity must dominate D's IP Address.
+
+   Finally, D sends secured IP packets to R1.  R1 receives those
+   packets, provides IPsec input processing (including appropriate
+   inner/outer IP address validation), and forwards valid packets along
+   to S.
+
+2.2 Other Examples
+
+   This mechanism can be extended for use with other services as well.
+   To give some insight into other possible uses, this section discusses
+   use of KX records in environments using a Key Distribution Center
+   (KDC), such as Kerberos [KN93], and a possible use of KX records in
+   conjunction with mobile nodes accessing the network via a dialup
+   service.
+
+2.2.1 KDC Examples
+
+   This example considers the situation of a destination node
+   implementing IPsec that can only obtain its Security Association
+   information from a Key Distribution Center (KDC).  Let the KDC
+   implement both the KDC protocol and also a non-KDC key management
+   protocol (e.g. ISAKMP).  In such a case, each client node of the KDC
+   might have its own KX record pointing at the KDC so that nodes not
+   implementing the KDC protocol can still create Security Associations
+   with each of the client nodes of the KDC.
+
+   In the event the session initiator were not using the KDC but the
+   session target was an IPsec node that only used the KDC, the
+   initiator would find the KX record for the target pointing at the
+
+
+
+Atkinson                     Informational                      [Page 6]
+
+RFC 2230           DNS Key Exchange Delegation Record      November 1997
+
+
+   KDC.  Then, the external key management exchange (e.g. ISAKMP) would
+   be between the initiator and the KDC.  Then the KDC would distribute
+   the IPsec SA to the KDC-only IPsec node using the KDC.  The IPsec
+   traffic itself could travel directly between the initiator and the
+   destination node.
+
+   In the event the initiator node could only use the KDC and the target
+   were not using the KDC, the initiator would send its request for a
+   key to the KDC.  The KDC would then initiate an external key
+   management exchange (e.g. ISAKMP) with a node that the target's KX
+   record(s) pointed to, on behalf of the initiator node.
+
+   The target node could verify that the KDC were allowed to proxy for
+   the initiator node by looking up the KX records for the initiator
+   node and finding a KX record for the initiator that listed the KDC.
+
+   Then the external key exchange would be performed between the KDC and
+   the target node.  Then the KDC would distribute the resulting IPsec
+   Security Association to the initiator.  Again, IPsec traffic itself
+   could travel directly between the initiator and the destination.
+
+2.2.2 Dial-Up Host Example
+
+   This example outlines a possible use of KX records with mobile hosts
+   that dial into the network via PPP and are dynamically assigned an IP
+   address and domain-name at dial-in time.
+
+   Consider the situation where each mobile node is dynamically assigned
+   both a domain name and an IP address at the time that node dials into
+   the network.  Let the policy require that each mobile node act as its
+   own Key Exchanger.  In this case, it is important that dial-in nodes
+   use addresses from one or more well known IP subnets or address pools
+   dedicated to dial-in access.  If that is true, then no KX record or
+   other action is needed to ensure that each node will act as its own
+   Key Exchanger because lack of a KX record indicates that the node is
+   its own Key Exchanger.
+
+   Consider the situation where the mobile node's domain name remains
+   constant but its IP address changes.  Let the policy require that
+   each mobile node act as its own Key Exchanger.  In this case, there
+   might be operational problems when another node attempts to perform a
+   secure reverse DNS lookup on the IP address to determine the
+   corresponding domain name.  The authenticated DNS binding (in the
+   form of a PTR record) between the mobile node's currently assigned IP
+   address and its permanent domain name will need to be securely
+   updated each time the node is assigned a new IP address.  There are
+   no mechanisms for accomplishing this that are both IETF-standard and
+   widely deployed as of the time this note was written.  Use of Dynamic
+
+
+
+Atkinson                     Informational                      [Page 7]
+
+RFC 2230           DNS Key Exchange Delegation Record      November 1997
+
+
+   DNS Update without authentication is a significant security risk and
+   hence is not recommended for this situation.
+
+3. SYNTAX OF KX RECORD
+
+   A KX record has the DNS TYPE of "KX" and a numeric value of 36.  A KX
+   record is a member of the Internet ("IN") CLASS in the DNS.  Each KX
+   record is associated with a <domain-name> entry in the DNS.  A KX
+   record has the following textual syntax:
+
+        <domain-name>  IN  KX  <preference> <domain-name>
+
+   For this description, let the <domain-name> item to the left of the
+   "KX" string be called <domain-name 1> and the <domain-name> item to
+   the right of the "KX" string be called <domain-name 2>.  <preference>
+   is a non-negative integer.
+
+   Internet nodes about to initiate a key exchange with <domain-name 1>
+   should instead contact <domain-name 2> to initiate the key exchange
+   for a security service between the initiator and <domain-name 2>.  If
+   more than one KX record exists for <domain-name 1>, then the
+   <preference> field is used to indicate preference among the systems
+   delegated to.  Lower values are preferred over higher values.  The
+   <domain-name 2> is authorised to provide key exchange services on
+   behalf of <domain-name 1>.  The <domain-name 2> MUST have a CNAME
+   record, an A record, or an AAAA record associated with it.
+
+3.1 KX RDATA format
+
+   The KX DNS record has the following RDATA format:
+
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    |                  PREFERENCE                   |
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+    /                   EXCHANGER                   /
+    /                                               /
+    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+   where:
+
+   PREFERENCE      A 16 bit non-negative integer which specifies the
+                   preference given to this RR among other KX records
+                   at the same owner.  Lower values are preferred.
+
+   EXCHANGER       A <domain-name> which specifies a host willing to
+                   act as a mail exchange for the owner name.
+
+
+
+
+
+Atkinson                     Informational                      [Page 8]
+
+RFC 2230           DNS Key Exchange Delegation Record      November 1997
+
+
+   KX records MUST cause type A additional section processing for the
+   host specified by EXCHANGER.  In the event that the host processing
+   the DNS transaction supports IPv6, KX records MUST also cause type
+   AAAA additional section processing.
+
+   The KX RDATA field MUST NOT be compressed.
+
+4. SECURITY CONSIDERATIONS
+
+   KX records MUST always be signed using the method(s) defined by the
+   DNS Security extensions specified in [RFC-2065].  All unsigned KX
+   records MUST be ignored because of the security vulnerability caused
+   by assuming that unsigned records are valid.  All signed KX records
+   whose signatures do not correctly validate MUST be ignored because of
+   the potential security vulnerability in trusting an invalid KX
+   record.
+
+   KX records MUST be ignored by systems not implementing Secure DNS
+   because such systems have no mechanism to authenticate the KX record.
+
+   If a node does not have a permanent DNS entry and some form of
+   Dynamic DNS Update is in use, then those dynamic DNS updates MUST be
+   fully authenticated to prevent an adversary from injecting false DNS
+   records (especially the KX, A, and PTR records) into the Domain Name
+   System.  If false records were inserted into the DNS without being
+   signed by the Secure DNS mechanisms, then a denial-of-service attack
+   results.  If false records were inserted into the DNS and were
+   (erroneously) signed by the signing authority, then an active attack
+   results.
+
+   Myriad serious security vulnerabilities can arise if the restrictions
+   throuhout this document are not strictly adhered to.  Implementers
+   should carefully consider the openly published issues relating to DNS
+   security [Bell95,Vixie95] as they build their implementations.
+   Readers should also consider the security considerations discussed in
+   the DNS Security Extensions document [RFC-2065].
+
+5. REFERENCES
+
+
+   [RFC-1825]  Atkinson, R., "IP Authentication Header", RFC 1826,
+               August 1995.
+
+   [RFC-1827]  Atkinson, R., "IP Encapsulating Security Payload",
+               RFC 1827, August 1995.
+
+
+
+
+
+
+Atkinson                     Informational                      [Page 9]
+
+RFC 2230           DNS Key Exchange Delegation Record      November 1997
+
+
+   [Bell95] Bellovin, S., "Using the Domain Name System for System
+            Break-ins", Proceedings of 5th USENIX UNIX Security
+            Symposium, USENIX Association, Berkeley, CA, June 1995.
+            ftp://ftp.research.att.com/dist/smb/dnshack.ps
+
+   [RFC-2065]  Eastlake, D., and C. Kaufman, "Domain Name System
+               Security Extensions", RFC 2065, January 1997.
+
+   [RFC-1510]  Kohl J., and C. Neuman, "The Kerberos Network
+               Authentication Service", RFC 1510, September 1993.
+
+   [RFC-1035]  Mockapetris, P., "Domain names - implementation and
+               specification", STD 13, RFC 1035, November 1987.
+
+   [RFC-1034]  Mockapetris, P., "Domain names - concepts and
+               facilities", STD 13, RFC 1034, November 1987.
+
+   [Vixie95] P. Vixie, "DNS and BIND Security Issues", Proceedings of
+             the 5th USENIX UNIX Security Symposium, USENIX
+             Association, Berkeley, CA, June 1995.
+             ftp://ftp.vix.com/pri/vixie/bindsec.psf
+
+ACKNOWLEDGEMENTS
+
+   Development of this DNS record was primarily performed during 1993
+   through 1995.  The author's work on this was sponsored jointly by the
+   Computing Systems Technology Office (CSTO) of the Advanced Research
+   Projects Agency (ARPA) and by the Information Security Program Office
+   (PD71E), Space & Naval Warface Systems Command (SPAWAR).  In that
+   era, Dave Mihelcic and others provided detailed review and
+   constructive feedback.  More recently, Bob Moscowitz and Todd Welch
+   provided detailed review and constructive feedback of a work in
+   progress version of this document.
+
+AUTHOR'S ADDRESS
+
+   Randall Atkinson
+   Code 5544
+   Naval Research Laboratory
+   4555 Overlook Avenue, SW
+   Washington, DC 20375-5337
+
+   Phone: (DSN) 354-8590
+   EMail: atkinson@itd.nrl.navy.mil
+
+
+
+
+
+
+
+Atkinson                     Informational                     [Page 10]
+
+RFC 2230           DNS Key Exchange Delegation Record      November 1997
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (1997).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implmentation may be prepared, copied, published
+   andand distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Atkinson                     Informational                     [Page 11]
+
diff --git a/doc/rfc/rfc2308.txt b/doc/rfc/rfc2308.txt
new file mode 100644
index 0000000..9123a95
--- /dev/null
+++ b/doc/rfc/rfc2308.txt
@@ -0,0 +1,1067 @@
+
+
+
+
+
+
+Network Working Group                                          M. Andrews
+Request for Comments: 2308                                          CSIRO
+Updates: 1034, 1035                                            March 1998
+Category: Standards Track
+
+
+              Negative Caching of DNS Queries (DNS NCACHE)
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1998).  All Rights Reserved.
+
+Abstract
+
+   [RFC1034] provided a description of how to cache negative responses.
+   It however had a fundamental flaw in that it did not allow a name
+   server to hand out those cached responses to other resolvers, thereby
+   greatly reducing the effect of the caching.  This document addresses
+   issues raise in the light of experience and replaces [RFC1034 Section
+   4.3.4].
+
+   Negative caching was an optional part of the DNS specification and
+   deals with the caching of the non-existence of an RRset [RFC2181] or
+   domain name.
+
+   Negative caching is useful as it reduces the response time for
+   negative answers.  It also reduces the number of messages that have
+   to be sent between resolvers and name servers hence overall network
+   traffic.  A large proportion of DNS traffic on the Internet could be
+   eliminated if all resolvers implemented negative caching.  With this
+   in mind negative caching should no longer be seen as an optional part
+   of a DNS resolver.
+
+
+
+
+
+
+
+
+
+
+
+Andrews                     Standards Track                     [Page 1]
+
+RFC 2308                       DNS NCACHE                     March 1998
+
+
+1 - Terminology
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+   "Negative caching" - the storage of knowledge that something does not
+   exist.  We can store the knowledge that a record has a particular
+   value.  We can also do the reverse, that is, to store the knowledge
+   that a record does not exist.  It is the storage of knowledge that
+   something does not exist, cannot or does not give an answer that we
+   call negative caching.
+
+   "QNAME" - the name in the query section of an answer, or where this
+   resolves to a CNAME, or CNAME chain, the data field of the last
+   CNAME.  The last CNAME in this sense is that which contains a value
+   which does not resolve to another CNAME.  Implementations should note
+   that including CNAME records in responses in order, so that the first
+   has the label from the query section, and then each in sequence has
+   the label from the data section of the previous (where more than one
+   CNAME is needed) allows the sequence to be processed in one pass, and
+   considerably eases the task of the receiver.  Other relevant records
+   (such as SIG RRs [RFC2065]) can be interspersed amongst the CNAMEs.
+
+   "NXDOMAIN" - an alternate expression for the "Name Error" RCODE as
+   described in [RFC1035 Section 4.1.1] and the two terms are used
+   interchangeably in this document.
+
+   "NODATA" - a pseudo RCODE which indicates that the name is valid, for
+   the given class, but are no records of the given type.  A NODATA
+   response has to be inferred from the answer.
+
+   "FORWARDER" - a nameserver used to resolve queries instead of
+   directly using the authoritative nameserver chain.  The forwarder
+   typically either has better access to the internet, or maintains a
+   bigger cache which may be shared amongst many resolvers.  How a
+   server is identified as a FORWARDER, or knows it is a FORWARDER is
+   outside the scope of this document.  However if you are being used as
+   a forwarder the query will have the recursion desired flag set.
+
+   An understanding of [RFC1034], [RFC1035] and [RFC2065] is expected
+   when reading this document.
+
+
+
+
+
+
+
+
+
+Andrews                     Standards Track                     [Page 2]
+
+RFC 2308                       DNS NCACHE                     March 1998
+
+
+2 - Negative Responses
+
+   The most common negative responses indicate that a particular RRset
+   does not exist in the DNS.  The first sections of this document deal
+   with this case.  Other negative responses can indicate failures of a
+   nameserver, those are dealt with in section 7 (Other Negative
+   Responses).
+
+   A negative response is indicated by one of the following conditions:
+
+2.1 - Name Error
+
+   Name errors (NXDOMAIN) are indicated by the presence of "Name Error"
+   in the RCODE field.  In this case the domain referred to by the QNAME
+   does not exist.  Note: the answer section may have SIG and CNAME RRs
+   and the authority section may have SOA, NXT [RFC2065] and SIG RRsets.
+
+   It is possible to distinguish between a referral and a NXDOMAIN
+   response by the presense of NXDOMAIN in the RCODE regardless of the
+   presence of NS or SOA records in the authority section.
+
+   NXDOMAIN responses can be categorised into four types by the contents
+   of the authority section.  These are shown below along with a
+   referral for comparison.  Fields not mentioned are not important in
+   terms of the examples.
+
+           NXDOMAIN RESPONSE: TYPE 1.
+
+           Header:
+               RDCODE=NXDOMAIN
+           Query:
+               AN.EXAMPLE. A
+           Answer:
+               AN.EXAMPLE. CNAME TRIPPLE.XX.
+           Authority:
+               XX. SOA NS1.XX. HOSTMASTER.NS1.XX. ....
+               XX. NS NS1.XX.
+               XX. NS NS2.XX.
+           Additional:
+               NS1.XX. A 127.0.0.2
+               NS2.XX. A 127.0.0.3
+
+           NXDOMAIN RESPONSE: TYPE 2.
+
+           Header:
+               RDCODE=NXDOMAIN
+           Query:
+               AN.EXAMPLE. A
+
+
+
+Andrews                     Standards Track                     [Page 3]
+
+RFC 2308                       DNS NCACHE                     March 1998
+
+
+           Answer:
+               AN.EXAMPLE. CNAME TRIPPLE.XX.
+           Authority:
+               XX. SOA NS1.XX. HOSTMASTER.NS1.XX. ....
+           Additional:
+               <empty>
+
+           NXDOMAIN RESPONSE: TYPE 3.
+
+           Header:
+               RDCODE=NXDOMAIN
+           Query:
+               AN.EXAMPLE. A
+           Answer:
+               AN.EXAMPLE. CNAME TRIPPLE.XX.
+           Authority:
+               <empty>
+           Additional:
+               <empty>
+
+           NXDOMAIN RESPONSE: TYPE 4
+
+           Header:
+               RDCODE=NXDOMAIN
+           Query:
+               AN.EXAMPLE. A
+           Answer:
+               AN.EXAMPLE. CNAME TRIPPLE.XX.
+           Authority:
+               XX. NS NS1.XX.
+               XX. NS NS2.XX.
+           Additional:
+               NS1.XX. A 127.0.0.2
+               NS2.XX. A 127.0.0.3
+
+           REFERRAL RESPONSE.
+
+           Header:
+               RDCODE=NOERROR
+           Query:
+               AN.EXAMPLE. A
+           Answer:
+               AN.EXAMPLE. CNAME TRIPPLE.XX.
+           Authority:
+               XX. NS NS1.XX.
+               XX. NS NS2.XX.
+           Additional:
+               NS1.XX. A 127.0.0.2
+
+
+
+Andrews                     Standards Track                     [Page 4]
+
+RFC 2308                       DNS NCACHE                     March 1998
+
+
+               NS2.XX. A 127.0.0.3
+
+   Note, in the four examples of NXDOMAIN responses, it is known that
+   the name "AN.EXAMPLE." exists, and has as its value a CNAME record.
+   The NXDOMAIN refers to "TRIPPLE.XX", which is then known not to
+   exist.  On the other hand, in the referral example, it is shown that
+   "AN.EXAMPLE" exists, and has a CNAME RR as its value, but nothing is
+   known one way or the other about the existence of "TRIPPLE.XX", other
+   than that "NS1.XX" or "NS2.XX" can be consulted as the next step in
+   obtaining information about it.
+
+   Where no CNAME records appear, the NXDOMAIN response refers to the
+   name in the label of the RR in the question section.
+
+2.1.1 Special Handling of Name Error
+
+   This section deals with errors encountered when implementing negative
+   caching of NXDOMAIN responses.
+
+   There are a large number of resolvers currently in existence that
+   fail to correctly detect and process all forms of NXDOMAIN response.
+   Some resolvers treat a TYPE 1 NXDOMAIN response as a referral.  To
+   alleviate this problem it is recommended that servers that are
+   authoritative for the NXDOMAIN response only send TYPE 2 NXDOMAIN
+   responses, that is the authority section contains a SOA record and no
+   NS records.  If a non- authoritative server sends a type 1 NXDOMAIN
+   response to one of these old resolvers, the result will be an
+   unnecessary query to an authoritative server.  This is undesirable,
+   but not fatal except when the server is being used a FORWARDER.  If
+   however the resolver is using the server as a FORWARDER to such a
+   resolver it will be necessary to disable the sending of TYPE 1
+   NXDOMAIN response to it, use TYPE 2 NXDOMAIN instead.
+
+   Some resolvers incorrectly continue processing if the authoritative
+   answer flag is not set, looping until the query retry threshold is
+   exceeded and then returning SERVFAIL.  This is a problem when your
+   nameserver is listed as a FORWARDER for such resolvers.  If the
+   nameserver is used as a FORWARDER by such resolver, the authority
+   flag will have to be forced on for NXDOMAIN responses to these
+   resolvers.  In practice this causes no problems even if turned on
+   always, and has been the default behaviour in BIND from 4.9.3
+   onwards.
+
+2.2 - No Data
+
+   NODATA is indicated by an answer with the RCODE set to NOERROR and no
+   relevant answers in the answer section.  The authority section will
+   contain an SOA record, or there will be no NS records there.
+
+
+
+Andrews                     Standards Track                     [Page 5]
+
+RFC 2308                       DNS NCACHE                     March 1998
+
+
+   NODATA responses have to be algorithmically determined from the
+   response's contents as there is no RCODE value to indicate NODATA.
+   In some cases to determine with certainty that NODATA is the correct
+   response it can be necessary to send another query.
+
+   The authority section may contain NXT and SIG RRsets in addition to
+   NS and SOA records.  CNAME and SIG records may exist in the answer
+   section.
+
+   It is possible to distinguish between a NODATA and a referral
+   response by the presence of a SOA record in the authority section or
+   the absence of NS records in the authority section.
+
+   NODATA responses can be categorised into three types by the contents
+   of the authority section.  These are shown below along with a
+   referral for comparison.  Fields not mentioned are not important in
+   terms of the examples.
+
+           NODATA RESPONSE: TYPE 1.
+
+           Header:
+               RDCODE=NOERROR
+           Query:
+               ANOTHER.EXAMPLE. A
+           Answer:
+               <empty>
+           Authority:
+               EXAMPLE. SOA NS1.XX. HOSTMASTER.NS1.XX. ....
+               EXAMPLE. NS NS1.XX.
+               EXAMPLE. NS NS2.XX.
+           Additional:
+               NS1.XX. A 127.0.0.2
+               NS2.XX. A 127.0.0.3
+
+           NO DATA RESPONSE: TYPE 2.
+
+           Header:
+               RDCODE=NOERROR
+           Query:
+               ANOTHER.EXAMPLE. A
+           Answer:
+               <empty>
+           Authority:
+               EXAMPLE. SOA NS1.XX. HOSTMASTER.NS1.XX. ....
+           Additional:
+               <empty>
+
+
+
+
+
+Andrews                     Standards Track                     [Page 6]
+
+RFC 2308                       DNS NCACHE                     March 1998
+
+
+           NO DATA RESPONSE: TYPE 3.
+
+           Header:
+               RDCODE=NOERROR
+           Query:
+               ANOTHER.EXAMPLE. A
+           Answer:
+               <empty>
+           Authority:
+               <empty>
+           Additional:
+               <empty>
+
+           REFERRAL RESPONSE.
+
+           Header:
+               RDCODE=NOERROR
+           Query:
+               ANOTHER.EXAMPLE. A
+           Answer:
+               <empty>
+           Authority:
+               EXAMPLE. NS NS1.XX.
+               EXAMPLE. NS NS2.XX.
+           Additional:
+               NS1.XX. A 127.0.0.2
+               NS2.XX. A 127.0.0.3
+
+
+   These examples, unlike the NXDOMAIN examples above, have no CNAME
+   records, however they could, in just the same way that the NXDOMAIN
+   examples did, in which case it would be the value of the last CNAME
+   (the QNAME) for which NODATA would be concluded.
+
+2.2.1 - Special Handling of No Data
+
+   There are a large number of resolvers currently in existence that
+   fail to correctly detect and process all forms of NODATA response.
+   Some resolvers treat a TYPE 1 NODATA response as a referral.  To
+   alleviate this problem it is recommended that servers that are
+   authoritative for the NODATA response only send TYPE 2 NODATA
+   responses, that is the authority section contains a SOA record and no
+   NS records.  Sending a TYPE 1 NODATA response from a non-
+   authoritative server to one of these resolvers will only result in an
+   unnecessary query.  If a server is listed as a FORWARDER for another
+   resolver it may also be necessary to disable the sending of TYPE 1
+   NODATA response for non-authoritative NODATA responses.
+
+
+
+
+Andrews                     Standards Track                     [Page 7]
+
+RFC 2308                       DNS NCACHE                     March 1998
+
+
+   Some name servers fail to set the RCODE to NXDOMAIN in the presence
+   of CNAMEs in the answer section.  If a definitive NXDOMAIN / NODATA
+   answer is required in this case the resolver must query again using
+   the QNAME as the query label.
+
+3 - Negative Answers from Authoritative Servers
+
+   Name servers authoritative for a zone MUST include the SOA record of
+   the zone in the authority section of the response when reporting an
+   NXDOMAIN or indicating that no data of the requested type exists.
+   This is required so that the response may be cached.  The TTL of this
+   record is set from the minimum of the MINIMUM field of the SOA record
+   and the TTL of the SOA itself, and indicates how long a resolver may
+   cache the negative answer.  The TTL SIG record associated with the
+   SOA record should also be trimmed in line with the SOA's TTL.
+
+   If the containing zone is signed [RFC2065] the SOA and appropriate
+   NXT and SIG records MUST be added.
+
+4 - SOA Minimum Field
+
+   The SOA minimum field has been overloaded in the past to have three
+   different meanings, the minimum TTL value of all RRs in a zone, the
+   default TTL of RRs which did not contain a TTL value and the TTL of
+   negative responses.
+
+   Despite being the original defined meaning, the first of these, the
+   minimum TTL value of all RRs in a zone, has never in practice been
+   used and is hereby deprecated.
+
+   The second, the default TTL of RRs which contain no explicit TTL in
+   the master zone file, is relevant only at the primary server.  After
+   a zone transfer all RRs have explicit TTLs and it is impossible to
+   determine whether the TTL for a record was explicitly set or derived
+   from the default after a zone transfer.  Where a server does not
+   require RRs to include the TTL value explicitly, it should provide a
+   mechanism, not being the value of the MINIMUM field of the SOA
+   record, from which the missing TTL values are obtained.  How this is
+   done is implementation dependent.
+
+   The Master File format [RFC 1035 Section 5] is extended to include
+   the following directive:
+
+                           $TTL <TTL> [comment]
+
+
+
+
+
+
+
+Andrews                     Standards Track                     [Page 8]
+
+RFC 2308                       DNS NCACHE                     March 1998
+
+
+   All resource records appearing after the directive, and which do not
+   explicitly include a TTL value, have their TTL set to the TTL given
+   in the $TTL directive.  SIG records without a explicit TTL get their
+   TTL from the "original TTL" of the SIG record [RFC 2065 Section 4.5].
+
+   The remaining of the current meanings, of being the TTL to be used
+   for negative responses, is the new defined meaning of the SOA minimum
+   field.
+
+5 - Caching Negative Answers
+
+   Like normal answers negative answers have a time to live (TTL).  As
+   there is no record in the answer section to which this TTL can be
+   applied, the TTL must be carried by another method.  This is done by
+   including the SOA record from the zone in the authority section of
+   the reply.  When the authoritative server creates this record its TTL
+   is taken from the minimum of the SOA.MINIMUM field and SOA's TTL.
+   This TTL decrements in a similar manner to a normal cached answer and
+   upon reaching zero (0) indicates the cached negative answer MUST NOT
+   be used again.
+
+   A negative answer that resulted from a name error (NXDOMAIN) should
+   be cached such that it can be retrieved and returned in response to
+   another query for the same <QNAME, QCLASS> that resulted in the
+   cached negative response.
+
+   A negative answer that resulted from a no data error (NODATA) should
+   be cached such that it can be retrieved and returned in response to
+   another query for the same <QNAME, QTYPE, QCLASS> that resulted in
+   the cached negative response.
+
+   The NXT record, if it exists in the authority section of a negative
+   answer received, MUST be stored such that it can be be located and
+   returned with SOA record in the authority section, as should any SIG
+   records in the authority section.  For NXDOMAIN answers there is no
+   "necessary" obvious relationship between the NXT records and the
+   QNAME.  The NXT record MUST have the same owner name as the query
+   name for NODATA responses.
+
+   Negative responses without SOA records SHOULD NOT be cached as there
+   is no way to prevent the negative responses looping forever between a
+   pair of servers even with a short TTL.
+
+   Despite the DNS forming a tree of servers, with various mis-
+   configurations it is possible to form a loop in the query graph, e.g.
+   two servers listing each other as forwarders, various lame server
+   configurations.  Without a TTL count down a cache negative response
+
+
+
+
+Andrews                     Standards Track                     [Page 9]
+
+RFC 2308                       DNS NCACHE                     March 1998
+
+
+   when received by the next server would have its TTL reset.  This
+   negative indication could then live forever circulating between the
+   servers involved.
+
+   As with caching positive responses it is sensible for a resolver to
+   limit for how long it will cache a negative response as the protocol
+   supports caching for up to 68 years.  Such a limit should not be
+   greater than that applied to positive answers and preferably be
+   tunable.  Values of one to three hours have been found to work well
+   and would make sensible a default.  Values exceeding one day have
+   been found to be problematic.
+
+6 - Negative answers from the cache
+
+   When a server, in answering a query, encounters a cached negative
+   response it MUST add the cached SOA record to the authority section
+   of the response with the TTL decremented by the amount of time it was
+   stored in the cache.  This allows the NXDOMAIN / NODATA response to
+   time out correctly.
+
+   If a NXT record was cached along with SOA record it MUST be added to
+   the authority section.  If a SIG record was cached along with a NXT
+   record it SHOULD be added to the authority section.
+
+   As with all answers coming from the cache, negative answers SHOULD
+   have an implicit referral built into the answer.  This enables the
+   resolver to locate an authoritative source.  An implicit referral is
+   characterised by NS records in the authority section referring the
+   resolver towards a authoritative source.  NXDOMAIN types 1 and 4
+   responses contain implicit referrals as does NODATA type 1 response.
+
+7 - Other Negative Responses
+
+   Caching of other negative responses is not covered by any existing
+   RFC.  There is no way to indicate a desired TTL in these responses.
+   Care needs to be taken to ensure that there are not forwarding loops.
+
+7.1 Server Failure (OPTIONAL)
+
+   Server failures fall into two major classes.  The first is where a
+   server can determine that it has been misconfigured for a zone.  This
+   may be where it has been listed as a server, but not configured to be
+   a server for the zone, or where it has been configured to be a server
+   for the zone, but cannot obtain the zone data for some reason.  This
+   can occur either because the zone file does not exist or contains
+   errors, or because another server from which the zone should have
+   been available either did not respond or was unable or unwilling to
+   supply the zone.
+
+
+
+Andrews                     Standards Track                    [Page 10]
+
+RFC 2308                       DNS NCACHE                     March 1998
+
+
+   The second class is where the server needs to obtain an answer from
+   elsewhere, but is unable to do so, due to network failures, other
+   servers that don't reply, or return server failure errors, or
+   similar.
+
+   In either case a resolver MAY cache a server failure response.  If it
+   does so it MUST NOT cache it for longer than five (5) minutes, and it
+   MUST be cached against the specific query tuple <query name, type,
+   class, server IP address>.
+
+7.2 Dead / Unreachable Server (OPTIONAL)
+
+   Dead / Unreachable servers are servers that fail to respond in any
+   way to a query or where the transport layer has provided an
+   indication that the server does not exist or is unreachable.  A
+   server may be deemed to be dead or unreachable if it has not
+   responded to an outstanding query within 120 seconds.
+
+   Examples of transport layer indications are:
+
+      ICMP error messages indicating host, net or port unreachable.
+      TCP resets
+      IP stack error messages providing similar indications to those above.
+
+   A server MAY cache a dead server indication.  If it does so it MUST
+   NOT be deemed dead for longer than five (5) minutes.  The indication
+   MUST be stored against query tuple <query name, type, class, server
+   IP address> unless there was a transport layer indication that the
+   server does not exist, in which case it applies to all queries to
+   that specific IP address.
+
+8 - Changes from RFC 1034
+
+   Negative caching in resolvers is no-longer optional, if a resolver
+   caches anything it must also cache negative answers.
+
+   Non-authoritative negative answers MAY be cached.
+
+   The SOA record from the authority section MUST be cached.  Name error
+   indications must be cached against the tuple <query name, QCLASS>.
+   No data indications must be cached against <query name, QTYPE,
+   QCLASS> tuple.
+
+   A cached SOA record must be added to the response.  This was
+   explicitly not allowed because previously the distinction between a
+   normal cached SOA record, and the SOA cached as a result of a
+   negative response was not made, and simply extracting a normal cached
+   SOA and adding that to a cached negative response causes problems.
+
+
+
+Andrews                     Standards Track                    [Page 11]
+
+RFC 2308                       DNS NCACHE                     March 1998
+
+
+   The $TTL TTL directive was added to the master file format.
+
+9 - History of Negative Caching
+
+   This section presents a potted history of negative caching in the DNS
+   and forms no part of the technical specification of negative caching.
+
+   It is interesting to note that the same concepts were re-invented in
+   both the CHIVES and BIND servers.
+
+   The history of the early CHIVES work (Section 9.1) was supplied by
+   Rob Austein <sra@epilogue.com> and is reproduced here in the form in
+   which he supplied it [MPA].
+
+   Sometime around the spring of 1985, I mentioned to Paul Mockapetris
+   that our experience with his JEEVES DNS resolver had pointed out the
+   need for some kind of negative caching scheme.  Paul suggested that
+   we simply cache authoritative errors, using the SOA MINIMUM value for
+   the zone that would have contained the target RRs.  I'm pretty sure
+   that this conversation took place before RFC-973 was written, but it
+   was never clear to me whether this idea was something that Paul came
+   up with on the spot in response to my question or something he'd
+   already been planning to put into the document that became RFC-973.
+   In any case, neither of us was entirely sure that the SOA MINIMUM
+   value was really the right metric to use, but it was available and
+   was under the control of the administrator of the target zone, both
+   of which seemed to us at the time to be important feature.
+
+   Late in 1987, I released the initial beta-test version of CHIVES, the
+   DNS resolver I'd written to replace Paul's JEEVES resolver.  CHIVES
+   included a search path mechanism that was used pretty heavily at
+   several sites (including my own), so CHIVES also included a negative
+   caching mechanism based on SOA MINIMUM values.  The basic strategy
+   was to cache authoritative error codes keyed by the exact query
+   parameters (QNAME, QCLASS, and QTYPE), with a cache TTL equal to the
+   SOA MINIMUM value.  CHIVES did not attempt to track down SOA RRs if
+   they weren't supplied in the authoritative response, so it never
+   managed to completely eliminate the gratuitous DNS error message
+   traffic, but it did help considerably.  Keep in mind that this was
+   happening at about the same time as the near-collapse of the ARPANET
+   due to congestion caused by exponential growth and the the "old"
+   (pre-VJ) TCP retransmission algorithm, so negative caching resulted
+   in drasticly better DNS response time for our users, mailer daemons,
+   etcetera.
+
+
+
+
+
+
+
+Andrews                     Standards Track                    [Page 12]
+
+RFC 2308                       DNS NCACHE                     March 1998
+
+
+   As far as I know, CHIVES was the first resolver to implement negative
+   caching.  CHIVES was developed during the twilight years of TOPS-20,
+   so it never ran on very many machines, but the few machines that it
+   did run on were the ones that were too critical to shut down quickly
+   no matter how much it cost to keep them running.  So what few users
+   we did have tended to drive CHIVES pretty hard.  Several interesting
+   bits of DNS technology resulted from that, but the one that's
+   relevant here is the MAXTTL configuration parameter.
+
+   Experience with JEEVES had already shown that RRs often showed up
+   with ridiculously long TTLs (99999999 was particularly popular for
+   many years, due to bugs in the code and documentation of several
+   early versions of BIND), and that robust software that blindly
+   believed such TTLs could create so many strange failures that it was
+   often necessary to reboot the resolver frequently just to clear this
+   garbage out of the cache.  So CHIVES had a configuration parameter
+   "MAXTTL", which specified the maximum "reasonable" TTL in a received
+   RR.  RRs with TTLs greater than MAXTTL would either have their TTLs
+   reduced to MAXTTL or would be discarded entirely, depending on the
+   setting of another configuration parameter.
+
+   When we started getting field experience with CHIVES's negative
+   caching code, it became clear that the SOA MINIMUM value was often
+   large enough to cause the same kinds of problems for negative caching
+   as the huge TTLs in RRs had for normal caching (again, this was in
+   part due to a bug in several early versions of BIND, where a
+   secondary server would authoritatively deny all knowledge of its
+   zones if it couldn't contact the primaries on reboot).  So we started
+   running the negative cache TTLs through the MAXTTL check too, and
+   continued to experiment.
+
+   The configuration that seemed to work best on WSMR-SIMTEL20.ARMY.MIL
+   (last of the major Internet TOPS-20 machines to be shut down, thus
+   the last major user of CHIVES, thus the place where we had the
+   longest experimental baseline) was to set MAXTTL to about three days.
+   Most of the traffic initiated by SIMTEL20 in its last years was
+   mail-related, and the mail queue timeout was set to one week, so this
+   gave a "stuck" message several tries at complete DNS resolution,
+   without bogging down the system with a lot of useless queries.  Since
+   (for reasons that now escape me) we only had the single MAXTTL
+   parameter rather than separate ones for positive and negative
+   caching, it's not clear how much effect this setting of MAXTTL had on
+   the negative caching code.
+
+   CHIVES also included a second, somewhat controversial mechanism which
+   took the place of negative caching in some cases.  The CHIVES
+   resolver daemon could be configured to load DNS master files, giving
+   it the ability to act as what today would be called a "stealth
+
+
+
+Andrews                     Standards Track                    [Page 13]
+
+RFC 2308                       DNS NCACHE                     March 1998
+
+
+   secondary".  That is, when configured in this way, the resolver had
+   direct access to authoritative information for heavily-used zones.
+   The search path mechanisms in CHIVES reflected this: there were
+   actually two separate search paths, one of which only searched local
+   authoritative zone data, and one which could generate normal
+   iterative queries.  This cut down on the need for negative caching in
+   cases where usage was predictably heavy (e.g., the resolver on
+   XX.LCS.MIT.EDU always loaded the zone files for both LCS.MIT.EDU and
+   AI.MIT.EDU and put both of these suffixes into the "local" search
+   path, since between them the hosts in these two zones accounted for
+   the bulk of the DNS traffic).  Not all sites running CHIVES chose to
+   use this feature; C.CS.CMU.EDU, for example, chose to use the
+   "remote" search path for everything because there were too many
+   different sub-zones at CMU for zone shadowing to be practical for
+   them, so they relied pretty heavily on negative caching even for
+   local traffic.
+
+   Overall, I still think the basic design we used for negative caching
+   was pretty reasonable: the zone administrator specified how long to
+   cache negative answers, and the resolver configuration chose the
+   actual cache time from the range between zero and the period
+   specified by the zone administrator.  There are a lot of details I'd
+   do differently now (like using a new SOA field instead of overloading
+   the MINIMUM field), but after more than a decade, I'd be more worried
+   if we couldn't think of at least a few improvements.
+
+9.2 BIND
+
+   While not the first attempt to get negative caching into BIND, in
+   July 1993, BIND 4.9.2 ALPHA, Anant Kumar of ISI supplied code that
+   implemented, validation and negative caching (NCACHE).  This code had
+   a 10 minute TTL for negative caching and only cached the indication
+   that there was a negative response, NXDOMAIN or NOERROR_NODATA. This
+   is the origin of the NODATA pseudo response code mentioned above.
+
+   Mark Andrews of CSIRO added code (RETURNSOA) that stored the SOA
+   record such that it could be retrieved by a similar query.  UUnet
+   complained that they were getting old answers after loading a new
+   zone, and the option was turned off, BIND 4.9.3-alpha5, April 1994.
+   In reality this indicated that the named needed to purge the space
+   the zone would occupy.  Functionality to do this was added in BIND
+   4.9.3 BETA11 patch2, December 1994.
+
+   RETURNSOA was re-enabled by default, BIND 4.9.5-T1A, August 1996.
+
+
+
+
+
+
+
+Andrews                     Standards Track                    [Page 14]
+
+RFC 2308                       DNS NCACHE                     March 1998
+
+
+10 Example
+
+   The following example is based on a signed zone that is empty apart
+   from the nameservers.  We will query for WWW.XX.EXAMPLE showing
+   initial response and again 10 minutes later.  Note 1: during the
+   intervening 10 minutes the NS records for XX.EXAMPLE have expired.
+   Note 2: the TTL of the SIG records are not explicitly set in the zone
+   file and are hence the TTL of the RRset they are the signature for.
+
+        Zone File:
+
+        $TTL 86400
+        $ORIGIN XX.EXAMPLE.
+        @       IN      SOA     NS1.XX.EXAMPLE. HOSTMATER.XX.EXAMPLE. (
+                                1997102000      ; serial
+                                1800    ; refresh (30 mins)
+                                900     ; retry (15 mins)
+                                604800  ; expire (7 days)
+                                1200 ) ; minimum (20 mins)
+                IN      SIG     SOA ...
+          1200  IN      NXT     NS1.XX.EXAMPLE. A NXT SIG SOA NS KEY
+                IN      SIG     NXT ... XX.EXAMPLE. ...
+           300  IN      NS      NS1.XX.EXAMPLE.
+           300  IN      NS      NS2.XX.EXAMPLE.
+                IN      SIG     NS ... XX.EXAMPLE. ...
+                IN      KEY     0x4100 1 1 ...
+                IN      SIG     KEY ... XX.EXAMPLE. ...
+                IN      SIG     KEY ... EXAMPLE. ...
+        NS1     IN      A       10.0.0.1
+                IN      SIG     A ... XX.EXAMPLE. ...
+          1200  IN      NXT     NS2.XX.EXAMPLE. A NXT SIG
+                IN      SIG     NXT ...
+        NS2     IN      A       10.0.0.2
+                IN      SIG     A ... XX.EXAMPLE. ...
+          1200  IN      NXT     XX.EXAMPLE. A NXT SIG
+                IN      SIG     NXT ... XX.EXAMPLE. ...
+
+        Initial Response:
+
+        Header:
+            RDCODE=NXDOMAIN, AA=1, QR=1, TC=0
+        Query:
+            WWW.XX.EXAMPLE. IN A
+        Answer:
+            <empty>
+        Authority:
+            XX.EXAMPLE.      1200 IN SOA NS1.XX.EXAMPLE. ...
+            XX.EXAMPLE.      1200 IN SIG SOA ... XX.EXAMPLE. ...
+
+
+
+Andrews                     Standards Track                    [Page 15]
+
+RFC 2308                       DNS NCACHE                     March 1998
+
+
+            NS2.XX.EXAMPLE.  1200 IN NXT XX.EXAMPLE. NXT A NXT SIG
+            NS2.XX.EXAMPLE.  1200 IN SIG NXT ... XX.EXAMPLE. ...
+            XX.EXAMPLE.     86400 IN NS  NS1.XX.EXAMPLE.
+            XX.EXAMPLE.     86400 IN NS  NS2.XX.EXAMPLE.
+            XX.EXAMPLE.     86400 IN SIG NS ... XX.EXAMPLE. ...
+        Additional
+            XX.EXAMPLE.     86400 IN KEY 0x4100 1 1 ...
+            XX.EXAMPLE.     86400 IN SIG KEY ... EXAMPLE. ...
+            NS1.XX.EXAMPLE. 86400 IN A   10.0.0.1
+            NS1.XX.EXAMPLE. 86400 IN SIG A ... XX.EXAMPLE. ...
+            NS2.XX.EXAMPLE. 86400 IN A   10.0.0.2
+            NS3.XX.EXAMPLE. 86400 IN SIG A ... XX.EXAMPLE. ...
+
+         After 10 Minutes:
+
+         Header:
+             RDCODE=NXDOMAIN, AA=0, QR=1, TC=0
+         Query:
+             WWW.XX.EXAMPLE. IN A
+         Answer:
+             <empty>
+         Authority:
+             XX.EXAMPLE.       600 IN SOA NS1.XX.EXAMPLE. ...
+             XX.EXAMPLE.       600 IN SIG SOA ... XX.EXAMPLE. ...
+             NS2.XX.EXAMPLE.   600 IN NXT XX.EXAMPLE. NXT A NXT SIG
+             NS2.XX.EXAMPLE.   600 IN SIG NXT ... XX.EXAMPLE. ...
+             EXAMPLE.        65799 IN NS  NS1.YY.EXAMPLE.
+             EXAMPLE.        65799 IN NS  NS2.YY.EXAMPLE.
+             EXAMPLE.        65799 IN SIG NS ... XX.EXAMPLE. ...
+         Additional
+             XX.EXAMPLE.     65800 IN KEY 0x4100 1 1 ...
+             XX.EXAMPLE.     65800 IN SIG KEY ... EXAMPLE. ...
+             NS1.YY.EXAMPLE. 65799 IN A   10.100.0.1
+             NS1.YY.EXAMPLE. 65799 IN SIG A ... EXAMPLE. ...
+             NS2.YY.EXAMPLE. 65799 IN A   10.100.0.2
+             NS3.YY.EXAMPLE. 65799 IN SIG A ... EXAMPLE. ...
+             EXAMPLE.        65799 IN KEY 0x4100 1 1 ...
+             EXAMPLE.        65799 IN SIG KEY ... . ...
+
+
+11 Security Considerations
+
+   It is believed that this document does not introduce any significant
+   additional security threats other that those that already exist when
+   using data from the DNS.
+
+
+
+
+
+
+Andrews                     Standards Track                    [Page 16]
+
+RFC 2308                       DNS NCACHE                     March 1998
+
+
+   With negative caching it might be possible to propagate a denial of
+   service attack by spreading a NXDOMAIN message with a very high TTL.
+   Without negative caching that would be much harder.  A similar effect
+   could be achieved previously by spreading a bad A record, so that the
+   server could not be reached - which is almost the same.  It has the
+   same effect as far as what the end user is able to do, but with a
+   different psychological effect.  With the bad A, I feel "damn the
+   network is broken again" and try again tomorrow.  With the "NXDOMAIN"
+   I feel "Oh, they've turned off the server and it doesn't exist any
+   more" and probably never bother trying this server again.
+
+   A practical example of this is a SMTP server where this behaviour is
+   encoded.  With a NXDOMAIN attack the mail message would bounce
+   immediately, where as with a bad A attack the mail would be queued
+   and could potentially get through after the attack was suspended.
+
+   For such an attack to be successful, the NXDOMAIN indiction must be
+   injected into a parent server (or a busy caching resolver).  One way
+   this might be done by the use of a CNAME which results in the parent
+   server querying an attackers server.  Resolvers that wish to prevent
+   such attacks can query again the final QNAME ignoring any NS data in
+   the query responses it has received for this query.
+
+   Implementing TTL sanity checking will reduce the effectiveness of
+   such an attack, because a successful attack would require re-
+   injection of the bogus data at more frequent intervals.
+
+   DNS Security [RFC2065] provides a mechanism to verify whether a
+   negative response is valid or not, through the use of NXT and SIG
+   records.  This document supports the use of that mechanism by
+   promoting the transmission of the relevant security records even in a
+   non security aware server.
+
+Acknowledgments
+
+   I would like to thank Rob Austein for his history of the CHIVES
+   nameserver. The DNSIND working group, in particular Robert Elz for
+   his valuable technical and editorial contributions to this document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Andrews                     Standards Track                    [Page 17]
+
+RFC 2308                       DNS NCACHE                     March 1998
+
+
+References
+
+   [RFC1034]
+           Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES,"
+           STD 13, RFC 1034, November 1987.
+
+   [RFC1035]
+           Mockapetris, P., "DOMAIN NAMES - IMPLEMENTATION AND
+           SPECIFICATION," STD 13, RFC 1035, November 1987.
+
+   [RFC2065]
+           Eastlake, D., and C. Kaufman, "Domain Name System Security
+           Extensions," RFC 2065, January 1997.
+
+   [RFC2119]
+           Bradner, S., "Key words for use in RFCs to Indicate
+           Requirement Levels," BCP 14, RFC 2119, March 1997.
+
+   [RFC2181]
+           Elz, R., and R. Bush, "Clarifications to the DNS
+           Specification," RFC 2181, July 1997.
+
+Author's Address
+
+   Mark Andrews
+   CSIRO - Mathematical and Information Sciences
+   Locked Bag 17
+   North Ryde NSW 2113
+   AUSTRALIA
+
+   Phone: +61 2 9325 3148
+   EMail: Mark.Andrews@cmis.csiro.au
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Andrews                     Standards Track                    [Page 18]
+
+RFC 2308                       DNS NCACHE                     March 1998
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (1998).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Andrews                     Standards Track                    [Page 19]
+
diff --git a/doc/rfc/rfc2317.txt b/doc/rfc/rfc2317.txt
new file mode 100644
index 0000000..c17bb41
--- /dev/null
+++ b/doc/rfc/rfc2317.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+Network Working Group                                         H. Eidnes
+Request for Comments: 2317                                 SINTEF RUNIT
+BCP: 20                                                     G. de Groot
+Category: Best Current Practice          Berkeley Software Design, Inc.
+                                                               P. Vixie
+                                           Internet Software Consortium
+                                                             March 1998
+
+
+                   Classless IN-ADDR.ARPA delegation
+
+Status of this Memo
+
+   This document specifies an Internet Best Current Practices for the
+   Internet Community, and requests discussion and suggestions for
+   improvements.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1998).  All Rights Reserved.
+
+2. Introduction
+
+   This document describes a way to do IN-ADDR.ARPA delegation on non-
+   octet boundaries for address spaces covering fewer than 256
+   addresses.  The proposed method should thus remove one of the
+   objections to subnet on non-octet boundaries but perhaps more
+   significantly, make it possible to assign IP address space in smaller
+   chunks than 24-bit prefixes, without losing the ability to delegate
+   authority for the corresponding IN-ADDR.ARPA mappings.  The proposed
+   method is fully compatible with the original DNS lookup mechanisms
+   specified in [1], i.e. there is no need to modify the lookup
+   algorithm used, and there should be no need to modify any software
+   which does DNS lookups.
+
+   The document also discusses some operational considerations to
+   provide some guidance in implementing this method.
+
+3. Motivation
+
+   With the proliferation of classless routing technology, it has become
+   feasible to assign address space on non-octet boundaries.  In case of
+   a very small organization with only a few hosts, assigning a full
+   24-bit prefix (what was traditionally referred to as a "class C
+   network number") often leads to inefficient address space
+   utilization.
+
+
+
+
+
+Eidnes, et. al.          Best Current Practice                  [Page 1]
+
+RFC 2317           Classless IN-ADDR.ARPA delegation          March 1998
+
+
+   One of the problems encountered when assigning a longer prefix (less
+   address space) is that it seems impossible for such an organization
+   to maintain its own reverse ("IN-ADDR.ARPA") zone autonomously.  By
+   use of the reverse delegation method described below, the most
+   important objection to assignment of longer prefixes to unrelated
+   organizations can be removed.
+
+   Let us assume we have assigned the address spaces to three different
+   parties as follows:
+
+           192.0.2.0/25   to organization A
+           192.0.2.128/26 to organization B
+           192.0.2.192/26 to organization C
+
+   In the classical approach, this would lead to a single zone like
+   this:
+
+   $ORIGIN 2.0.192.in-addr.arpa.
+   ;
+   1               PTR     host1.A.domain.
+   2               PTR     host2.A.domain.
+   3               PTR     host3.A.domain.
+   ;
+   129             PTR     host1.B.domain.
+   130             PTR     host2.B.domain.
+   131             PTR     host3.B.domain.
+   ;
+   193             PTR     host1.C.domain.
+   194             PTR     host2.C.domain.
+   195             PTR     host3.C.domain.
+
+   The administration of this zone is problematic.  Authority for this
+   zone can only be delegated once, and this usually translates into
+   "this zone can only be administered by one organization."  The other
+   organizations with address space that corresponds to entries in this
+   zone would thus have to depend on another organization for their
+   address to name translation.  With the proposed method, this
+   potential problem can be avoided.
+
+4. Classless IN-ADDR.ARPA delegation
+
+   Since a single zone can only be delegated once, we need more points
+   to do delegation on to solve the problem above.  These extra points
+   of delegation can be introduced by extending the IN-ADDR.ARPA tree
+   downwards, e.g. by using the first address or the first address and
+   the network mask length (as shown below) in the corresponding address
+
+
+
+
+
+Eidnes, et. al.          Best Current Practice                  [Page 2]
+
+RFC 2317           Classless IN-ADDR.ARPA delegation          March 1998
+
+
+   space to form the the first component in the name for the zones.  The
+   following four zone files show how the problem in the motivation
+   section could be solved using this method.
+
+   $ORIGIN 2.0.192.in-addr.arpa.
+   @       IN      SOA     my-ns.my.domain. hostmaster.my.domain. (...)
+   ;...
+   ;  <<0-127>> /25
+   0/25            NS      ns.A.domain.
+   0/25            NS      some.other.name.server.
+   ;
+   1               CNAME   1.0/25.2.0.192.in-addr.arpa.
+   2               CNAME   2.0/25.2.0.192.in-addr.arpa.
+   3               CNAME   3.0/25.2.0.192.in-addr.arpa.
+   ;
+   ;  <<128-191>> /26
+   128/26          NS      ns.B.domain.
+   128/26          NS      some.other.name.server.too.
+   ;
+   129             CNAME   129.128/26.2.0.192.in-addr.arpa.
+   130             CNAME   130.128/26.2.0.192.in-addr.arpa.
+   131             CNAME   131.128/26.2.0.192.in-addr.arpa.
+   ;
+   ;  <<192-255>> /26
+   192/26          NS      ns.C.domain.
+   192/26          NS      some.other.third.name.server.
+   ;
+   193             CNAME   193.192/26.2.0.192.in-addr.arpa.
+   194             CNAME   194.192/26.2.0.192.in-addr.arpa.
+   195             CNAME   195.192/26.2.0.192.in-addr.arpa.
+
+   $ORIGIN 0/25.2.0.192.in-addr.arpa.
+   @       IN      SOA     ns.A.domain. hostmaster.A.domain. (...)
+   @               NS      ns.A.domain.
+   @               NS      some.other.name.server.
+   ;
+   1               PTR     host1.A.domain.
+   2               PTR     host2.A.domain.
+   3               PTR     host3.A.domain.
+
+
+
+
+
+
+
+
+
+
+
+
+Eidnes, et. al.          Best Current Practice                  [Page 3]
+
+RFC 2317           Classless IN-ADDR.ARPA delegation          March 1998
+
+
+   $ORIGIN 128/26.2.0.192.in-addr.arpa.
+   @       IN      SOA     ns.B.domain. hostmaster.B.domain. (...)
+   @               NS      ns.B.domain.
+   @               NS      some.other.name.server.too.
+   ;
+   129             PTR     host1.B.domain.
+   130             PTR     host2.B.domain.
+   131             PTR     host3.B.domain.
+
+
+   $ORIGIN 192/26.2.0.192.in-addr.arpa.
+   @       IN      SOA     ns.C.domain. hostmaster.C.domain. (...)
+   @               NS      ns.C.domain.
+   @               NS      some.other.third.name.server.
+   ;
+   193             PTR     host1.C.domain.
+   194             PTR     host2.C.domain.
+   195             PTR     host3.C.domain.
+
+   For each size-256 chunk split up using this method, there is a need
+   to install close to 256 CNAME records in the parent zone.  Some
+   people might view this as ugly; we will not argue that particular
+   point.  It is however quite easy to automatically generate the CNAME
+   resource records in the parent zone once and for all, if the way the
+   address space is partitioned is known.
+
+   The advantage of this approach over the other proposed approaches for
+   dealing with this problem is that there should be no need to modify
+   any already-deployed software.  In particular, the lookup mechanism
+   in the DNS does not have to be modified to accommodate this splitting
+   of the responsibility for the IPv4 address to name translation on
+   "non-dot" boundaries.  Furthermore, this technique has been in use
+   for several years in many installations, apparently with no ill
+   effects.
+
+   As usual, a resource record like
+
+   $ORIGIN 2.0.192.in-addr.arpa.
+   129             CNAME   129.128/26.2.0.192.in-addr.arpa.
+
+   can be convienently abbreviated to
+
+   $ORIGIN 2.0.192.in-addr.arpa.
+   129             CNAME   129.128/26
+
+
+
+
+
+
+
+Eidnes, et. al.          Best Current Practice                  [Page 4]
+
+RFC 2317           Classless IN-ADDR.ARPA delegation          March 1998
+
+
+   Some DNS implementations are not kind to special characters in domain
+   names, e.g. the "/" used in the above examples.  As [3] makes clear,
+   these are legal, though some might feel unsightly.  Because these are
+   not host names the restriction of [2] does not apply.  Modern clients
+   and servers have an option to act in the liberal and correct fashion.
+
+   The examples here use "/" because it was felt to be more visible and
+   pedantic reviewers felt that the 'these are not hostnames' argument
+   needed to be repeated.  We advise you not to be so pedantic, and to
+   not precisely copy the above examples, e.g.  substitute a more
+   conservative character, such as hyphen, for "/".
+
+5. Operational considerations
+
+   This technique is intended to be used for delegating address spaces
+   covering fewer than 256 addresses.  For delegations covering larger
+   blocks of addresses the traditional methods (multiple delegations)
+   can be used instead.
+
+5.1 Recommended secondary name service
+
+   Some older versions of name server software will make no effort to
+   find and return the pointed-to name in CNAME records if the pointed-
+   to name is not already known locally as cached or as authoritative
+   data.  This can cause some confusion in resolvers, as only the CNAME
+   record will be returned in the response.  To avoid this problem it is
+   recommended that the authoritative name servers for the delegating
+   zone (the zone containing all the CNAME records) all run as slave
+   (secondary) name servers for the "child" zones delegated and pointed
+   into via the CNAME records.
+
+5.2 Alternative naming conventions
+
+   As a result of this method, the location of the zone containing the
+   actual PTR records is no longer predefined.  This gives flexibility
+   and some examples will be presented here.
+
+   An alternative to using the first address, or the first address and
+   the network mask length in the corresponding address space, to name
+   the new zones is to use some other (non-numeric) name.  Thus it is
+   also possible to point to an entirely different part of the DNS tree
+   (i.e. outside of the IN-ADDR.ARPA tree).  It would be necessary to
+   use one of these alternate methods if two organizations somehow
+   shared the same physical subnet (and corresponding IP address space)
+   with no "neat" alignment of the addresses, but still wanted to
+   administrate their own IN-ADDR.ARPA mappings.
+
+
+
+
+
+Eidnes, et. al.          Best Current Practice                  [Page 5]
+
+RFC 2317           Classless IN-ADDR.ARPA delegation          March 1998
+
+
+   The following short example shows how you can point out of the IN-
+   ADDR.ARPA tree:
+
+   $ORIGIN 2.0.192.in-addr.arpa.
+   @       IN      SOA     my-ns.my.domain. hostmaster.my.domain. (...)
+   ; ...
+   1               CNAME   1.A.domain.
+   2               CNAME   2.A.domain.
+   ; ...
+   129             CNAME   129.B.domain.
+   130             CNAME   130.B.domain.
+   ;
+
+
+   $ORIGIN A.domain.
+   @       IN      SOA     my-ns.A.domain. hostmaster.A.domain. (...)
+   ; ...
+   ;
+   host1           A       192.0.2.1
+   1               PTR     host1
+   ;
+   host2           A       192.0.2.2
+   2               PTR     host2
+   ;
+
+   etc.
+
+   This way you can actually end up with the name->address and the
+   (pointed-to) address->name mapping data in the same zone file - some
+   may view this as an added bonus as no separate set of secondaries for
+   the reverse zone is required.  Do however note that the traversal via
+   the IN-ADDR.ARPA tree will still be done, so the CNAME records
+   inserted there need to point in the right direction for this to work.
+
+   Sketched below is an alternative approach using the same solution:
+
+   $ORIGIN 2.0.192.in-addr.arpa.
+   @                  SOA     my-ns.my.domain. hostmaster.my.domain. (...)
+   ; ...
+   1                  CNAME   1.2.0.192.in-addr.A.domain.
+   2                  CNAME   2.2.0.192.in-addr.A.domain.
+
+   $ORIGIN A.domain.
+   @                  SOA     my-ns.A.domain. hostmaster.A.domain. (...)
+   ; ...
+   ;
+   host1              A       192.0.2.1
+   1.2.0.192.in-addr  PTR     host1
+
+
+
+Eidnes, et. al.          Best Current Practice                  [Page 6]
+
+RFC 2317           Classless IN-ADDR.ARPA delegation          March 1998
+
+
+   host2              A       192.0.2.2
+   2.2.0.192.in-addr  PTR     host2
+
+   It is clear that many possibilities exist which can be adapted to the
+   specific requirements of the situation at hand.
+
+5.3 Other operational issues
+
+   Note that one cannot provide CNAME referrals twice for the same
+   address space, i.e. you cannot allocate a /25 prefix to one
+   organisation, and run IN-ADDR.ARPA this way, and then have the
+   organisation subnet the /25 into longer prefixes, and attempt to
+   employ the same technique to give each subnet control of its own
+   number space. This would result in a CNAME record pointing to a CNAME
+   record, which may be less robust overall.
+
+   Unfortunately, some old beta releases of the popular DNS name server
+   implementation BIND 4.9.3 had a bug which caused problems if a CNAME
+   record was encountered when a reverse lookup was made.  The beta
+   releases involved have since been obsoleted, and this issue is
+   resolved in the released code.  Some software manufacturers have
+   included the defective beta code in their product. In the few cases
+   we know of, patches from the manufacturers are available or planned
+   to replace the obsolete beta code involved.
+
+6. Security Considerations
+
+   With this scheme, the "leaf sites" will need to rely on one more site
+   running their DNS name service correctly than they would be if they
+   had a /24 allocation of their own, and this may add an extra
+   component which will need to work for reliable name resolution.
+
+   Other than that, the authors are not aware of any additional security
+   issues introduced by this mechanism.
+
+7. Conclusion
+
+   The suggested scheme gives more flexibility in delegating authority
+   in the IN-ADDR.ARPA domain, thus making it possible to assign address
+   space more efficiently without losing the ability to delegate the DNS
+   authority over the corresponding address to name mappings.
+
+8. Acknowledgments
+
+   Glen A. Herrmannsfeldt described this trick on comp.protocols.tcp-
+   ip.domains some time ago.  Alan Barrett and Sam Wilson provided
+   valuable comments on the newsgroup.
+
+
+
+
+Eidnes, et. al.          Best Current Practice                  [Page 7]
+
+RFC 2317           Classless IN-ADDR.ARPA delegation          March 1998
+
+
+   We would like to thank Rob Austein, Randy Bush, Matt Crawford, Robert
+   Elz, Glen A. Herrmannsfeldt, Daniel Karrenberg, David Kessens, Tony
+   Li, Paul Mockapetris, Eric Wassenaar, Michael Patton, Hans Maurer,
+   and Peter Koch for their review and constructive comments.
+
+9. References
+
+   [1]  Mockapetris, P., "Domain Names - Concepts and Facilities",
+        STD 13, RFC 1034, November 1987.
+
+   [2]  Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet Host
+        Table Specification", RFC 952, October 1985.
+
+   [3]  Elz, R., and R. Bush, "Clarifications to the DNS
+        Specification", RFC 2181, July 1997.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eidnes, et. al.          Best Current Practice                  [Page 8]
+
+RFC 2317           Classless IN-ADDR.ARPA delegation          March 1998
+
+
+10. Authors' Addresses
+
+   Havard Eidnes
+   SINTEF RUNIT
+   N-7034 Trondheim
+   Norway
+
+   Phone: +47 73 59 44 68
+   Fax: +47 73 59 17 00
+   EMail: Havard.Eidnes@runit.sintef.no
+
+
+   Geert Jan de Groot
+   Berkeley Software Design, Inc. (BSDI)
+   Hendrik Staetslaan 69
+   5622 HM Eindhoven
+   The Netherlands
+
+   Phone: +31 40 2960509
+   Fax:   +31 40 2960309
+   EMail: GeertJan.deGroot@bsdi.com
+
+
+   Paul Vixie
+   Internet Software Consortium
+   Star Route Box 159A
+   Woodside, CA 94062
+   USA
+
+   Phone: +1 415 747 0204
+   EMail: paul@vix.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eidnes, et. al.          Best Current Practice                  [Page 9]
+
+RFC 2317           Classless IN-ADDR.ARPA delegation          March 1998
+
+
+11.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (1998).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eidnes, et. al.          Best Current Practice                 [Page 10]
+
diff --git a/doc/rfc/rfc2373.txt b/doc/rfc/rfc2373.txt
new file mode 100644
index 0000000..59fcff8
--- /dev/null
+++ b/doc/rfc/rfc2373.txt
@@ -0,0 +1,1459 @@
+
+
+
+
+
+
+Network Working Group                                        R. Hinden
+Request for Comments: 2373                                       Nokia
+Obsoletes: 1884                                             S. Deering
+Category: Standards Track                                Cisco Systems
+							     July 1998
+
+                  IP Version 6 Addressing Architecture
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1998).  All Rights Reserved.
+
+Abstract
+
+   This specification defines the addressing architecture of the IP
+   Version 6 protocol [IPV6].  The document includes the IPv6 addressing
+   model, text representations of IPv6 addresses, definition of IPv6
+   unicast addresses, anycast addresses, and multicast addresses, and an
+   IPv6 node's required addresses.
+
+Table of Contents
+
+   1. Introduction.................................................2
+   2. IPv6 Addressing..............................................2
+      2.1 Addressing Model.........................................3
+      2.2 Text Representation of Addresses.........................3
+      2.3 Text Representation of Address Prefixes..................5
+      2.4 Address Type Representation..............................6
+      2.5 Unicast Addresses........................................7
+        2.5.1 Interface Identifiers................................8
+        2.5.2 The Unspecified Address..............................9
+        2.5.3 The Loopback Address.................................9
+        2.5.4 IPv6 Addresses with Embedded IPv4 Addresses.........10
+        2.5.5 NSAP Addresses......................................10
+        2.5.6 IPX Addresses.......................................10
+        2.5.7 Aggregatable Global Unicast Addresses...............11
+        2.5.8 Local-use IPv6 Unicast Addresses....................11
+      2.6 Anycast Addresses.......................................12
+        2.6.1 Required Anycast Address............................13
+      2.7 Multicast Addresses.....................................14
+
+
+
+Hinden & Deering            Standards Track                     [Page 1]
+
+RFC 2373              IPv6 Addressing Architecture             July 1998
+
+
+        2.7.1 Pre-Defined Multicast Addresses.....................15
+        2.7.2 Assignment of New IPv6 Multicast Addresses..........17
+      2.8 A Node's Required Addresses.............................17
+   3. Security Considerations.....................................18
+   APPENDIX A: Creating EUI-64 based Interface Identifiers........19
+   APPENDIX B: ABNF Description of Text Representations...........22
+   APPENDIX C: CHANGES FROM RFC-1884..............................23
+   REFERENCES.....................................................24
+   AUTHORS' ADDRESSES.............................................25
+   FULL COPYRIGHT STATEMENT.......................................26
+
+
+1.0 INTRODUCTION
+
+   This specification defines the addressing architecture of the IP
+   Version 6 protocol.  It includes a detailed description of the
+   currently defined address formats for IPv6 [IPV6].
+
+   The authors would like to acknowledge the contributions of Paul
+   Francis, Scott Bradner, Jim Bound, Brian Carpenter, Matt Crawford,
+   Deborah Estrin, Roger Fajman, Bob Fink, Peter Ford, Bob Gilligan,
+   Dimitry Haskin, Tom Harsch, Christian Huitema, Tony Li, Greg
+   Minshall, Thomas Narten, Erik Nordmark, Yakov Rekhter, Bill Simpson,
+   and Sue Thomson.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC 2119].
+
+2.0 IPv6 ADDRESSING
+
+   IPv6 addresses are 128-bit identifiers for interfaces and sets of
+   interfaces.  There are three types of addresses:
+
+     Unicast:   An identifier for a single interface.  A packet sent to
+                a unicast address is delivered to the interface
+                identified by that address.
+
+     Anycast:   An identifier for a set of interfaces (typically
+                belonging to different nodes).  A packet sent to an
+                anycast address is delivered to one of the interfaces
+                identified by that address (the "nearest" one, according
+                to the routing protocols' measure of distance).
+
+     Multicast: An identifier for a set of interfaces (typically
+                belonging to different nodes).  A packet sent to a
+                multicast address is delivered to all interfaces
+                identified by that address.
+
+
+
+Hinden & Deering            Standards Track                     [Page 2]
+
+RFC 2373              IPv6 Addressing Architecture             July 1998
+
+
+   There are no broadcast addresses in IPv6, their function being
+   superseded by multicast addresses.
+
+   In this document, fields in addresses are given a specific name, for
+   example "subscriber".  When this name is used with the term "ID" for
+   identifier after the name (e.g., "subscriber ID"), it refers to the
+   contents of the named field.  When it is used with the term "prefix"
+   (e.g.  "subscriber prefix") it refers to all of the address up to and
+   including this field.
+
+   In IPv6, all zeros and all ones are legal values for any field,
+   unless specifically excluded.  Specifically, prefixes may contain
+   zero-valued fields or end in zeros.
+
+2.1 Addressing Model
+
+   IPv6 addresses of all types are assigned to interfaces, not nodes.
+   An IPv6 unicast address refers to a single interface.  Since each
+   interface belongs to a single node, any of that node's interfaces'
+   unicast addresses may be used as an identifier for the node.
+
+   All interfaces are required to have at least one link-local unicast
+   address (see section 2.8 for additional required addresses).  A
+   single interface may also be assigned multiple IPv6 addresses of any
+   type (unicast, anycast, and multicast) or scope.  Unicast addresses
+   with scope greater than link-scope are not needed for interfaces that
+   are not used as the origin or destination of any IPv6 packets to or
+   from non-neighbors.  This is sometimes convenient for point-to-point
+   interfaces.  There is one exception to this addressing model:
+
+     An unicast address or a set of unicast addresses may be assigned to
+     multiple physical interfaces if the implementation treats the
+     multiple physical interfaces as one interface when presenting it to
+     the internet layer.  This is useful for load-sharing over multiple
+     physical interfaces.
+
+   Currently IPv6 continues the IPv4 model that a subnet prefix is
+   associated with one link.  Multiple subnet prefixes may be assigned
+   to the same link.
+
+2.2 Text Representation of Addresses
+
+   There are three conventional forms for representing IPv6 addresses as
+   text strings:
+
+   1. The preferred form is x:x:x:x:x:x:x:x, where the 'x's are the
+      hexadecimal values of the eight 16-bit pieces of the address.
+      Examples:
+
+
+
+Hinden & Deering            Standards Track                     [Page 3]
+
+RFC 2373              IPv6 Addressing Architecture             July 1998
+
+
+         FEDC:BA98:7654:3210:FEDC:BA98:7654:3210
+
+         1080:0:0:0:8:800:200C:417A
+
+      Note that it is not necessary to write the leading zeros in an
+      individual field, but there must be at least one numeral in every
+      field (except for the case described in 2.).
+
+   2. Due to some methods of allocating certain styles of IPv6
+      addresses, it will be common for addresses to contain long strings
+      of zero bits.  In order to make writing addresses containing zero
+      bits easier a special syntax is available to compress the zeros.
+      The use of "::" indicates multiple groups of 16-bits of zeros.
+      The "::" can only appear once in an address.  The "::" can also be
+      used to compress the leading and/or trailing zeros in an address.
+
+      For example the following addresses:
+
+         1080:0:0:0:8:800:200C:417A  a unicast address
+         FF01:0:0:0:0:0:0:101        a multicast address
+         0:0:0:0:0:0:0:1             the loopback address
+         0:0:0:0:0:0:0:0             the unspecified addresses
+
+      may be represented as:
+
+         1080::8:800:200C:417A       a unicast address
+         FF01::101                   a multicast address
+         ::1                         the loopback address
+         ::                          the unspecified addresses
+
+   3. An alternative form that is sometimes more convenient when dealing
+      with a mixed environment of IPv4 and IPv6 nodes is
+      x:x:x:x:x:x:d.d.d.d, where the 'x's are the hexadecimal values of
+      the six high-order 16-bit pieces of the address, and the 'd's are
+      the decimal values of the four low-order 8-bit pieces of the
+      address (standard IPv4 representation).  Examples:
+
+         0:0:0:0:0:0:13.1.68.3
+
+         0:0:0:0:0:FFFF:129.144.52.38
+
+      or in compressed form:
+
+         ::13.1.68.3
+
+         ::FFFF:129.144.52.38
+
+
+
+
+
+Hinden & Deering            Standards Track                     [Page 4]
+
+RFC 2373              IPv6 Addressing Architecture             July 1998
+
+
+2.3 Text Representation of Address Prefixes
+
+   The text representation of IPv6 address prefixes is similar to the
+   way IPv4 addresses prefixes are written in CIDR notation.  An IPv6
+   address prefix is represented by the notation:
+
+      ipv6-address/prefix-length
+
+   where
+
+      ipv6-address    is an IPv6 address in any of the notations listed
+                      in section 2.2.
+
+      prefix-length   is a decimal value specifying how many of the
+                      leftmost contiguous bits of the address comprise
+                      the prefix.
+
+   For example, the following are legal representations of the 60-bit
+   prefix 12AB00000000CD3 (hexadecimal):
+
+      12AB:0000:0000:CD30:0000:0000:0000:0000/60
+      12AB::CD30:0:0:0:0/60
+      12AB:0:0:CD30::/60
+
+   The following are NOT legal representations of the above prefix:
+
+      12AB:0:0:CD3/60   may drop leading zeros, but not trailing zeros,
+                        within any 16-bit chunk of the address
+
+      12AB::CD30/60     address to left of "/" expands to
+                        12AB:0000:0000:0000:0000:000:0000:CD30
+
+      12AB::CD3/60      address to left of "/" expands to
+                        12AB:0000:0000:0000:0000:000:0000:0CD3
+
+   When writing both a node address and a prefix of that node address
+   (e.g., the node's subnet prefix), the two can combined as follows:
+
+      the node address      12AB:0:0:CD30:123:4567:89AB:CDEF
+      and its subnet number 12AB:0:0:CD30::/60
+
+      can be abbreviated as 12AB:0:0:CD30:123:4567:89AB:CDEF/60
+
+
+
+
+
+
+
+
+
+Hinden & Deering            Standards Track                     [Page 5]
+
+RFC 2373              IPv6 Addressing Architecture             July 1998
+
+
+2.4 Address Type Representation
+
+   The specific type of an IPv6 address is indicated by the leading bits
+   in the address.  The variable-length field comprising these leading
+   bits is called the Format Prefix (FP).  The initial allocation of
+   these prefixes is as follows:
+
+    Allocation                            Prefix         Fraction of
+                                          (binary)       Address Space
+    -----------------------------------   --------       -------------
+    Reserved                              0000 0000      1/256
+    Unassigned                            0000 0001      1/256
+
+    Reserved for NSAP Allocation          0000 001       1/128
+    Reserved for IPX Allocation           0000 010       1/128
+
+    Unassigned                            0000 011       1/128
+    Unassigned                            0000 1         1/32
+    Unassigned                            0001           1/16
+
+    Aggregatable Global Unicast Addresses 001            1/8
+    Unassigned                            010            1/8
+    Unassigned                            011            1/8
+    Unassigned                            100            1/8
+    Unassigned                            101            1/8
+    Unassigned                            110            1/8
+
+    Unassigned                            1110           1/16
+    Unassigned                            1111 0         1/32
+    Unassigned                            1111 10        1/64
+    Unassigned                            1111 110       1/128
+    Unassigned                            1111 1110 0    1/512
+
+    Link-Local Unicast Addresses          1111 1110 10   1/1024
+    Site-Local Unicast Addresses          1111 1110 11   1/1024
+
+    Multicast Addresses                   1111 1111      1/256
+
+    Notes:
+
+      (1) The "unspecified address" (see section 2.5.2), the loopback
+          address (see section 2.5.3), and the IPv6 Addresses with
+          Embedded IPv4 Addresses (see section 2.5.4), are assigned out
+          of the 0000 0000 format prefix space.
+
+
+
+
+
+
+
+Hinden & Deering            Standards Track                     [Page 6]
+
+RFC 2373              IPv6 Addressing Architecture             July 1998
+
+
+      (2) The format prefixes 001 through 111, except for Multicast
+          Addresses (1111 1111), are all required to have to have 64-bit
+          interface identifiers in EUI-64 format.  See section 2.5.1 for
+          definitions.
+
+   This allocation supports the direct allocation of aggregation
+   addresses, local use addresses, and multicast addresses.  Space is
+   reserved for NSAP addresses and IPX addresses.  The remainder of the
+   address space is unassigned for future use.  This can be used for
+   expansion of existing use (e.g., additional aggregatable addresses,
+   etc.) or new uses (e.g., separate locators and identifiers).  Fifteen
+   percent of the address space is initially allocated.  The remaining
+   85% is reserved for future use.
+
+   Unicast addresses are distinguished from multicast addresses by the
+   value of the high-order octet of the addresses: a value of FF
+   (11111111) identifies an address as a multicast address; any other
+   value identifies an address as a unicast address.  Anycast addresses
+   are taken from the unicast address space, and are not syntactically
+   distinguishable from unicast addresses.
+
+2.5 Unicast Addresses
+
+   IPv6 unicast addresses are aggregatable with contiguous bit-wise
+   masks similar to IPv4 addresses under Class-less Interdomain Routing
+   [CIDR].
+
+   There are several forms of unicast address assignment in IPv6,
+   including the global aggregatable global unicast address, the NSAP
+   address, the IPX hierarchical address, the site-local address, the
+   link-local address, and the IPv4-capable host address.  Additional
+   address types can be defined in the future.
+
+   IPv6 nodes may have considerable or little knowledge of the internal
+   structure of the IPv6 address, depending on the role the node plays
+   (for instance, host versus router).  At a minimum, a node may
+   consider that unicast addresses (including its own) have no internal
+   structure:
+
+   |                           128 bits                              |
+   +-----------------------------------------------------------------+
+   |                          node address                           |
+   +-----------------------------------------------------------------+
+
+   A slightly sophisticated host (but still rather simple) may
+   additionally be aware of subnet prefix(es) for the link(s) it is
+   attached to, where different addresses may have different values for
+   n:
+
+
+
+Hinden & Deering            Standards Track                     [Page 7]
+
+RFC 2373              IPv6 Addressing Architecture             July 1998
+
+
+   |                         n bits                 |   128-n bits   |
+   +------------------------------------------------+----------------+
+   |                   subnet prefix                | interface ID   |
+   +------------------------------------------------+----------------+
+
+   Still more sophisticated hosts may be aware of other hierarchical
+   boundaries in the unicast address.  Though a very simple router may
+   have no knowledge of the internal structure of IPv6 unicast
+   addresses, routers will more generally have knowledge of one or more
+   of the hierarchical boundaries for the operation of routing
+   protocols.  The known boundaries will differ from router to router,
+   depending on what positions the router holds in the routing
+   hierarchy.
+
+2.5.1 Interface Identifiers
+
+   Interface identifiers in IPv6 unicast addresses are used to identify
+   interfaces on a link.  They are required to be unique on that link.
+   They may also be unique over a broader scope.  In many cases an
+   interface's identifier will be the same as that interface's link-
+   layer address.  The same interface identifier may be used on multiple
+   interfaces on a single node.
+
+   Note that the use of the same interface identifier on multiple
+   interfaces of a single node does not affect the interface
+   identifier's global uniqueness or each IPv6 addresses global
+   uniqueness created using that interface identifier.
+
+   In a number of the format prefixes (see section 2.4) Interface IDs
+   are required to be 64 bits long and to be constructed in IEEE EUI-64
+   format [EUI64].  EUI-64 based Interface identifiers may have global
+   scope when a global token is available (e.g., IEEE 48bit MAC) or may
+   have local scope where a global token is not available (e.g., serial
+   links, tunnel end-points, etc.).  It is required that the "u" bit
+   (universal/local bit in IEEE EUI-64 terminology) be inverted when
+   forming the interface identifier from the EUI-64.  The "u" bit is set
+   to one (1) to indicate global scope, and it is set to zero (0) to
+   indicate local scope.  The first three octets in binary of an EUI-64
+   identifier are as follows:
+
+       0       0 0       1 1       2
+      |0       7 8       5 6       3|
+      +----+----+----+----+----+----+
+      |cccc|ccug|cccc|cccc|cccc|cccc|
+      +----+----+----+----+----+----+
+
+
+
+
+
+
+Hinden & Deering            Standards Track                     [Page 8]
+
+RFC 2373              IPv6 Addressing Architecture             July 1998
+
+
+   written in Internet standard bit-order , where "u" is the
+   universal/local bit, "g" is the individual/group bit, and "c" are the
+   bits of the company_id.  Appendix A: "Creating EUI-64 based Interface
+   Identifiers" provides examples on the creation of different EUI-64
+   based interface identifiers.
+
+   The motivation for inverting the "u" bit when forming the interface
+   identifier is to make it easy for system administrators to hand
+   configure local scope identifiers when hardware tokens are not
+   available.  This is expected to be case for serial links, tunnel end-
+   points, etc.  The alternative would have been for these to be of the
+   form 0200:0:0:1, 0200:0:0:2, etc., instead of the much simpler ::1,
+   ::2, etc.
+
+   The use of the universal/local bit in the IEEE EUI-64 identifier is
+   to allow development of future technology that can take advantage of
+   interface identifiers with global scope.
+
+   The details of forming interface identifiers are defined in the
+   appropriate "IPv6 over <link>" specification such as "IPv6 over
+   Ethernet" [ETHER], "IPv6 over FDDI" [FDDI], etc.
+
+2.5.2 The Unspecified Address
+
+   The address 0:0:0:0:0:0:0:0 is called the unspecified address.  It
+   must never be assigned to any node.  It indicates the absence of an
+   address.  One example of its use is in the Source Address field of
+   any IPv6 packets sent by an initializing host before it has learned
+   its own address.
+
+   The unspecified address must not be used as the destination address
+   of IPv6 packets or in IPv6 Routing Headers.
+
+2.5.3 The Loopback Address
+
+   The unicast address 0:0:0:0:0:0:0:1 is called the loopback address.
+   It may be used by a node to send an IPv6 packet to itself.  It may
+   never be assigned to any physical interface.  It may be thought of as
+   being associated with a virtual interface (e.g., the loopback
+   interface).
+
+   The loopback address must not be used as the source address in IPv6
+   packets that are sent outside of a single node.  An IPv6 packet with
+   a destination address of loopback must never be sent outside of a
+   single node and must never be forwarded by an IPv6 router.
+
+
+
+
+
+
+Hinden & Deering            Standards Track                     [Page 9]
+
+RFC 2373              IPv6 Addressing Architecture             July 1998
+
+
+2.5.4 IPv6 Addresses with Embedded IPv4 Addresses
+
+   The IPv6 transition mechanisms [TRAN] include a technique for hosts
+   and routers to dynamically tunnel IPv6 packets over IPv4 routing
+   infrastructure.  IPv6 nodes that utilize this technique are assigned
+   special IPv6 unicast addresses that carry an IPv4 address in the low-
+   order 32-bits.  This type of address is termed an "IPv4-compatible
+   IPv6 address" and has the format:
+
+   |                80 bits               | 16 |      32 bits        |
+   +--------------------------------------+--------------------------+
+   |0000..............................0000|0000|    IPv4 address     |
+   +--------------------------------------+----+---------------------+
+
+   A second type of IPv6 address which holds an embedded IPv4 address is
+   also defined.  This address is used to represent the addresses of
+   IPv4-only nodes (those that *do not* support IPv6) as IPv6 addresses.
+   This type of address is termed an "IPv4-mapped IPv6 address" and has
+   the format:
+
+   |                80 bits               | 16 |      32 bits        |
+   +--------------------------------------+--------------------------+
+   |0000..............................0000|FFFF|    IPv4 address     |
+   +--------------------------------------+----+---------------------+
+
+2.5.5 NSAP Addresses
+
+   This mapping of NSAP address into IPv6 addresses is defined in
+   [NSAP].  This document recommends that network implementors who have
+   planned or deployed an OSI NSAP addressing plan, and who wish to
+   deploy or transition to IPv6, should redesign a native IPv6
+   addressing plan to meet their needs.  However, it also defines a set
+   of mechanisms for the support of OSI NSAP addressing in an IPv6
+   network.  These mechanisms are the ones that must be used if such
+   support is required.  This document also defines a mapping of IPv6
+   addresses within the OSI address format, should this be required.
+
+2.5.6 IPX Addresses
+
+   This mapping of IPX address into IPv6 addresses is as follows:
+
+   |   7   |                   121 bits                              |
+   +-------+---------------------------------------------------------+
+   |0000010|                 to be defined                           |
+   +-------+---------------------------------------------------------+
+
+   The draft definition, motivation, and usage are under study.
+
+
+
+
+Hinden & Deering            Standards Track                    [Page 10]
+
+RFC 2373              IPv6 Addressing Architecture             July 1998
+
+
+2.5.7 Aggregatable Global Unicast Addresses
+
+   The global aggregatable global unicast address is defined in [AGGR].
+   This address format is designed to support both the current provider
+   based aggregation and a new type of aggregation called exchanges.
+   The combination will allow efficient routing aggregation for both
+   sites which connect directly to providers and who connect to
+   exchanges.  Sites will have the choice to connect to either type of
+   aggregation point.
+
+   The IPv6 aggregatable global unicast address format is as follows:
+
+   | 3|  13 | 8 |   24   |   16   |          64 bits               |
+   +--+-----+---+--------+--------+--------------------------------+
+   |FP| TLA |RES|  NLA   |  SLA   |         Interface ID           |
+   |  | ID  |   |  ID    |  ID    |                                |
+   +--+-----+---+--------+--------+--------------------------------+
+
+   Where
+
+      001          Format Prefix (3 bit) for Aggregatable Global
+                   Unicast Addresses
+      TLA ID       Top-Level Aggregation Identifier
+      RES          Reserved for future use
+      NLA ID       Next-Level Aggregation Identifier
+      SLA ID       Site-Level Aggregation Identifier
+      INTERFACE ID Interface Identifier
+
+   The contents, field sizes, and assignment rules are defined in
+   [AGGR].
+
+2.5.8 Local-Use IPv6 Unicast Addresses
+
+   There are two types of local-use unicast addresses defined.  These
+   are Link-Local and Site-Local.  The Link-Local is for use on a single
+   link and the Site-Local is for use in a single site.  Link-Local
+   addresses have the following format:
+
+   |   10     |
+   |  bits    |        54 bits          |          64 bits           |
+   +----------+-------------------------+----------------------------+
+   |1111111010|           0             |       interface ID         |
+   +----------+-------------------------+----------------------------+
+
+   Link-Local addresses are designed to be used for addressing on a
+   single link for purposes such as auto-address configuration, neighbor
+   discovery, or when no routers are present.
+
+
+
+
+Hinden & Deering            Standards Track                    [Page 11]
+
+RFC 2373              IPv6 Addressing Architecture             July 1998
+
+
+   Routers must not forward any packets with link-local source or
+   destination addresses to other links.
+
+   Site-Local addresses have the following format:
+
+   |   10     |
+   |  bits    |   38 bits   |  16 bits  |         64 bits            |
+   +----------+-------------+-----------+----------------------------+
+   |1111111011|    0        | subnet ID |       interface ID         |
+   +----------+-------------+-----------+----------------------------+
+
+   Site-Local addresses are designed to be used for addressing inside of
+   a site without the need for a global prefix.
+
+   Routers must not forward any packets with site-local source or
+   destination addresses outside of the site.
+
+2.6 Anycast Addresses
+
+   An IPv6 anycast address is an address that is assigned to more than
+   one interface (typically belonging to different nodes), with the
+   property that a packet sent to an anycast address is routed to the
+   "nearest" interface having that address, according to the routing
+   protocols' measure of distance.
+
+   Anycast addresses are allocated from the unicast address space, using
+   any of the defined unicast address formats.  Thus, anycast addresses
+   are syntactically indistinguishable from unicast addresses.  When a
+   unicast address is assigned to more than one interface, thus turning
+   it into an anycast address, the nodes to which the address is
+   assigned must be explicitly configured to know that it is an anycast
+   address.
+
+   For any assigned anycast address, there is a longest address prefix P
+   that identifies the topological region in which all interfaces
+   belonging to that anycast address reside.  Within the region
+   identified by P, each member of the anycast set must be advertised as
+   a separate entry in the routing system (commonly referred to as a
+   "host route"); outside the region identified by P, the anycast
+   address may be aggregated into the routing advertisement for prefix
+   P.
+
+   Note that in, the worst case, the prefix P of an anycast set may be
+   the null prefix, i.e., the members of the set may have no topological
+   locality.  In that case, the anycast address must be advertised as a
+   separate routing entry throughout the entire internet, which presents
+
+
+
+
+
+Hinden & Deering            Standards Track                    [Page 12]
+
+RFC 2373              IPv6 Addressing Architecture             July 1998
+
+
+   a severe scaling limit on how many such "global" anycast sets may be
+   supported.  Therefore, it is expected that support for global anycast
+   sets may be unavailable or very restricted.
+
+   One expected use of anycast addresses is to identify the set of
+   routers belonging to an organization providing internet service.
+   Such addresses could be used as intermediate addresses in an IPv6
+   Routing header, to cause a packet to be delivered via a particular
+   aggregation or sequence of aggregations.  Some other possible uses
+   are to identify the set of routers attached to a particular subnet,
+   or the set of routers providing entry into a particular routing
+   domain.
+
+   There is little experience with widespread, arbitrary use of internet
+   anycast addresses, and some known complications and hazards when
+   using them in their full generality [ANYCST].  Until more experience
+   has been gained and solutions agreed upon for those problems, the
+   following restrictions are imposed on IPv6 anycast addresses:
+
+      o An anycast address must not be used as the source address of an
+        IPv6 packet.
+
+      o An anycast address must not be assigned to an IPv6 host, that
+        is, it may be assigned to an IPv6 router only.
+
+2.6.1 Required Anycast Address
+
+   The Subnet-Router anycast address is predefined.  Its format is as
+   follows:
+
+   |                         n bits                 |   128-n bits   |
+   +------------------------------------------------+----------------+
+   |                   subnet prefix                | 00000000000000 |
+   +------------------------------------------------+----------------+
+
+   The "subnet prefix" in an anycast address is the prefix which
+   identifies a specific link.  This anycast address is syntactically
+   the same as a unicast address for an interface on the link with the
+   interface identifier set to zero.
+
+   Packets sent to the Subnet-Router anycast address will be delivered
+   to one router on the subnet.  All routers are required to support the
+   Subnet-Router anycast addresses for the subnets which they have
+   interfaces.
+
+
+
+
+
+
+
+Hinden & Deering            Standards Track                    [Page 13]
+
+RFC 2373              IPv6 Addressing Architecture             July 1998
+
+
+   The subnet-router anycast address is intended to be used for
+   applications where a node needs to communicate with one of a set of
+   routers on a remote subnet.  For example when a mobile host needs to
+   communicate with one of the mobile agents on its "home" subnet.
+
+2.7 Multicast Addresses
+
+   An IPv6 multicast address is an identifier for a group of nodes.  A
+   node may belong to any number of multicast groups.  Multicast
+   addresses have the following format:
+
+   |   8    |  4 |  4 |                  112 bits                   |
+   +------ -+----+----+---------------------------------------------+
+   |11111111|flgs|scop|                  group ID                   |
+   +--------+----+----+---------------------------------------------+
+
+      11111111 at the start of the address identifies the address as
+      being a multicast address.
+
+                                    +-+-+-+-+
+      flgs is a set of 4 flags:     |0|0|0|T|
+                                    +-+-+-+-+
+
+         The high-order 3 flags are reserved, and must be initialized to
+         0.
+
+         T = 0 indicates a permanently-assigned ("well-known") multicast
+         address, assigned by the global internet numbering authority.
+
+         T = 1 indicates a non-permanently-assigned ("transient")
+         multicast address.
+
+      scop is a 4-bit multicast scope value used to limit the scope of
+      the multicast group.  The values are:
+
+         0  reserved
+         1  node-local scope
+         2  link-local scope
+         3  (unassigned)
+         4  (unassigned)
+         5  site-local scope
+         6  (unassigned)
+         7  (unassigned)
+         8  organization-local scope
+         9  (unassigned)
+         A  (unassigned)
+         B  (unassigned)
+         C  (unassigned)
+
+
+
+Hinden & Deering            Standards Track                    [Page 14]
+
+RFC 2373              IPv6 Addressing Architecture             July 1998
+
+
+         D  (unassigned)
+         E  global scope
+         F  reserved
+
+      group ID identifies the multicast group, either permanent or
+      transient, within the given scope.
+
+   The "meaning" of a permanently-assigned multicast address is
+   independent of the scope value.  For example, if the "NTP servers
+   group" is assigned a permanent multicast address with a group ID of
+   101 (hex), then:
+
+      FF01:0:0:0:0:0:0:101 means all NTP servers on the same node as the
+      sender.
+
+      FF02:0:0:0:0:0:0:101 means all NTP servers on the same link as the
+      sender.
+
+      FF05:0:0:0:0:0:0:101 means all NTP servers at the same site as the
+      sender.
+
+      FF0E:0:0:0:0:0:0:101 means all NTP servers in the internet.
+
+   Non-permanently-assigned multicast addresses are meaningful only
+   within a given scope.  For example, a group identified by the non-
+   permanent, site-local multicast address FF15:0:0:0:0:0:0:101 at one
+   site bears no relationship to a group using the same address at a
+   different site, nor to a non-permanent group using the same group ID
+   with different scope, nor to a permanent group with the same group
+   ID.
+
+   Multicast addresses must not be used as source addresses in IPv6
+   packets or appear in any routing header.
+
+2.7.1 Pre-Defined Multicast Addresses
+
+   The following well-known multicast addresses are pre-defined:
+
+      Reserved Multicast Addresses:   FF00:0:0:0:0:0:0:0
+                                      FF01:0:0:0:0:0:0:0
+                                      FF02:0:0:0:0:0:0:0
+                                      FF03:0:0:0:0:0:0:0
+                                      FF04:0:0:0:0:0:0:0
+                                      FF05:0:0:0:0:0:0:0
+                                      FF06:0:0:0:0:0:0:0
+                                      FF07:0:0:0:0:0:0:0
+                                      FF08:0:0:0:0:0:0:0
+                                      FF09:0:0:0:0:0:0:0
+
+
+
+Hinden & Deering            Standards Track                    [Page 15]
+
+RFC 2373              IPv6 Addressing Architecture             July 1998
+
+
+                                      FF0A:0:0:0:0:0:0:0
+                                      FF0B:0:0:0:0:0:0:0
+                                      FF0C:0:0:0:0:0:0:0
+                                      FF0D:0:0:0:0:0:0:0
+                                      FF0E:0:0:0:0:0:0:0
+                                      FF0F:0:0:0:0:0:0:0
+
+   The above multicast addresses are reserved and shall never be
+   assigned to any multicast group.
+
+      All Nodes Addresses:    FF01:0:0:0:0:0:0:1
+                              FF02:0:0:0:0:0:0:1
+
+   The above multicast addresses identify the group of all IPv6 nodes,
+   within scope 1 (node-local) or 2 (link-local).
+
+      All Routers Addresses:   FF01:0:0:0:0:0:0:2
+                               FF02:0:0:0:0:0:0:2
+                               FF05:0:0:0:0:0:0:2
+
+   The above multicast addresses identify the group of all IPv6 routers,
+   within scope 1 (node-local), 2 (link-local), or 5 (site-local).
+
+      Solicited-Node Address:  FF02:0:0:0:0:1:FFXX:XXXX
+
+   The above multicast address is computed as a function of a node's
+   unicast and anycast addresses.  The solicited-node multicast address
+   is formed by taking the low-order 24 bits of the address (unicast or
+   anycast) and appending those bits to the prefix
+   FF02:0:0:0:0:1:FF00::/104 resulting in a multicast address in the
+   range
+
+      FF02:0:0:0:0:1:FF00:0000
+
+   to
+
+      FF02:0:0:0:0:1:FFFF:FFFF
+
+   For example, the solicited node multicast address corresponding to
+   the IPv6 address 4037::01:800:200E:8C6C is FF02::1:FF0E:8C6C.  IPv6
+   addresses that differ only in the high-order bits, e.g. due to
+   multiple high-order prefixes associated with different aggregations,
+   will map to the same solicited-node address thereby reducing the
+   number of multicast addresses a node must join.
+
+   A node is required to compute and join the associated Solicited-Node
+   multicast addresses for every unicast and anycast address it is
+   assigned.
+
+
+
+Hinden & Deering            Standards Track                    [Page 16]
+
+RFC 2373              IPv6 Addressing Architecture             July 1998
+
+
+2.7.2 Assignment of New IPv6 Multicast Addresses
+
+   The current approach [ETHER] to map IPv6 multicast addresses into
+   IEEE 802 MAC addresses takes the low order 32 bits of the IPv6
+   multicast address and uses it to create a MAC address.  Note that
+   Token Ring networks are handled differently.  This is defined in
+   [TOKEN].  Group ID's less than or equal to 32 bits will generate
+   unique MAC addresses.  Due to this new IPv6 multicast addresses
+   should be assigned so that the group identifier is always in the low
+   order 32 bits as shown in the following:
+
+   |   8    |  4 |  4 |          80 bits          |     32 bits     |
+   +------ -+----+----+---------------------------+-----------------+
+   |11111111|flgs|scop|   reserved must be zero   |    group ID     |
+   +--------+----+----+---------------------------+-----------------+
+
+   While this limits the number of permanent IPv6 multicast groups to
+   2^32 this is unlikely to be a limitation in the future.  If it
+   becomes necessary to exceed this limit in the future multicast will
+   still work but the processing will be sightly slower.
+
+   Additional IPv6 multicast addresses are defined and registered by the
+   IANA [MASGN].
+
+2.8 A Node's Required Addresses
+
+   A host is required to recognize the following addresses as
+   identifying itself:
+
+      o Its Link-Local Address for each interface
+      o Assigned Unicast Addresses
+      o Loopback Address
+      o All-Nodes Multicast Addresses
+      o Solicited-Node Multicast Address for each of its assigned
+        unicast and anycast addresses
+      o Multicast Addresses of all other groups to which the host
+        belongs.
+
+   A router is required to recognize all addresses that a host is
+   required to recognize, plus the following addresses as identifying
+   itself:
+
+      o The Subnet-Router anycast addresses for the interfaces it is
+        configured to act as a router on.
+      o All other Anycast addresses with which the router has been
+        configured.
+      o All-Routers Multicast Addresses
+
+
+
+
+Hinden & Deering            Standards Track                    [Page 17]
+
+RFC 2373              IPv6 Addressing Architecture             July 1998
+
+
+      o Multicast Addresses of all other groups to which the router
+        belongs.
+
+   The only address prefixes which should be predefined in an
+   implementation are the:
+
+      o Unspecified Address
+      o Loopback Address
+      o Multicast Prefix (FF)
+      o Local-Use Prefixes (Link-Local and Site-Local)
+      o Pre-Defined Multicast Addresses
+      o IPv4-Compatible Prefixes
+
+   Implementations should assume all other addresses are unicast unless
+   specifically configured (e.g., anycast addresses).
+
+3. Security Considerations
+
+   IPv6 addressing documents do not have any direct impact on Internet
+   infrastructure security.  Authentication of IPv6 packets is defined
+   in [AUTH].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hinden & Deering            Standards Track                    [Page 18]
+
+RFC 2373              IPv6 Addressing Architecture             July 1998
+
+
+APPENDIX A : Creating EUI-64 based Interface Identifiers
+--------------------------------------------------------
+
+   Depending on the characteristics of a specific link or node there are
+   a number of approaches for creating EUI-64 based interface
+   identifiers.  This appendix describes some of these approaches.
+
+Links or Nodes with EUI-64 Identifiers
+
+   The only change needed to transform an EUI-64 identifier to an
+   interface identifier is to invert the "u" (universal/local) bit.  For
+   example, a globally unique EUI-64 identifier of the form:
+
+   |0              1|1              3|3              4|4              6|
+   |0              5|6              1|2              7|8              3|
+   +----------------+----------------+----------------+----------------+
+   |cccccc0gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|mmmmmmmmmmmmmmmm|
+   +----------------+----------------+----------------+----------------+
+
+   where "c" are the bits of the assigned company_id, "0" is the value
+   of the universal/local bit to indicate global scope, "g" is
+   individual/group bit, and "m" are the bits of the manufacturer-
+   selected extension identifier.  The IPv6 interface identifier would
+   be of the form:
+
+   |0              1|1              3|3              4|4              6|
+   |0              5|6              1|2              7|8              3|
+   +----------------+----------------+----------------+----------------+
+   |cccccc1gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|mmmmmmmmmmmmmmmm|
+   +----------------+----------------+----------------+----------------+
+
+   The only change is inverting the value of the universal/local bit.
+
+Links or Nodes with IEEE 802 48 bit MAC's
+
+   [EUI64] defines a method to create a EUI-64 identifier from an IEEE
+   48bit MAC identifier.  This is to insert two octets, with hexadecimal
+   values of 0xFF and 0xFE, in the middle of the 48 bit MAC (between the
+   company_id and vendor supplied id).  For example the 48 bit MAC with
+   global scope:
+
+   |0              1|1              3|3              4|
+   |0              5|6              1|2              7|
+   +----------------+----------------+----------------+
+   |cccccc0gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|
+   +----------------+----------------+----------------+
+
+
+
+
+
+Hinden & Deering            Standards Track                    [Page 19]
+
+RFC 2373              IPv6 Addressing Architecture             July 1998
+
+
+   where "c" are the bits of the assigned company_id, "0" is the value
+   of the universal/local bit to indicate global scope, "g" is
+   individual/group bit, and "m" are the bits of the manufacturer-
+   selected extension identifier.  The interface identifier would be of
+   the form:
+
+   |0              1|1              3|3              4|4              6|
+   |0              5|6              1|2              7|8              3|
+   +----------------+----------------+----------------+----------------+
+   |cccccc1gcccccccc|cccccccc11111111|11111110mmmmmmmm|mmmmmmmmmmmmmmmm|
+   +----------------+----------------+----------------+----------------+
+
+   When IEEE 802 48bit MAC addresses are available (on an interface or a
+   node), an implementation should use them to create interface
+   identifiers due to their availability and uniqueness properties.
+
+Links with Non-Global Identifiers
+
+   There are a number of types of links that, while multi-access, do not
+   have globally unique link identifiers.  Examples include LocalTalk
+   and Arcnet.  The method to create an EUI-64 formatted identifier is
+   to take the link identifier (e.g., the LocalTalk 8 bit node
+   identifier) and zero fill it to the left.  For example a LocalTalk 8
+   bit node identifier of hexadecimal value 0x4F results in the
+   following interface identifier:
+
+   |0              1|1              3|3              4|4              6|
+   |0              5|6              1|2              7|8              3|
+   +----------------+----------------+----------------+----------------+
+   |0000000000000000|0000000000000000|0000000000000000|0000000001001111|
+   +----------------+----------------+----------------+----------------+
+
+   Note that this results in the universal/local bit set to "0" to
+   indicate local scope.
+
+Links without Identifiers
+
+   There are a number of links that do not have any type of built-in
+   identifier.  The most common of these are serial links and configured
+   tunnels.  Interface identifiers must be chosen that are unique for
+   the link.
+
+   When no built-in identifier is available on a link the preferred
+   approach is to use a global interface identifier from another
+   interface or one which is assigned to the node itself.  To use this
+   approach no other interface connecting the same node to the same link
+   may use the same identifier.
+
+
+
+
+Hinden & Deering            Standards Track                    [Page 20]
+
+RFC 2373              IPv6 Addressing Architecture             July 1998
+
+
+   If there is no global interface identifier available for use on the
+   link the implementation needs to create a local scope interface
+   identifier.  The only requirement is that it be unique on the link.
+   There are many possible approaches to select a link-unique interface
+   identifier.  They include:
+
+      Manual Configuration
+      Generated Random Number
+      Node Serial Number (or other node-specific token)
+
+   The link-unique interface identifier should be generated in a manner
+   that it does not change after a reboot of a node or if interfaces are
+   added or deleted from the node.
+
+   The selection of the appropriate algorithm is link and implementation
+   dependent.  The details on forming interface identifiers are defined
+   in the appropriate "IPv6 over <link>" specification.  It is strongly
+   recommended that a collision detection algorithm be implemented as
+   part of any automatic algorithm.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hinden & Deering            Standards Track                    [Page 21]
+
+RFC 2373              IPv6 Addressing Architecture             July 1998
+
+
+APPENDIX B: ABNF Description of Text Representations
+----------------------------------------------------
+
+   This appendix defines the text representation of IPv6 addresses and
+   prefixes in Augmented BNF [ABNF] for reference purposes.
+
+      IPv6address = hexpart [ ":" IPv4address ]
+      IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT
+
+      IPv6prefix  = hexpart "/" 1*2DIGIT
+
+      hexpart = hexseq | hexseq "::" [ hexseq ] | "::" [ hexseq ]
+      hexseq  = hex4 *( ":" hex4)
+      hex4    = 1*4HEXDIG
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hinden & Deering            Standards Track                    [Page 22]
+
+RFC 2373              IPv6 Addressing Architecture             July 1998
+
+
+APPENDIX C: CHANGES FROM RFC-1884
+---------------------------------
+
+   The following changes were made from RFC-1884 "IP Version 6
+   Addressing Architecture":
+
+      - Added an appendix providing a ABNF description of text
+        representations.
+      - Clarification that link unique identifiers not change after
+        reboot or other interface reconfigurations.
+      - Clarification of Address Model based on comments.
+      - Changed aggregation format terminology to be consistent with
+        aggregation draft.
+      - Added text to allow interface identifier to be used on more than
+        one interface on same node.
+      - Added rules for defining new multicast addresses.
+      - Added appendix describing procedures for creating EUI-64 based
+        interface ID's.
+      - Added notation for defining IPv6 prefixes.
+      - Changed solicited node multicast definition to use a longer
+        prefix.
+      - Added site scope all routers multicast address.
+      - Defined Aggregatable Global Unicast Addresses to use "001" Format
+        Prefix.
+      - Changed "010" (Provider-Based Unicast) and "100" (Reserved for
+        Geographic) Format Prefixes to Unassigned.
+      - Added section on Interface ID definition for unicast addresses.
+        Requires use of EUI-64 in range of format prefixes and rules for
+        setting global/local scope bit in EUI-64.
+      - Updated NSAP text to reflect working in RFC1888.
+      - Removed protocol specific IPv6 multicast addresses (e.g., DHCP)
+        and referenced the IANA definitions.
+      - Removed section "Unicast Address Example".  Had become OBE.
+      - Added new and updated references.
+      - Minor text clarifications and improvements.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hinden & Deering            Standards Track                    [Page 23]
+
+RFC 2373              IPv6 Addressing Architecture             July 1998
+
+
+REFERENCES
+
+   [ABNF]    Crocker, D., and P. Overell, "Augmented BNF for
+             Syntax Specifications: ABNF", RFC 2234, November 1997.
+
+   [AGGR]    Hinden, R., O'Dell, M., and S. Deering, "An
+             Aggregatable Global Unicast Address Format", RFC 2374, July
+             1998.
+
+   [AUTH]    Atkinson, R., "IP Authentication Header", RFC 1826, August
+             1995.
+
+   [ANYCST]  Partridge, C., Mendez, T., and W. Milliken, "Host
+             Anycasting Service", RFC 1546, November 1993.
+
+   [CIDR]    Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless
+             Inter-Domain Routing (CIDR): An Address Assignment and
+             Aggregation Strategy", RFC 1519, September 1993.
+
+   [ETHER]   Crawford, M., "Transmission of IPv6 Pacekts over Ethernet
+             Networks", Work in Progress.
+
+   [EUI64]   IEEE, "Guidelines for 64-bit Global Identifier (EUI-64)
+             Registration Authority",
+             http://standards.ieee.org/db/oui/tutorials/EUI64.html,
+             March 1997.
+
+   [FDDI]    Crawford, M., "Transmission of IPv6 Packets over FDDI
+             Networks", Work in Progress.
+
+   [IPV6]    Deering, S., and R. Hinden, Editors, "Internet Protocol,
+             Version 6 (IPv6) Specification", RFC 1883, December 1995.
+
+   [MASGN]   Hinden, R., and S. Deering, "IPv6 Multicast Address
+             Assignments", RFC 2375, July 1998.
+
+   [NSAP]    Bound, J., Carpenter, B., Harrington, D., Houldsworth, J.,
+             and A. Lloyd, "OSI NSAPs and IPv6", RFC 1888, August 1996.
+
+   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+             Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [TOKEN]   Thomas, S., "Transmission of IPv6 Packets over Token Ring
+             Networks", Work in Progress.
+
+   [TRAN]    Gilligan, R., and E. Nordmark, "Transition Mechanisms for
+             IPv6 Hosts and Routers", RFC 1993, April 1996.
+
+
+
+
+Hinden & Deering            Standards Track                    [Page 24]
+
+RFC 2373              IPv6 Addressing Architecture             July 1998
+
+
+AUTHORS' ADDRESSES
+
+   Robert M. Hinden
+   Nokia
+   232 Java Drive
+   Sunnyvale, CA 94089
+   USA
+
+   Phone: +1 408 990-2004
+   Fax:   +1 408 743-5677
+   EMail: hinden@iprg.nokia.com
+
+
+   Stephen E. Deering
+   Cisco Systems, Inc.
+   170 West Tasman Drive
+   San Jose, CA 95134-1706
+   USA
+
+   Phone: +1 408 527-8213
+   Fax:   +1 408 527-8254
+   EMail: deering@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hinden & Deering            Standards Track                    [Page 25]
+
+RFC 2373              IPv6 Addressing Architecture             July 1998
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (1998).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hinden & Deering            Standards Track                    [Page 26]
+
diff --git a/doc/rfc/rfc2374.txt b/doc/rfc/rfc2374.txt
new file mode 100644
index 0000000..e3c7f0d
--- /dev/null
+++ b/doc/rfc/rfc2374.txt
@@ -0,0 +1,675 @@
+
+
+
+
+
+
+Network Working Group                                        R. Hinden
+Request for Comments: 2374                                       Nokia
+Obsoletes: 2073                                              M. O'Dell
+Category: Standards Track                                        UUNET
+                                                            S. Deering
+                                                                 Cisco
+                                                             July 1998
+
+
+           An IPv6 Aggregatable Global Unicast Address Format
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1998).  All Rights Reserved.
+
+1.0 Introduction
+
+   This document defines an IPv6 aggregatable global unicast address
+   format for use in the Internet.  The address format defined in this
+   document is consistent with the IPv6 Protocol [IPV6] and the "IPv6
+   Addressing Architecture" [ARCH].  It is designed to facilitate
+   scalable Internet routing.
+
+   This documented replaces RFC 2073, "An IPv6 Provider-Based Unicast
+   Address Format".  RFC 2073 will become historic.  The Aggregatable
+   Global Unicast Address Format is an improvement over RFC 2073 in a
+   number of areas.  The major changes include removal of the registry
+   bits because they are not needed for route aggregation, support of
+   EUI-64 based interface identifiers, support of provider and exchange
+   based aggregation, separation of public and site topology, and new
+   aggregation based terminology.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC 2119].
+
+
+
+
+
+
+
+
+Hinden, et. al.             Standards Track                     [Page 1]
+
+RFC 2374           IPv6 Global Unicast Address Format          July 1998
+
+
+2.0 Overview of the IPv6 Address
+
+   IPv6 addresses are 128-bit identifiers for interfaces and sets of
+   interfaces.  There are three types of addresses: Unicast, Anycast,
+   and Multicast.  This document defines a specific type of Unicast
+   address.
+
+   In this document, fields in addresses are given specific names, for
+   example "subnet".  When this name is used with the term "ID" (for
+   "identifier") after the name (e.g., "subnet ID"), it refers to the
+   contents of the named field.  When it is used with the term "prefix"
+   (e.g.  "subnet prefix") it refers to all of the addressing bits to
+   the left of and including this field.
+
+   IPv6 unicast addresses are designed assuming that the Internet
+   routing system makes forwarding decisions based on a "longest prefix
+   match" algorithm on arbitrary bit boundaries and does not have any
+   knowledge of the internal structure of IPv6 addresses.  The structure
+   in IPv6 addresses is for assignment and allocation.  The only
+   exception to this is the distinction made between unicast and
+   multicast addresses.
+
+   The specific type of an IPv6 address is indicated by the leading bits
+   in the address.  The variable-length field comprising these leading
+   bits is called the Format Prefix (FP).
+
+   This document defines an address format for the 001 (binary) Format
+   Prefix for Aggregatable Global Unicast addresses. The same address
+   format could be used for other Format Prefixes, as long as these
+   Format Prefixes also identify IPv6 unicast addresses.  Only the "001"
+   Format Prefix is defined here.
+
+3.0 IPv6 Aggregatable Global Unicast Address Format
+
+   This document defines an address format for the IPv6 aggregatable
+   global unicast address assignment.  The authors believe that this
+   address format will be widely used for IPv6 nodes connected to the
+   Internet.  This address format is designed to support both the
+   current provider-based aggregation and a new type of exchange-based
+   aggregation.  The combination will allow efficient routing
+   aggregation for sites that connect directly to providers and for
+   sites that connect to exchanges.  Sites will have the choice to
+   connect to either type of aggregation entity.
+
+
+
+
+
+
+
+
+Hinden, et. al.             Standards Track                     [Page 2]
+
+RFC 2374           IPv6 Global Unicast Address Format          July 1998
+
+
+   While this address format is designed to support exchange-based
+   aggregation (in addition to current provider-based aggregation) it is
+   not dependent on exchanges for it's overall route aggregation
+   properties.  It will provide efficient route aggregation with only
+   provider-based aggregation.
+
+   Aggregatable addresses are organized into a three level hierarchy:
+
+      - Public Topology
+      - Site Topology
+      - Interface Identifier
+
+   Public topology is the collection of providers and exchanges who
+   provide public Internet transit services.  Site topology is local to
+   a specific site or organization which does not provide public transit
+   service to nodes outside of the site.  Interface identifiers identify
+   interfaces on links.
+
+        ______________                  ______________
+    --+/              \+--------------+/              \+----------
+      (       P1       )    +----+    (       P3       )  +----+
+      +\______________/     |    |----+\______________/+--|    |--
+      |                  +--| X1 |                       +| X2 |
+      | ______________  /   |    |-+    ______________  / |    |--
+      +/              \+    +-+--+  \  /              \+  +----+
+      (       P2       )     / \     +(      P4        )
+    --+\______________/     /   \      \______________/
+           |               /     \           |      |
+           |              /       |          |      |
+           |             /        |          |      |
+          _|_          _/_       _|_        _|_    _|_
+         /   \        /   \     /   \      /   \  /   \
+        ( S.A )      ( S.B )   ( P5  )    ( P6  )( S.C )
+         \___/        \___/     \___/      \___/  \___/
+                                  |          / \
+                                 _|_       _/_  \   ___
+                                /   \     /   \  +-/   \
+                               ( S.D )   ( S.E )  ( S.F )
+                                \___/     \___/    \___/
+
+   As shown in the figure above, the aggregatable address format is
+   designed to support long-haul providers (shown as P1, P2, P3, and
+   P4), exchanges (shown as X1 and X2), multiple levels of providers
+   (shown at P5 and P6), and subscribers (shown as S.x) Exchanges
+   (unlike current NAPs, FIXes, etc.) will allocate IPv6 addresses.
+   Organizations who connect to these exchanges will also subscribe
+   (directly, indirectly via the exchange, etc.) for long-haul service
+   from one or more long-haul providers.  Doing so, they will achieve
+
+
+
+Hinden, et. al.             Standards Track                     [Page 3]
+
+RFC 2374           IPv6 Global Unicast Address Format          July 1998
+
+
+   addressing independence from long-haul transit providers.  They will
+   be able to change long-haul providers without having to renumber
+   their organization.  They can also be multihomed via the exchange to
+   more than one long-haul provider without having to have address
+   prefixes from each long-haul provider.  Note that the mechanisms used
+   for this type of provider selection and portability are not discussed
+   in the document.
+
+3.1 Aggregatable Global Unicast Address Structure
+
+   The aggregatable global unicast address format is as follows:
+
+     | 3|  13 | 8 |   24   |   16   |          64 bits               |
+     +--+-----+---+--------+--------+--------------------------------+
+     |FP| TLA |RES|  NLA   |  SLA   |         Interface ID           |
+     |  | ID  |   |  ID    |  ID    |                                |
+     +--+-----+---+--------+--------+--------------------------------+
+
+     <--Public Topology--->   Site
+                           <-------->
+                            Topology
+                                     <------Interface Identifier----->
+
+   Where
+
+      FP           Format Prefix (001)
+      TLA ID       Top-Level Aggregation Identifier
+      RES          Reserved for future use
+      NLA ID       Next-Level Aggregation Identifier
+      SLA ID       Site-Level Aggregation Identifier
+      INTERFACE ID Interface Identifier
+
+   The following sections specify each part of the IPv6 Aggregatable
+   Global Unicast address format.
+
+3.2 Top-Level Aggregation ID
+
+   Top-Level Aggregation Identifiers (TLA ID) are the top level in the
+   routing hierarchy.  Default-free routers must have a routing table
+   entry for every active TLA ID and will probably have additional
+   entries providing routing information for the TLA ID in which they
+   are located.  They may have additional entries in order to optimize
+   routing for their specific topology, but the routing topology at all
+   levels must be designed to minimize the number of additional entries
+   fed into the default free routing tables.
+
+
+
+
+
+
+Hinden, et. al.             Standards Track                     [Page 4]
+
+RFC 2374           IPv6 Global Unicast Address Format          July 1998
+
+
+   This addressing format supports 8,192 (2^13) TLA ID's.  Additional
+   TLA ID's may be added by either growing the TLA field to the right
+   into the reserved field or by using this format for additional format
+   prefixes.
+
+   The issues relating to TLA ID assignment are beyond the scope of this
+   document.  They will be described in a document under preparation.
+
+3.3 Reserved
+
+   The Reserved field is reserved for future use and must be set to
+   zero.
+
+   The Reserved field allows for future growth of the TLA and NLA fields
+   as appropriate.  See section 4.0 for a discussion.
+
+3.4 Next-Level Aggregation Identifier
+
+   Next-Level Aggregation Identifier's are used by organizations
+   assigned a TLA ID to create an addressing hierarchy and to identify
+   sites.  The organization can assign the top part of the NLA ID in a
+   manner to create an addressing hierarchy appropriate to its network.
+   It can use the remainder of the bits in the field to identify sites
+   it wishes to serve.  This is shown as follows:
+
+      |  n  |      24-n bits     |   16   |    64 bits      |
+      +-----+--------------------+--------+-----------------+
+      |NLA1 |      Site ID       | SLA ID | Interface ID    |
+      +-----+--------------------+--------+-----------------+
+
+   Each organization assigned a TLA ID receives 24 bits of NLA ID space.
+   This NLA ID space allows each organization to provide service to
+   approximately as many organizations as the current IPv4 Internet can
+   support total networks.
+
+   Organizations assigned TLA ID's may also support NLA ID's in their
+   own Site ID space.  This allows the organization assigned a TLA ID to
+   provide service to organizations providing public transit service and
+   to organizations who do not provide public transit service.  These
+   organizations receiving an NLA ID may also choose to use their Site
+   ID space to support other NLA ID's.  This is shown as follows:
+
+
+
+
+
+
+
+
+
+
+Hinden, et. al.             Standards Track                     [Page 5]
+
+RFC 2374           IPv6 Global Unicast Address Format          July 1998
+
+
+   |  n  |      24-n bits     |   16   |    64 bits      |
+   +-----+--------------------+--------+-----------------+
+   |NLA1 |      Site ID       | SLA ID | Interface ID    |
+   +-----+--------------------+--------+-----------------+
+
+         |  m  |    24-n-m    |   16   |    64 bits      |
+         +-----+--------------+--------+-----------------+
+         |NLA2 |   Site ID    | SLA ID | Interface ID    |
+         +-----+--------------+--------+-----------------+
+
+               |  o  |24-n-m-o|   16   |    64 bits      |
+               +-----+--------+--------+-----------------+
+               |NLA3 | Site ID| SLA ID | Interface ID    |
+               +-----+--------+--------+-----------------+
+
+   The design of the bit layout of the NLA ID space for a specific TLA
+   ID is left to the organization responsible for that TLA ID.  Likewise
+   the design of the bit layout of the next level NLA ID is the
+   responsibility of the previous level NLA ID.  It is recommended that
+   organizations assigning NLA address space use "slow start" allocation
+   procedures similar to [RFC2050].
+
+   The design of an NLA ID allocation plan is a tradeoff between routing
+   aggregation efficiency and flexibility.  Creating hierarchies allows
+   for greater amount of aggregation and results in smaller routing
+   tables.  Flat NLA ID assignment provides for easier allocation and
+   attachment flexibility, but results in larger routing tables.
+
+3.5 Site-Level Aggregation Identifier
+
+   The SLA ID field is used by an individual organization to create its
+   own local addressing hierarchy and to identify subnets.  This is
+   analogous to subnets in IPv4 except that each organization has a much
+   greater number of subnets.  The 16 bit SLA ID field support 65,535
+   individual subnets.
+
+   Organizations may choose to either route their SLA ID "flat" (e.g.,
+   not create any logical relationship between the SLA identifiers that
+   results in larger routing tables), or to create a two or more level
+   hierarchy (that results in smaller routing tables) in the SLA ID
+   field.  The latter is shown as follows:
+
+
+
+
+
+
+
+
+
+
+Hinden, et. al.             Standards Track                     [Page 6]
+
+RFC 2374           IPv6 Global Unicast Address Format          July 1998
+
+
+   |  n  |   16-n     |              64 bits                |
+   +-----+------------+-------------------------------------+
+   |SLA1 |   Subnet   |            Interface ID             |
+   +-----+------------+-------------------------------------+
+
+         | m  |16-n-m |              64 bits                |
+         +----+-------+-------------------------------------+
+         |SLA2|Subnet |            Interface ID             |
+         +----+-------+-------------------------------------+
+
+   The approach chosen for structuring an SLA ID field is the
+   responsibility of the individual organization.
+
+   The number of subnets supported in this address format should be
+   sufficient for all but the largest of organizations.  Organizations
+   which need additional subnets can arrange with the organization they
+   are obtaining Internet service from to obtain additional site
+   identifiers and use this to create additional subnets.
+
+3.6 Interface ID
+
+   Interface identifiers are used to identify interfaces on a link.
+   They are required to be unique on that link.  They may also be unique
+   over a broader scope.  In many cases an interfaces identifier will be
+   the same or be based on the interface's link-layer address.
+   Interface IDs used in the aggregatable global unicast address format
+   are required to be 64 bits long and to be constructed in IEEE EUI-64
+   format [EUI-64].  These identifiers may have global scope when a
+   global token (e.g., IEEE 48bit MAC) is available or may have local
+   scope where a global token is not available (e.g., serial links,
+   tunnel end-points, etc.).  The "u" bit (universal/local bit in IEEE
+   EUI-64 terminology) in the EUI-64 identifier must be set correctly,
+   as defined in [ARCH], to indicate global or local scope.
+
+   The procedures for creating EUI-64 based Interface Identifiers is
+   defined in [ARCH].  The details on forming interface identifiers is
+   defined in the appropriate "IPv6 over <link>" specification such as
+   "IPv6 over Ethernet" [ETHER], "IPv6 over FDDI" [FDDI], etc.
+
+4.0 Technical Motivation
+
+   The design choices for the size of the fields in the aggregatable
+   address format were based on the need to meet a number of technical
+   requirements.  These are described in the following paragraphs.
+
+   The size of the Top-Level Aggregation Identifier is 13 bits.  This
+   allows for 8,192 TLA ID's.  This size was chosen to insure that the
+   default-free routing table in top level routers in the Internet is
+
+
+
+Hinden, et. al.             Standards Track                     [Page 7]
+
+RFC 2374           IPv6 Global Unicast Address Format          July 1998
+
+
+   kept within the limits, with a reasonable margin, of the current
+   routing technology.  The margin is important because default-free
+   routers will also carry a significant number of longer (i.e., more-
+   specific) prefixes for optimizing paths internal to a TLA and between
+   TLAs.
+
+   The important issue is not only the size of the default-free routing
+   table, but the complexity of the topology that determines the number
+   of copies of the default-free routes that a router must examine while
+   computing a forwarding table.  Current practice with IPv4 it is
+   common to see a prefix announced fifteen times via different paths.
+
+   The complexity of Internet topology is very likely to increase in the
+   future.  It is important that IPv6 default-free routing support
+   additional complexity as well as a considerably larger internet.
+
+   It should be noted for comparison that at the time of this writing
+   (spring, 1998) the IPv4 default-free routing table contains
+   approximately 50,000 prefixes.  While this shows that it is possible
+   to support more routes than 8,192 it is matter of debate if the
+   number of prefixes supported today in IPv4 is already too high for
+   current routing technology.  There are serious issues of route
+   stability as well as cases of providers not supporting all top level
+   prefixes.  The technical requirement was to pick a TLA ID size that
+   was below, with a reasonable margin, what was being done with IPv4.
+
+   The choice of 13 bits for the TLA field was an engineering
+   compromise.  Fewer bits would have been too small by not supporting
+   enough top level organizations.  More bits would have exceeded what
+   can be reasonably accommodated, with a reasonable margin, with
+   current routing technology in order to deal with the issues described
+   in the previous paragraphs.
+
+   If in the future, routing technology improves to support a larger
+   number of top level routes in the default-free routing tables there
+   are two choices on how to increase the number TLA identifiers.  The
+   first is to expand the TLA ID field into the reserved field.  This
+   would increase the number of TLA ID's to approximately 2 million.
+   The second approach is to allocate another format prefix (FP) for use
+   with this address format.  Either or a combination of these
+   approaches allows the number of TLA ID's to increase significantly.
+
+   The size of the Reserved field is 8 bits.  This size was chosen to
+   allow significant growth of either the TLA ID and/or the NLA ID
+   fields.
+
+   The size of the Next-Level Aggregation Identifier field is 24 bits.
+
+
+
+
+Hinden, et. al.             Standards Track                     [Page 8]
+
+RFC 2374           IPv6 Global Unicast Address Format          July 1998
+
+
+   This allows for approximately sixteen million NLA ID's if used in a
+   flat manner.  Used hierarchically it allows for a complexity roughly
+   equivalent to the IPv4 address space (assuming an average network
+   size of 254 interfaces).  If in the future additional room for
+   complexity is needed in the NLA ID, this may be accommodated by
+   extending the NLA ID into the Reserved field.
+
+   The size of the Site-Level Aggregation Identifier field is 16 bits.
+   This supports 65,535 individual subnets per site.  The design goal
+   for the size of this field was to be sufficient for all but the
+   largest of organizations.  Organizations which need additional
+   subnets can arrange with the organization they are obtaining Internet
+   service from to obtain additional site identifiers and use this to
+   create additional subnets.
+
+   The Site-Level Aggregation Identifier field was given a fixed size in
+   order to force the length of all prefixes identifying a particular
+   site to be the same length (i.e., 48 bits).  This facilitates
+   movement of sites in the topology (e.g., changing service providers
+   and multi-homing to multiple service providers).
+
+   The Interface ID Interface Identifier field is 64 bits.  This size
+   was chosen to meet the requirement specified in [ARCH] to support
+   EUI-64 based Interface Identifiers.
+
+5.0 Acknowledgments
+
+   The authors would like to express our thanks to Thomas Narten, Bob
+   Fink, Matt Crawford, Allison Mankin, Jim Bound, Christian Huitema,
+   Scott Bradner, Brian Carpenter, John Stewart, and Daniel Karrenberg
+   for their review and constructive comments.
+
+6.0 References
+
+   [ALLOC]   IAB and IESG, "IPv6 Address Allocation Management",
+             RFC 1881, December 1995.
+
+   [ARCH]    Hinden, R., "IP Version 6 Addressing Architecture",
+             RFC 2373, July 1998.
+
+   [AUTH]    Atkinson, R., "IP Authentication Header", RFC 1826, August
+             1995.
+
+   [AUTO]    Thompson, S., and T. Narten., "IPv6 Stateless Address
+             Autoconfiguration", RFC 1971, August 1996.
+
+   [ETHER]   Crawford, M., "Transmission of IPv6 Packets over Ethernet
+             Networks", Work in Progress.
+
+
+
+Hinden, et. al.             Standards Track                     [Page 9]
+
+RFC 2374           IPv6 Global Unicast Address Format          July 1998
+
+
+   [EUI64]   IEEE, "Guidelines for 64-bit Global Identifier (EUI-64)
+             Registration Authority",
+             http://standards.ieee.org/db/oui/tutorials/EUI64.html,
+             March 1997.
+
+   [FDDI]    Crawford, M., "Transmission of IPv6 Packets over FDDI
+             Networks", Work in Progress.
+
+   [IPV6]    Deering, S., and R. Hinden, "Internet Protocol, Version 6
+             (IPv6) Specification", RFC 1883, December 1995.
+
+   [RFC2050] Hubbard, K., Kosters, M., Conrad, D., Karrenberg, D.,
+             and J. Postel, "Internet Registry IP Allocation
+             Guidelines", BCP 12, RFC 1466, November 1996.
+
+   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+             Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+7.0 Security Considerations
+
+   IPv6 addressing documents do not have any direct impact on Internet
+   infrastructure security.  Authentication of IPv6 packets is defined
+   in [AUTH].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hinden, et. al.             Standards Track                    [Page 10]
+
+RFC 2374           IPv6 Global Unicast Address Format          July 1998
+
+
+8.0 Authors' Addresses
+
+   Robert M. Hinden
+   Nokia
+   232 Java Drive
+   Sunnyvale, CA 94089
+   USA
+
+   Phone: 1 408 990-2004
+   EMail: hinden@iprg.nokia.com
+
+
+   Mike O'Dell
+   UUNET Technologies, Inc.
+   3060 Williams Drive
+   Fairfax, VA 22030
+   USA
+
+   Phone: 1 703 206-5890
+   EMail: mo@uunet.uu.net
+
+
+   Stephen E. Deering
+   Cisco Systems, Inc.
+   170 West Tasman Drive
+   San Jose, CA 95134-1706
+   USA
+
+   Phone: 1 408 527-8213
+   EMail: deering@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hinden, et. al.             Standards Track                    [Page 11]
+
+RFC 2374           IPv6 Global Unicast Address Format          July 1998
+
+
+9.0  Full Copyright Statement
+
+   Copyright (C) The Internet Society (1998).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hinden, et. al.             Standards Track                    [Page 12]
+
diff --git a/doc/rfc/rfc2375.txt b/doc/rfc/rfc2375.txt
new file mode 100644
index 0000000..a1fe8b9
--- /dev/null
+++ b/doc/rfc/rfc2375.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Network Working Group                                         R. Hinden
+Request for Comments: 2375                             Ipsilon Networks
+Category: Informational                                      S. Deering
+                                                                  Cisco
+                                                              July 1998
+
+
+                   IPv6 Multicast Address Assignments
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1998).  All Rights Reserved.
+
+1.0 Introduction
+
+   This document defines the initial assignment of IPv6 multicast
+   addresses.  It is based on the "IP Version 6 Addressing Architecture"
+   [ADDARCH] and current IPv4 multicast address assignment found in
+   <ftp://venera.isi.edu/in-notes/iana/assignments/multicast-addresses>.
+   It adapts the IPv4 assignments that are relevant to IPv6 assignments.
+   IPv4 assignments that were not relevant were not converted into IPv6
+   assignments.  Comments are solicited on this conversion.
+
+   All other IPv6 multicast addresses are reserved.
+
+   Sections 2 and 3 specify reserved and preassigned IPv6 multicast
+   addresses.
+
+   [ADDRARCH] defines rules for assigning new IPv6 multicast addresses.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC 2119].
+
+2. Fixed Scope Multicast Addresses
+
+   These permanently assigned multicast addresses are valid over a
+   specified scope value.
+
+
+
+
+
+
+
+Hinden & Deering             Informational                      [Page 1]
+
+RFC 2375           IPv6 Multicast Address Assignments          July 1998
+
+
+2.1 Node-Local Scope
+
+   FF01:0:0:0:0:0:0:1     All Nodes Address                  [ADDARCH]
+   FF01:0:0:0:0:0:0:2     All Routers Address                [ADDARCH]
+
+2.2 Link-Local Scope
+
+   FF02:0:0:0:0:0:0:1     All Nodes Address                  [ADDARCH]
+   FF02:0:0:0:0:0:0:2     All Routers Address                [ADDARCH]
+   FF02:0:0:0:0:0:0:3     Unassigned                             [JBP]
+   FF02:0:0:0:0:0:0:4     DVMRP Routers                  [RFC1075,JBP]
+   FF02:0:0:0:0:0:0:5     OSPFIGP                        [RFC2328,Moy]
+   FF02:0:0:0:0:0:0:6     OSPFIGP Designated Routers     [RFC2328,Moy]
+   FF02:0:0:0:0:0:0:7     ST Routers                    [RFC1190,KS14]
+   FF02:0:0:0:0:0:0:8     ST Hosts                      [RFC1190,KS14]
+   FF02:0:0:0:0:0:0:9     RIP Routers                        [RFC2080]
+   FF02:0:0:0:0:0:0:A     EIGRP Routers                    [Farinacci]
+   FF02:0:0:0:0:0:0:B     Mobile-Agents                 [Bill Simpson]
+
+   FF02:0:0:0:0:0:0:D     All PIM Routers                  [Farinacci]
+   FF02:0:0:0:0:0:0:E     RSVP-ENCAPSULATION                  [Braden]
+
+   FF02:0:0:0:0:0:1:1     Link Name                       [Harrington]
+   FF02:0:0:0:0:0:1:2     All-dhcp-agents              [Bound,Perkins]
+
+   FF02:0:0:0:0:1:FFXX:XXXX     Solicited-Node Address       [ADDARCH]
+
+2.3 Site-Local Scope
+
+   FF05:0:0:0:0:0:0:2       All Routers Address              [ADDARCH]
+
+   FF05:0:0:0:0:0:1:3       All-dhcp-servers           [Bound,Perkins]
+   FF05:0:0:0:0:0:1:4       All-dhcp-relays            [Bound,Perkins]
+   FF05:0:0:0:0:0:1:1000    Service Location                 [RFC2165]
+    -FF05:0:0:0:0:0:1:13FF
+
+3.0 All Scope Multicast Addresses
+
+   These permanently assigned multicast addresses are valid over all
+   scope ranges.  This is shown by an "X" in the scope field of the
+   address that means any legal scope value.
+
+   Note that, as defined in [ADDARCH], IPv6 multicast addresses which
+   are only different in scope represent different groups.  Nodes must
+   join each group individually.
+
+   The IPv6 multicast addresses with variable scope are as follows:
+
+
+
+
+Hinden & Deering             Informational                      [Page 2]
+
+RFC 2375           IPv6 Multicast Address Assignments          July 1998
+
+
+   FF0X:0:0:0:0:0:0:0     Reserved Multicast Address         [ADDARCH]
+
+   FF0X:0:0:0:0:0:0:100   VMTP Managers Group           [RFC1045,DRC3]
+   FF0X:0:0:0:0:0:0:101   Network Time Protocol (NTP)   [RFC1119,DLM1]
+   FF0X:0:0:0:0:0:0:102   SGI-Dogfight                           [AXC]
+   FF0X:0:0:0:0:0:0:103   Rwhod                                  [SXD]
+   FF0X:0:0:0:0:0:0:104   VNP                                   [DRC3]
+   FF0X:0:0:0:0:0:0:105   Artificial Horizons - Aviator          [BXF]
+   FF0X:0:0:0:0:0:0:106   NSS - Name Service Server             [BXS2]
+   FF0X:0:0:0:0:0:0:107   AUDIONEWS - Audio News Multicast      [MXF2]
+   FF0X:0:0:0:0:0:0:108   SUN NIS+ Information Service          [CXM3]
+   FF0X:0:0:0:0:0:0:109   MTP Multicast Transport Protocol       [SXA]
+   FF0X:0:0:0:0:0:0:10A   IETF-1-LOW-AUDIO                       [SC3]
+   FF0X:0:0:0:0:0:0:10B   IETF-1-AUDIO                           [SC3]
+   FF0X:0:0:0:0:0:0:10C   IETF-1-VIDEO                           [SC3]
+   FF0X:0:0:0:0:0:0:10D   IETF-2-LOW-AUDIO                       [SC3]
+   FF0X:0:0:0:0:0:0:10E   IETF-2-AUDIO                           [SC3]
+   FF0X:0:0:0:0:0:0:10F   IETF-2-VIDEO                           [SC3]
+
+   FF0X:0:0:0:0:0:0:110   MUSIC-SERVICE             [Guido van Rossum]
+   FF0X:0:0:0:0:0:0:111   SEANET-TELEMETRY             [Andrew Maffei]
+   FF0X:0:0:0:0:0:0:112   SEANET-IMAGE                 [Andrew Maffei]
+   FF0X:0:0:0:0:0:0:113   MLOADD                              [Braden]
+   FF0X:0:0:0:0:0:0:114   any private experiment                 [JBP]
+   FF0X:0:0:0:0:0:0:115   DVMRP on MOSPF                         [Moy]
+   FF0X:0:0:0:0:0:0:116   SVRLOC                            [Veizades]
+   FF0X:0:0:0:0:0:0:117   XINGTV                      <hgxing@aol.com>
+   FF0X:0:0:0:0:0:0:118   microsoft-ds         <arnoldm@microsoft.com>
+   FF0X:0:0:0:0:0:0:119   nbc-pro           <bloomer@birch.crd.ge.com>
+   FF0X:0:0:0:0:0:0:11A   nbc-pfn           <bloomer@birch.crd.ge.com>
+   FF0X:0:0:0:0:0:0:11B   lmsc-calren-1                         [Uang]
+   FF0X:0:0:0:0:0:0:11C   lmsc-calren-2                         [Uang]
+   FF0X:0:0:0:0:0:0:11D   lmsc-calren-3                         [Uang]
+   FF0X:0:0:0:0:0:0:11E   lmsc-calren-4                         [Uang]
+   FF0X:0:0:0:0:0:0:11F   ampr-info                          [Janssen]
+
+   FF0X:0:0:0:0:0:0:120   mtrace                              [Casner]
+   FF0X:0:0:0:0:0:0:121   RSVP-encap-1                        [Braden]
+   FF0X:0:0:0:0:0:0:122   RSVP-encap-2                        [Braden]
+   FF0X:0:0:0:0:0:0:123   SVRLOC-DA                         [Veizades]
+   FF0X:0:0:0:0:0:0:124   rln-server                            [Kean]
+   FF0X:0:0:0:0:0:0:125   proshare-mc                          [Lewis]
+   FF0X:0:0:0:0:0:0:126   dantz                               [Yackle]
+   FF0X:0:0:0:0:0:0:127   cisco-rp-announce                [Farinacci]
+   FF0X:0:0:0:0:0:0:128   cisco-rp-discovery               [Farinacci]
+   FF0X:0:0:0:0:0:0:129   gatekeeper                            [Toga]
+   FF0X:0:0:0:0:0:0:12A   iberiagames                        [Marocho]
+
+
+
+
+Hinden & Deering             Informational                      [Page 3]
+
+RFC 2375           IPv6 Multicast Address Assignments          July 1998
+
+
+   FF0X:0:0:0:0:0:0:201  "rwho" Group (BSD) (unofficial)         [JBP]
+   FF0X:0:0:0:0:0:0:202   SUN RPC PMAPPROC_CALLIT               [BXE1]
+
+   FF0X:0:0:0:0:0:2:0000
+    -FF0X:0:0:0:0:0:2:7FFD  Multimedia Conference Calls          [SC3]
+   FF0X:0:0:0:0:0:2:7FFE    SAPv1 Announcements                  [SC3]
+   FF0X:0:0:0:0:0:2:7FFF    SAPv0 Announcements (deprecated)     [SC3]
+   FF0X:0:0:0:0:0:2:8000
+    -FF0X:0:0:0:0:0:2:FFFF  SAP Dynamic Assignments              [SC3]
+
+5.0 References
+
+   [ADDARCH] Hinden, R., and S. Deering, "IP Version 6 Addressing
+             Architecture", RFC 2373, July 1998.
+
+   [AUTORFC] Thompson, S., and T. Narten, "IPv6 Stateless Address
+             Autoconfiguration", RFC 1971, August 1996.
+
+   [ETHER]   Crawford, M., "Transmission of IPv6 Packets over Ethernet
+             Networks", Work in Progress.
+
+   [RFC1045] Cheriton, D., "VMTP: Versatile Message Transaction Protocol
+             Specification", RFC 1045, February 1988.
+
+   [RFC1075] Waitzman, D., Partridge, C., and S. Deering, "Distance
+             Vector Multicast Routing Protocol", RFC 1075, November
+             1988.
+
+   [RFC1112] Deering, S., "Host Extensions for IP Multicasting", STD 5,
+             RFC 1112, Stanford University, August 1989.
+
+   [RFC1119] Mills, D., "Network Time Protocol (Version 1),
+             Specification and Implementation", STD 12, RFC 1119, July
+             1988.
+
+   [RFC1190] Topolcic, C., Editor, "Experimental Internet Stream
+             Protocol, Version 2 (ST-II)", RFC 1190, October 1990.
+
+   [RFC2080] Malkin, G., and R. Minnear, "RIPng for IPv6", RFC 2080,
+             January 1997.
+
+   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+             Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2165] Veizades, J., Guttman, E., Perkins, C., and S. Kaplan
+             "Service Location Protocol", RFC 2165 June 1997.
+
+   [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
+
+
+
+Hinden & Deering             Informational                      [Page 4]
+
+RFC 2375           IPv6 Multicast Address Assignments          July 1998
+
+
+6. People
+
+   <arnoldm@microsoft.com>
+
+   [AXC] Andrew Cherenson <arc@SGI.COM>
+
+   [Braden] Bob Braden, <braden@isi.edu>, April 1996.
+
+   [Bob Brenner]
+
+   [Bressler] David J. Bressler, <bressler@tss.com>, April 1996.
+
+   <bloomer@birch.crd.ge.com>
+
+   [Bound] Jim Bound <bound@zk3.dec.com>
+
+   [BXE1] Brendan Eic <brendan@illyria.wpd.sgi.com>
+
+   [BXF] Bruce Factor <ahi!bigapple!bruce@uunet.UU.NET>
+
+   [BXS2] Bill Schilit <schilit@parc.xerox.com>
+
+   [Casner] Steve Casner, <casner@isi.edu>, January 1995.
+
+   [CXM3] Chuck McManis <cmcmanis@sun.com>
+
+   [Tim Clark]
+
+   [DLM1] David Mills <Mills@HUEY.UDEL.EDU>
+
+   [DRC3] Dave Cheriton <cheriton@PESCADERO.STANFORD.EDU>
+
+   [DXS3] Daniel Steinber <Daniel.Steinberg@Eng.Sun.COM>
+
+   [Farinacci] Dino Farinacci, <dino@cisco.com>
+
+   [GSM11] Gary S. Malkin <GMALKIN@XYLOGICS.COM>
+
+   [Harrington] Dan Harrington, <dan@lucent.com>, July 1996.
+
+   <hgxing@aol.com>
+
+   [IANA] IANA <iana@iana.org>
+
+   [Janssen] Rob Janssen, <rob@pe1chl.ampr.org>, January 1995.
+
+   [JBP] Jon Postel <postel@isi.edu>
+
+
+
+
+Hinden & Deering             Informational                      [Page 5]
+
+RFC 2375           IPv6 Multicast Address Assignments          July 1998
+
+
+   [JXM1] Jim Miner <miner@star.com>
+
+   [Kean] Brian Kean, <bkean@dca.com>, August 1995.
+
+   [KS14] <mystery contact>
+
+   [Lee] Choon Lee, <cwl@nsd.3com.com>, April 1996.
+
+   [Lewis] Mark Lewis, <Mark_Lewis@ccm.jf.intel.com>, October 1995.
+
+   [Malamud] Carl Malamud, <carl@radio.com>, January 1996.
+
+   [Andrew Maffei]
+
+   [Marohco] Jose Luis Marocho, <73374.313@compuserve.com>, July 1996.
+
+   [Moy] John Moy <jmoy@casc.com>
+
+   [MXF2] Martin Forssen <maf@dtek.chalmers.se>
+
+   [Perkins] Charlie Perkins, <cperkins@corp.sun.com>
+
+   [Guido van Rossum]
+
+   [SC3] Steve Casner <casner@isi.edu>
+
+   [Simpson] Bill Simpson <bill.simpson@um.cc.umich.edu> November 1994.
+
+   [Joel Snyder]
+
+   [SXA] Susie Armstrong <Armstrong.wbst128@XEROX.COM>
+
+   [SXD] Steve Deering <deering@PARC.XEROX.COM>
+
+   [tynan] Dermot Tynan, <dtynan@claddagh.ie>, August 1995.
+
+   [Toga] Jim Toga, <jtoga@ibeam.jf.intel.com>, May 1996.
+
+   [Uang] Yea Uang <uang@force.decnet.lockheed.com> November 1994.
+
+   [Veizades] John Veizades,  <veizades@tgv.com>, May 1995.
+
+   [Yackle] Dotty Yackle, <ditty_yackle@dantz.com>, February 1996.
+
+
+
+
+
+
+
+
+Hinden & Deering             Informational                      [Page 6]
+
+RFC 2375           IPv6 Multicast Address Assignments          July 1998
+
+
+7.0 Security Considerations
+
+   This document defines the initial assignment of IPv6 multicast
+   addresses.  As such it does not directly impact the security of the
+   Internet infrastructure or its applications.
+
+8.0 Authors' Addresses
+
+   Robert M. Hinden
+   Ipsilon Networks, Inc.
+   232 Java Drive
+   Sunnyvale, CA 94089
+   USA
+
+   Phone: +1 415 990 2004
+   EMail: hinden@ipsilon.com
+
+
+   Stephen E. Deering
+   Cisco Systems, Inc.
+   170 West Tasman Drive
+   San Jose, CA 95134-1706
+   USA
+
+   Phone: +1 408 527-8213
+   EMail: deering@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hinden & Deering             Informational                      [Page 7]
+
+RFC 2375           IPv6 Multicast Address Assignments          July 1998
+
+
+9.0  Full Copyright Statement
+
+   Copyright (C) The Internet Society (1998).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hinden & Deering             Informational                      [Page 8]
+
diff --git a/doc/rfc/rfc2418.txt b/doc/rfc/rfc2418.txt
new file mode 100644
index 0000000..9bdb2c5
--- /dev/null
+++ b/doc/rfc/rfc2418.txt
@@ -0,0 +1,1459 @@
+
+
+
+
+
+
+Network Working Group                                         S. Bradner
+Request for Comments: 2418                                        Editor
+Obsoletes: 1603                                       Harvard University
+BCP: 25                                                   September 1998
+Category: Best Current Practice
+
+
+                           IETF Working Group
+                       Guidelines and Procedures
+
+Status of this Memo
+
+   This document specifies an Internet Best Current Practices for the
+   Internet Community, and requests discussion and suggestions for
+   improvements.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1998).  All Rights Reserved.
+
+Abstract
+
+   The Internet Engineering Task Force (IETF) has responsibility for
+   developing and reviewing specifications intended as Internet
+   Standards. IETF activities are organized into working groups (WGs).
+   This document describes the guidelines and procedures for formation
+   and operation of IETF working groups. It also describes the formal
+   relationship between IETF participants WG and the Internet
+   Engineering Steering Group (IESG) and the basic duties of IETF
+   participants, including WG Chairs, WG participants, and IETF Area
+   Directors.
+
+Table of Contents
+
+   Abstract .........................................................  1
+   1. Introduction ..................................................  2
+     1.1. IETF approach to standardization ..........................  4
+     1.2. Roles within a Working Group ..............................  4
+   2. Working group formation .......................................  4
+     2.1. Criteria for formation ....................................  4
+     2.2. Charter ...................................................  6
+     2.3. Charter review & approval .................................  8
+     2.4. Birds of a feather (BOF) ..................................  9
+   3. Working Group Operation ....................................... 10
+     3.1. Session planning .......................................... 11
+     3.2. Session venue ............................................. 11
+     3.3. Session management ........................................ 13
+     3.4. Contention and appeals .................................... 15
+
+
+
+Bradner                  Best Current Practice                  [Page 1]
+
+RFC 2418                Working Group Guidelines          September 1998
+
+
+   4. Working Group Termination ..................................... 15
+   5. Rechartering a Working Group .................................. 15
+   6. Staff Roles ................................................... 16
+     6.1. WG Chair .................................................. 16
+     6.2. WG Secretary .............................................. 18
+     6.3. Document Editor ........................................... 18
+     6.4. WG Facilitator ............................................ 18
+     6.5. Design teams .............................................. 19
+     6.6. Working Group Consultant .................................. 19
+     6.7. Area Director ............................................. 19
+   7. Working Group Documents ....................................... 19
+     7.1. Session documents ......................................... 19
+     7.2. Internet-Drafts (I-D) ..................................... 19
+     7.3. Request For Comments (RFC) ................................ 20
+     7.4. Working Group Last-Call ................................... 20
+     7.5. Submission of documents ................................... 21
+   8. Review of documents ........................................... 21
+   9. Security Considerations ....................................... 22
+   10. Acknowledgments .............................................. 23
+   11. References ................................................... 23
+   12. Editor's Address ............................................. 23
+   Appendix:  Sample Working Group Charter .......................... 24
+   Full Copyright Statement ......................................... 26
+
+1. Introduction
+
+   The Internet, a loosely-organized international collaboration of
+   autonomous, interconnected networks, supports host-to-host
+   communication through voluntary adherence to open protocols and
+   procedures defined by Internet Standards.  There are also many
+   isolated interconnected networks, which are not connected to the
+   global Internet but use the Internet Standards. Internet Standards
+   are developed in the Internet Engineering Task Force (IETF).  This
+   document defines guidelines and procedures for IETF working groups.
+   The Internet Standards Process of the IETF is defined in [1]. The
+   organizations involved in the IETF Standards Process are described in
+   [2] as are the roles of specific individuals.
+
+   The IETF is a large, open community of network designers, operators,
+   vendors, users, and researchers concerned with the Internet and the
+   technology used on it. The primary activities of the IETF are
+   performed by committees known as working groups. There are currently
+   more than 100 working groups. (See the IETF web page for an up-to-
+   date list of IETF Working Groups - http://www.ietf.org.) Working
+   groups tend to have a narrow focus and a lifetime bounded by the
+   completion of a specific set of tasks, although there are exceptions.
+
+
+
+
+
+Bradner                  Best Current Practice                  [Page 2]
+
+RFC 2418                Working Group Guidelines          September 1998
+
+
+   For management purposes, the IETF working groups are collected
+   together into areas, with each area having a separate focus.  For
+   example, the security area deals with the development of security-
+   related technology.  Each IETF area is managed by one or two Area
+   Directors (ADs).  There are currently 8 areas in the IETF but the
+   number changes from time to time.  (See the IETF web page for a list
+   of the current areas, the Area Directors for each area, and a list of
+   which working groups are assigned to each area.)
+
+   In many areas, the Area Directors have formed an advisory group or
+   directorate.  These comprise experienced members of the IETF and the
+   technical community represented by the area.  The specific name and
+   the details of the role for each group differ from area to area, but
+   the primary intent is that these groups assist the Area Director(s),
+   e.g., with the review of specifications produced in the area.
+
+   The IETF area directors are selected by a nominating committee, which
+   also selects an overall chair for the IETF.  The nominations process
+   is described in [3].
+
+   The area directors sitting as a body, along with the IETF Chair,
+   comprise the Internet Engineering Steering Group (IESG). The IETF
+   Executive Director is an ex-officio participant of the IESG, as are
+   the IAB Chair and a designated Internet Architecture Board (IAB)
+   liaison.  The IESG approves IETF Standards and approves the
+   publication of other IETF documents.  (See [1].)
+
+   A small IETF Secretariat provides staff and administrative support
+   for the operation of the IETF.
+
+   There is no formal membership in the IETF.  Participation is open to
+   all.  This participation may be by on-line contribution, attendance
+   at face-to-face sessions, or both.  Anyone from the Internet
+   community who has the time and interest is urged to participate in
+   IETF meetings and any of its on-line working group discussions.
+   Participation is by individual technical contributors, rather than by
+   formal representatives of organizations.
+
+   This document defines procedures and guidelines for the formation and
+   operation of working groups in the IETF. It defines the relations of
+   working groups to other bodies within the IETF. The duties of working
+   group Chairs and Area Directors with respect to the operation of the
+   working group are also defined.  When used in this document the key
+   words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
+   "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be
+   interpreted as described in RFC 2119 [6].  RFC 2119 defines the use
+   of these key words to help make the intent of standards track
+   documents as clear as possible.  The same key words are used in this
+
+
+
+Bradner                  Best Current Practice                  [Page 3]
+
+RFC 2418                Working Group Guidelines          September 1998
+
+
+   document to help smooth WG operation and reduce the chance for
+   confusion about the processes.
+
+1.1. IETF approach to standardization
+
+   Familiarity with The Internet Standards Process [1] is essential for
+   a complete understanding of the philosophy, procedures and guidelines
+   described in this document.
+
+1.2. Roles within a Working Group
+
+   The document, "Organizations Involved in the IETF Standards Process"
+   [2] describes the roles of a number of individuals within a working
+   group, including the working group chair and the document editor.
+   These descriptions are expanded later in this document.
+
+2. Working group formation
+
+   IETF working groups (WGs) are the primary mechanism for development
+   of IETF specifications and guidelines, many of which are intended to
+   be standards or recommendations. A working group may be established
+   at the initiative of an Area Director or it may be initiated by an
+   individual or group of individuals. Anyone interested in creating an
+   IETF working group MUST obtain the advice and consent of the IETF
+   Area Director(s) in whose area the working group would fall and MUST
+   proceed through the formal steps detailed in this section.
+
+   Working groups are typically created to address a specific problem or
+   to produce one or more specific deliverables (a guideline, standards
+   specification, etc.).  Working groups are generally expected to be
+   short-lived in nature.  Upon completion of its goals and achievement
+   of its objectives, the working group is terminated. A working group
+   may also be terminated for other reasons (see section 4).
+   Alternatively, with the concurrence of the IESG, Area Director, the
+   WG Chair, and the WG participants, the objectives or assignment of
+   the working group may be extended by modifying the working group's
+   charter through a rechartering process (see section 5).
+
+2.1. Criteria for formation
+
+   When determining whether it is appropriate to create a working group,
+   the Area Director(s) and the IESG will consider several issues:
+
+    - Are the issues that the working group plans to address clear and
+      relevant to the Internet community?
+
+    - Are the goals specific and reasonably achievable, and achievable
+      within a reasonable time frame?
+
+
+
+Bradner                  Best Current Practice                  [Page 4]
+
+RFC 2418                Working Group Guidelines          September 1998
+
+
+    - What are the risks and urgency of the work, to determine the level
+      of effort required?
+
+    - Do the working group's activities overlap with those of another
+      working group?  If so, it may still be appropriate to create the
+      working group, but this question must be considered carefully by
+      the Area Directors as subdividing efforts often dilutes the
+      available technical expertise.
+
+    - Is there sufficient interest within the IETF in the working
+      group's topic with enough people willing to expend the effort to
+      produce the desired result (e.g., a protocol specification)?
+      Working groups require considerable effort, including management
+      of the working group process, editing of working group documents,
+      and contributing to the document text.  IETF experience suggests
+      that these roles typically cannot all be handled by one person; a
+      minimum of four or five active participants in the management
+      positions are typically required in addition to a minimum of one
+      or two dozen people that will attend the working group meetings
+      and contribute on the mailing list.  NOTE: The interest must be
+      broad enough that a working group would not be seen as merely the
+      activity of a single vendor.
+
+    - Is there enough expertise within the IETF in the working group's
+      topic, and are those people interested in contributing in the
+      working group?
+
+    - Does a base of interested consumers (end-users) appear to exist
+      for the planned work?  Consumer interest can be measured by
+      participation of end-users within the IETF process, as well as by
+      less direct means.
+
+    - Does the IETF have a reasonable role to play in the determination
+      of the technology?  There are many Internet-related technologies
+      that may be interesting to IETF members but in some cases the IETF
+      may not be in a position to effect the course of the technology in
+      the "real world".  This can happen, for example, if the technology
+      is being developed by another standards body or an industry
+      consortium.
+
+    - Are all known intellectual property rights relevant to the
+      proposed working group's efforts issues understood?
+
+    - Is the proposed work plan an open IETF effort or is it an attempt
+      to "bless" non-IETF technology where the effect of input from IETF
+      participants may be limited?
+
+
+
+
+
+Bradner                  Best Current Practice                  [Page 5]
+
+RFC 2418                Working Group Guidelines          September 1998
+
+
+    - Is there a good understanding of any existing work that is
+      relevant to the topics that the proposed working group is to
+      pursue?  This includes work within the IETF and elsewhere.
+
+    - Do the working group's goals overlap with known work in another
+      standards body, and if so is adequate liaison in place?
+
+   Considering the above criteria, the Area Director(s), using his or
+   her best judgement, will decide whether to pursue the formation of
+   the group through the chartering process.
+
+2.2. Charter
+
+   The formation of a working group requires a charter which is
+   primarily negotiated between a prospective working group Chair and
+   the relevant Area Director(s), although final approval is made by the
+   IESG with advice from the Internet Architecture Board (IAB).  A
+   charter is a contract between a working group and the IETF to perform
+   a set of tasks.  A charter:
+
+   1. Lists relevant administrative information for the working group;
+   2. Specifies the direction or objectives of the working group and
+      describes the approach that will be taken to achieve the goals;
+      and
+   3. Enumerates a set of milestones together with time frames for their
+      completion.
+
+   When the prospective Chair(s), the Area Director and the IETF
+   Secretariat are satisfied with the charter form and content, it
+   becomes the basis for forming a working group. Note that an Area
+   Director MAY require holding an exploratory Birds of a Feather (BOF)
+   meeting, as described below, to gage the level of support for a
+   working group before submitting the charter to the IESG and IAB for
+   approval.
+
+   Charters may be renegotiated periodically to reflect the current
+   status, organization or goals of the working group (see section 5).
+   Hence, a charter is a contract between the IETF and the working group
+   which is committing to meet explicit milestones and delivering
+   specific "products".
+
+   Specifically, each charter consists of the following sections:
+
+   Working group name
+      A working group name should be reasonably descriptive or
+      identifiable. Additionally, the group shall define an acronym
+      (maximum 8 printable ASCII characters) to reference the group in
+      the IETF directories, mailing lists, and general documents.
+
+
+
+Bradner                  Best Current Practice                  [Page 6]
+
+RFC 2418                Working Group Guidelines          September 1998
+
+
+   Chair(s)
+      The working group may have one or more Chairs to perform the
+      administrative functions of the group. The email address(es) of
+      the Chair(s) shall be included.  Generally, a working group is
+      limited to two chairs.
+
+   Area and Area Director(s)
+      The name of the IETF area with which the working group is
+      affiliated and the name and electronic mail address of the
+      associated Area Director(s).
+
+   Responsible Area Director
+      The Area Director who acts as the primary IESG contact for the
+      working group.
+
+   Mailing list
+      An IETF working group MUST have a general Internet mailing list.
+      Most of the work of an IETF working group will be conducted on the
+      mailing list. The working group charter MUST include:
+
+      1. The address to which a participant sends a subscription request
+         and the procedures to follow when subscribing,
+
+      2. The address to which a participant sends submissions and
+         special procedures, if any, and
+
+      3. The location of the mailing list archive. A message archive
+         MUST be maintained in a public place which can be accessed via
+         FTP or via the web.
+
+         As a service to the community, the IETF Secretariat operates a
+         mailing list archive for working group mailing lists. In order
+         to take advantage of this service, working group mailing lists
+         MUST include the address "wg_acronym-archive@lists.ietf.org"
+         (where "wg_acronym" is the working group acronym) in the
+         mailing list in order that a copy of all mailing list messages
+         be recorded in the Secretariat's archive.  Those archives are
+         located at ftp://ftp.ietf.org/ietf-mail-archive.  For
+         robustness, WGs SHOULD maintain an additional archive separate
+         from that maintained by the Secretariat.
+
+   Description of working group
+      The focus and intent of the group shall be set forth briefly. By
+      reading this section alone, an individual should be able to decide
+      whether this group is relevant to their own work. The first
+      paragraph must give a brief summary of the problem area, basis,
+      goal(s) and approach(es) planned for the working group.  This
+      paragraph can be used as an overview of the working group's
+
+
+
+Bradner                  Best Current Practice                  [Page 7]
+
+RFC 2418                Working Group Guidelines          September 1998
+
+
+      effort.
+
+      To facilitate evaluation of the intended work and to provide on-
+      going guidance to the working group, the charter must describe the
+      problem being solved and should discuss objectives and expected
+      impact with respect to:
+
+         - Architecture
+         - Operations
+         - Security
+         - Network management
+         - Scaling
+         - Transition (where applicable)
+
+   Goals and milestones
+      The working group charter MUST establish a timetable for specific
+      work items.  While this may be renegotiated over time, the list of
+      milestones and dates facilitates the Area Director's tracking of
+      working group progress and status, and it is indispensable to
+      potential participants identifying the critical moments for input.
+      Milestones shall consist of deliverables that can be qualified as
+      showing specific achievement; e.g., "Internet-Draft finished" is
+      fine, but "discuss via email" is not. It is helpful to specify
+      milestones for every 3-6 months, so that progress can be gauged
+      easily.  This milestone list is expected to be updated
+      periodically (see section 5).
+
+      An example of a WG charter is included as Appendix A.
+
+2.3. Charter review & approval
+
+   Proposed working groups often comprise technically competent
+   participants who are not familiar with the history of Internet
+   architecture or IETF processes.  This can, unfortunately, lead to
+   good working group consensus about a bad design.  To facilitate
+   working group efforts, an Area Director may assign a Consultant from
+   among the ranks of senior IETF participants.  (Consultants are
+   described in section 6.)  At the discretion of the Area Director,
+   approval of a new WG may be withheld in the absence of sufficient
+   consultant resources.
+
+   Once the Area Director (and the Area Directorate, as the Area
+   Director deems appropriate) has approved the working group charter,
+   the charter is submitted for review by the IAB and approval by the
+   IESG.  After a review period of at least a week the proposed charter
+   is posted to the IETF-announce mailing list as a public notice that
+   the formation of the working group is being considered.  At the same
+   time the proposed charter is also posted to the "new-work" mailing
+
+
+
+Bradner                  Best Current Practice                  [Page 8]
+
+RFC 2418                Working Group Guidelines          September 1998
+
+
+   list.  This mailing list has been created to let qualified
+   representatives from other standards organizations know about pending
+   IETF working groups.  After another review period lasting at least a
+   week the IESG MAY approve the charter as-is, it MAY request that
+   changes be made in the charter, or MAY decline to approve chartering
+   of the working group
+
+   If the IESG approves the formation of the working group it remands
+   the approved charter to the IETF Secretariat who records and enters
+   the information into the IETF tracking database.  The working group
+   is announced to the IETF-announce a by the IETF Secretariat.
+
+2.4. Birds of a Feather (BOF)
+
+   Often it is not clear whether an issue merits the formation of a
+   working group.  To facilitate exploration of the issues the IETF
+   offers the possibility of a Birds of a Feather (BOF) session, as well
+   as the early formation of an email list for preliminary discussion.
+   In addition, a BOF may serve as a forum for a single presentation or
+   discussion, without any intent to form a working group.
+
+   A BOF is a session at an IETF meeting which permits "market research"
+   and technical "brainstorming".  Any individual may request permission
+   to hold a BOF on a subject. The request MUST be filed with a relevant
+   Area Director who must approve a BOF before it can be scheduled. The
+   person who requests the BOF may be asked to serve as Chair of the
+   BOF.
+
+   The Chair of the BOF is also responsible for providing a report on
+   the outcome of the BOF.  If the Area Director approves, the BOF is
+   then scheduled by submitting a request to agenda@ietf.org with copies
+   to the Area Director(s). A BOF description and agenda are required
+   before a BOF can be scheduled.
+
+   Available time for BOFs is limited, and BOFs are held at the
+   discretion of the ADs for an area.  The AD(s) may require additional
+   assurances before authorizing a BOF.  For example,
+
+    - The Area Director MAY require the establishment of an open email
+      list prior to authorizing a BOF.  This permits initial exchanges
+      and sharing of framework, vocabulary and approaches, in order to
+      make the time spent in the BOF more productive.
+
+    - The Area Director MAY require that a BOF be held, prior to
+      establishing a working group (see section 2.2).
+
+    - The Area Director MAY require that there be a draft of the WG
+      charter prior to holding a BOF.
+
+
+
+Bradner                  Best Current Practice                  [Page 9]
+
+RFC 2418                Working Group Guidelines          September 1998
+
+
+    - The Area Director MAY require that a BOF not be held until an
+      Internet-Draft describing the proposed technology has been
+      published so it can be used as a basis for discussion in the BOF.
+
+   In general, a BOF on a particular topic is held only once (ONE slot
+   at one IETF Plenary meeting). Under unusual circumstances Area
+   Directors may, at their discretion, allow a BOF to meet for a second
+   time. BOFs are not permitted to meet three times.  Note that all
+   other things being equal, WGs will be given priority for meeting
+   space over BOFs.  Also, occasionally BOFs may be held for other
+   purposes than to discuss formation of a working group.
+
+   Usually the outcome of a BOF will be one of the following:
+
+    - There was enough interest and focus in the subject to warrant the
+      formation of a WG;
+
+    - While there was a reasonable level of interest expressed in the
+      BOF some other criteria for working group formation was not met
+      (see section 2.1).
+
+    - The discussion came to a fruitful conclusion, with results to be
+      written down and published, however there is no need to establish
+      a WG; or
+
+    - There was not enough interest in the subject to warrant the
+      formation of a WG.
+
+3.  Working Group Operation
+
+   The IETF has basic requirements for open and fair participation and
+   for thorough consideration of technical alternatives.  Within those
+   constraints, working groups are autonomous and each determines most
+   of the details of its own operation with respect to session
+   participation, reaching closure, etc. The core rule for operation is
+   that acceptance or agreement is achieved via working group "rough
+   consensus".  WG participants should specifically note the
+   requirements for disclosure of conflicts of interest in [2].
+
+   A number of procedural questions and issues will arise over time, and
+   it is the function of the Working Group Chair(s) to manage the group
+   process, keeping in mind that the overall purpose of the group is to
+   make progress towards reaching rough consensus in realizing the
+   working group's goals and objectives.
+
+   There are few hard and fast rules on organizing or conducting working
+   group activities, but a set of guidelines and practices has evolved
+   over time that have proven successful. These are listed here, with
+
+
+
+Bradner                  Best Current Practice                 [Page 10]
+
+RFC 2418                Working Group Guidelines          September 1998
+
+
+   actual choices typically determined by the working group participants
+   and the Chair(s).
+
+3.1. Session planning
+
+   For coordinated, structured WG interactions, the Chair(s) MUST
+   publish a draft agenda well in advance of the actual session. The
+   agenda should contain at least:
+
+   - The items for discussion;
+   - The estimated time necessary per item; and
+   - A clear indication of what documents the participants will need to
+     read before the session in order to be well prepared.
+
+   Publication of the working group agenda shall include sending a copy
+   of the agenda to the working group mailing list and to
+   agenda@ietf.org.
+
+   All working group actions shall be taken in a public forum, and wide
+   participation is encouraged. A working group will conduct much of its
+   business via electronic mail distribution lists but may meet
+   periodically to discuss and review task status and progress, to
+   resolve specific issues and to direct future activities.  IETF
+   Plenary meetings are the primary venue for these face-to-face working
+   group sessions, and it is common (though not required) that active
+   "interim" face-to-face meetings, telephone conferences, or video
+   conferences may also be held.  Interim meetings are subject to the
+   same rules for advance notification, reporting, open participation,
+   and process, which apply to other working group meetings.
+
+   All working group sessions (including those held outside of the IETF
+   meetings) shall be reported by making minutes available.  These
+   minutes should include the agenda for the session, an account of the
+   discussion including any decisions made, and a list of attendees. The
+   Working Group Chair is responsible for insuring that session minutes
+   are written and distributed, though the actual task may be performed
+   by someone designated by the Working Group Chair. The minutes shall
+   be submitted in printable ASCII text for publication in the IETF
+   Proceedings, and for posting in the IETF Directories and are to be
+   sent to: minutes@ietf.org
+
+3.2. Session venue
+
+   Each working group will determine the balance of email and face-to-
+   face sessions that is appropriate for achieving its milestones.
+   Electronic mail permits the widest participation; face-to-face
+   meetings often permit better focus and therefore can be more
+   efficient for reaching a consensus among a core of the working group
+
+
+
+Bradner                  Best Current Practice                 [Page 11]
+
+RFC 2418                Working Group Guidelines          September 1998
+
+
+   participants.  In determining the balance, the WG must ensure that
+   its process does not serve to exclude contribution by email-only
+   participants.  Decisions reached during a face-to-face meeting about
+   topics or issues which have not been discussed on the mailing list,
+   or are significantly different from previously arrived mailing list
+   consensus MUST be reviewed on the mailing list.
+
+   IETF Meetings
+   If a WG needs a session at an IETF meeting, the Chair must apply for
+   time-slots as soon as the first announcement of that IETF meeting is
+   made by the IETF Secretariat to the WG-chairs list.  Session time is
+   a scarce resource at IETF meetings, so placing requests early will
+   facilitate schedule coordination for WGs requiring the same set of
+   experts.
+
+   The application for a WG session at an IETF meeting MUST be made to
+   the IETF Secretariat at the address agenda@ietf.org.  Some Area
+   Directors may want to coordinate WG sessions in their area and
+   request that time slots be coordinated through them.  If this is the
+   case it will be noted in the IETF meeting announcement. A WG
+   scheduling request MUST contain:
+
+   - The working group name and full title;
+   - The amount of time requested;
+   - The rough outline of the WG agenda that is expected to be covered;
+   - The estimated number of people that will attend the WG session;
+   - Related WGs that should not be scheduled for the same time slot(s);
+     and
+   - Optionally a request can be added for the WG session to be
+     transmitted over the Internet in audio and video.
+
+   NOTE: While open discussion and contribution is essential to working
+   group success, the Chair is responsible for ensuring forward
+   progress.  When acceptable to the WG, the Chair may call for
+   restricted participation (but not restricted attendance!) at IETF
+   working group sessions for the purpose of achieving progress. The
+   Working Group Chair then has the authority to refuse to grant the
+   floor to any individual who is unprepared or otherwise covering
+   inappropriate material, or who, in the opinion of the Chair is
+   disrupting the WG process.  The Chair should consult with the Area
+   Director(s) if the individual persists in disruptive behavior.
+
+   On-line
+   It can be quite useful to conduct email exchanges in the same manner
+   as a face-to-face session, with published schedule and agenda, as
+   well as on-going summarization and consensus polling.
+
+
+
+
+
+Bradner                  Best Current Practice                 [Page 12]
+
+RFC 2418                Working Group Guidelines          September 1998
+
+
+   Many working group participants hold that mailing list discussion is
+   the best place to consider and resolve issues and make decisions. The
+   choice of operational style is made by the working group itself.  It
+   is important to note, however, that Internet email discussion is
+   possible for a much wider base of interested persons than is
+   attendance at IETF meetings, due to the time and expense required to
+   attend.
+
+   As with face-to-face sessions occasionally one or more individuals
+   may engage in behavior on a mailing list which disrupts the WG's
+   progress.  In these cases the Chair should attempt to discourage the
+   behavior by communication directly with the offending individual
+   rather than on the open mailing list.  If the behavior persists then
+   the Chair must involve the Area Director in the issue.  As a last
+   resort and after explicit warnings, the Area Director, with the
+   approval of the IESG, may request that the mailing list maintainer
+   block the ability of the offending individual to post to the mailing
+   list. (If the mailing list software permits this type of operation.)
+   Even if this is done, the individual must not be prevented from
+   receiving messages posted to the list.  Other methods of mailing list
+   control may be considered but must be approved by the AD(s) and the
+   IESG.
+
+3.3. Session management
+
+   Working groups make decisions through a "rough consensus" process.
+   IETF consensus does not require that all participants agree although
+   this is, of course, preferred.  In general, the dominant view of the
+   working group shall prevail.  (However, it must be noted that
+   "dominance" is not to be determined on the basis of volume or
+   persistence, but rather a more general sense of agreement.) Consensus
+   can be determined by a show of hands, humming, or any other means on
+   which the WG agrees (by rough consensus, of course).  Note that 51%
+   of the working group does not qualify as "rough consensus" and 99% is
+   better than rough.  It is up to the Chair to determine if rough
+   consensus has been reached.
+
+   It can be particularly challenging to gauge the level of consensus on
+   a mailing list.  There are two different cases where a working group
+   may be trying to understand the level of consensus via a mailing list
+   discussion. But in both cases the volume of messages on a topic is
+   not, by itself, a good indicator of consensus since one or two
+   individuals may be generating much of the traffic.
+
+   In the case where a consensus which has been reached during a face-
+   to-face meeting is being verified on a mailing list the people who
+   were in the meeting and expressed agreement must be taken into
+   account.  If there were 100 people in a meeting and only a few people
+
+
+
+Bradner                  Best Current Practice                 [Page 13]
+
+RFC 2418                Working Group Guidelines          September 1998
+
+
+   on the mailing list disagree with the consensus of the meeting then
+   the consensus should be seen as being verified.  Note that enough
+   time should be given to the verification process for the mailing list
+   readers to understand and consider any objections that may be raised
+   on the list.  The normal two week last-call period should be
+   sufficient for this.
+
+   The other case is where the discussion has been held entirely over
+   the mailing list.  The determination of the level of consensus may be
+   harder to do in this case since most people subscribed to mailing
+   lists do not actively participate in discussions on the list. It is
+   left to the discretion of the working group chair how to evaluate the
+   level of consensus.  The most common method used is for the working
+   group chair to state what he or she believes to be the consensus view
+   and. at the same time, requests comments from the list about the
+   stated conclusion.
+
+   The challenge to managing working group sessions is to balance the
+   need for open and fair consideration of the issues against the need
+   to make forward progress.  The working group, as a whole, has the
+   final responsibility for striking this balance.  The Chair has the
+   responsibility for overseeing the process but may delegate direct
+   process management to a formally-designated Facilitator.
+
+   It is occasionally appropriate to revisit a topic, to re-evaluate
+   alternatives or to improve the group's understanding of a relevant
+   decision.  However, unnecessary repeated discussions on issues can be
+   avoided if the Chair makes sure that the main arguments in the
+   discussion (and the outcome) are summarized and archived after a
+   discussion has come to conclusion. It is also good practice to note
+   important decisions/consensus reached by email in the minutes of the
+   next 'live' session, and to summarize briefly the decision-making
+   history in the final documents the WG produces.
+
+   To facilitate making forward progress, a Working Group Chair may wish
+   to decide to reject or defer the input from a member, based upon the
+   following criteria:
+
+   Old
+   The input pertains to a topic that already has been resolved and is
+   redundant with information previously available;
+
+   Minor
+   The input is new and pertains to a topic that has already been
+   resolved, but it is felt to be of minor import to the existing
+   decision;
+
+
+
+
+
+Bradner                  Best Current Practice                 [Page 14]
+
+RFC 2418                Working Group Guidelines          September 1998
+
+
+   Timing
+   The input pertains to a topic that the working group has not yet
+   opened for discussion; or
+
+   Scope
+   The input is outside of the scope of the working group charter.
+
+3.4. Contention and appeals
+
+   Disputes are possible at various stages during the IETF process. As
+   much as possible the process is designed so that compromises can be
+   made, and genuine consensus achieved; however, there are times when
+   even the most reasonable and knowledgeable people are unable to
+   agree.  To achieve the goals of openness and fairness, such conflicts
+   must be resolved by a process of open review and discussion.
+
+   Formal procedures for requesting a review of WG, Chair, Area Director
+   or IESG actions and conducting appeals are documented in The Internet
+   Standards Process [1].
+
+4. Working Group Termination
+
+   Working groups are typically chartered to accomplish a specific task
+   or tasks.  After the tasks are complete, the group will be disbanded.
+   However, if a WG produces a Proposed or Draft Standard, the WG will
+   frequently become dormant rather than disband (i.e., the WG will no
+   longer conduct formal activities, but the mailing list will remain
+   available to review the work as it moves to Draft Standard and
+   Standard status.)
+
+   If, at some point, it becomes evident that a working group is unable
+   to complete the work outlined in the charter, or if the assumptions
+   which that work was based have been modified in discussion or by
+   experience, the Area Director, in consultation with the working group
+   can either:
+
+   1. Recharter to refocus its tasks,
+   2. Choose new Chair(s), or
+   3. Disband.
+
+   If the working group disagrees with the Area Director's choice, it
+   may appeal to the IESG (see section 3.4).
+
+5. Rechartering a Working Group
+
+   Updated milestones are renegotiated with the Area Director and the
+   IESG, as needed, and then are submitted to the IESG Secretariat:
+   iesg-secretary@ietf.org.
+
+
+
+Bradner                  Best Current Practice                 [Page 15]
+
+RFC 2418                Working Group Guidelines          September 1998
+
+
+   Rechartering (other than revising milestones) a working group follows
+   the same procedures that the initial chartering does (see section 2).
+   The revised charter must be submitted to the IESG and IAB for
+   approval.  As with the initial chartering, the IESG may approve new
+   charter as-is, it may request that changes be made in the new charter
+   (including having the Working Group continue to use the old charter),
+   or it may decline to approve the rechartered working group.  In the
+   latter case, the working group is disbanded.
+
+6. Staff Roles
+
+   Working groups require considerable care and feeding.  In addition to
+   general participation, successful working groups benefit from the
+   efforts of participants filling specific functional roles.  The Area
+   Director must agree to the specific people performing the WG Chair,
+   and Working Group Consultant roles, and they serve at the discretion
+   of the Area Director.
+
+6.1. WG Chair
+
+   The Working Group Chair is concerned with making forward progress
+   through a fair and open process, and has wide discretion in the
+   conduct of WG business.  The Chair must ensure that a number of tasks
+   are performed, either directly or by others assigned to the tasks.
+
+   The Chair has the responsibility and the authority to make decisions,
+   on behalf of the working group, regarding all matters of working
+   group process and staffing, in conformance with the rules of the
+   IETF.  The AD has the authority and the responsibility to assist in
+   making those decisions at the request of the Chair or when
+   circumstances warrant such an intervention.
+
+   The Chair's responsibility encompasses at least the following:
+
+   Ensure WG process and content management
+
+      The Chair has ultimate responsibility for ensuring that a working
+      group achieves forward progress and meets its milestones.  The
+      Chair is also responsible to ensure that the working group
+      operates in an open and fair manner.  For some working groups,
+      this can be accomplished by having the Chair perform all
+      management-related activities.  In other working groups --
+      particularly those with large or divisive participation -- it is
+      helpful to allocate process and/or secretarial functions to other
+      participants.  Process management pertains strictly to the style
+      of working group interaction and not to its content. It ensures
+      fairness and detects redundancy.  The secretarial function
+      encompasses document editing.  It is quite common for a working
+
+
+
+Bradner                  Best Current Practice                 [Page 16]
+
+RFC 2418                Working Group Guidelines          September 1998
+
+
+      group to assign the task of specification Editor to one or two
+      participants.  Sometimes, they also are part of the design team,
+      described below.
+
+   Moderate the WG email list
+
+      The Chair should attempt to ensure that the discussions on this
+      list are relevant and that they converge to consensus agreements.
+      The Chair should make sure that discussions on the list are
+      summarized and that the outcome is well documented (to avoid
+      repetition).  The Chair also may choose to schedule organized on-
+      line "sessions" with agenda and deliverables.  These can be
+      structured as true meetings, conducted over the course of several
+      days (to allow participation across the Internet).
+
+      Organize, prepare and chair face-to-face and on-line formal
+      sessions.
+
+   Plan WG Sessions
+
+      The Chair must plan and announce all WG sessions well in advance
+      (see section 3.1).
+
+   Communicate results of sessions
+
+      The Chair and/or Secretary must ensure that minutes of a session
+      are taken and that an attendance list is circulated (see section
+      3.1).
+
+      Immediately after a session, the WG Chair MUST provide the Area
+      Director with a very short report (approximately one paragraph,
+      via email) on the session.
+
+   Distribute the workload
+
+      Of course, each WG will have participants who may not be able (or
+      want) to do any work at all. Most of the time the bulk of the work
+      is done by a few dedicated participants. It is the task of the
+      Chair to motivate enough experts to allow for a fair distribution
+      of the workload.
+
+   Document development
+
+      Working groups produce documents and documents need authors. The
+      Chair must make sure that authors of WG documents incorporate
+      changes as agreed to by the WG (see section 6.3).
+
+
+
+
+
+Bradner                  Best Current Practice                 [Page 17]
+
+RFC 2418                Working Group Guidelines          September 1998
+
+
+   Document publication
+
+      The Chair and/or Document Editor will work with the RFC Editor to
+      ensure document conformance with RFC publication requirements [5]
+      and to coordinate any editorial changes suggested by the RFC
+      Editor.  A particular concern is that all participants are working
+      from the same version of a document at the same time.
+
+   Document implementations
+
+      Under the procedures described in [1], the Chair is responsible
+      for documenting the specific implementations which qualify the
+      specification for Draft or Internet Standard status along with
+      documentation about testing of the interoperation of these
+      implementations.
+
+6.2. WG Secretary
+
+   Taking minutes and editing working group documents often is performed
+   by a specifically-designated participant or set of participants.  In
+   this role, the Secretary's job is to record WG decisions, rather than
+   to perform basic specification.
+
+6.3. Document Editor
+
+   Most IETF working groups focus their efforts on a document, or set of
+   documents, that capture the results of the group's work.  A working
+   group generally designates a person or persons to serve as the Editor
+   for a particular document.  The Document Editor is responsible for
+   ensuring that the contents of the document accurately reflect the
+   decisions that have been made by the working group.
+
+   As a general practice, the Working Group Chair and Document Editor
+   positions are filled by different individuals to help ensure that the
+   resulting documents accurately reflect the consensus of the working
+   group and that all processes are followed.
+
+6.4. WG Facilitator
+
+   When meetings tend to become distracted or divisive, it often is
+   helpful to assign the task of "process management" to one
+   participant.  Their job is to oversee the nature, rather than the
+   content, of participant interactions.  That is, they attend to the
+   style of the discussion and to the schedule of the agenda, rather
+   than making direct technical contributions themselves.
+
+
+
+
+
+
+Bradner                  Best Current Practice                 [Page 18]
+
+RFC 2418                Working Group Guidelines          September 1998
+
+
+6.5. Design teams
+
+   It is often useful, and perhaps inevitable, for a sub-group of a
+   working group to develop a proposal to solve a particular problem.
+   Such a sub-group is called a design team.  In order for a design team
+   to remain small and agile, it is acceptable to have closed membership
+   and private meetings.  Design teams may range from an informal chat
+   between people in a hallway to a formal set of expert volunteers that
+   the WG chair or AD appoints to attack a controversial problem.  The
+   output of a design team is always subject to approval, rejection or
+   modification by the WG as a whole.
+
+6.6. Working Group Consultant
+
+   At the discretion of the Area Director, a Consultant may be assigned
+   to a working group.  Consultants have specific technical background
+   appropriate to the WG and experience in Internet architecture and
+   IETF process.
+
+6.7. Area Director
+
+   Area Directors are responsible for ensuring that working groups in
+   their area produce coherent, coordinated, architecturally consistent
+   and timely output as a contribution to the overall results of the
+   IETF.
+
+7.  Working Group Documents
+
+7.1. Session documents
+
+   All relevant documents to be discussed at a session should be
+   published and available as Internet-Drafts at least two weeks before
+   a session starts.  Any document which does not meet this publication
+   deadline can only be discussed in a working group session with the
+   specific approval of the working group chair(s).  Since it is
+   important that working group members have adequate time to review all
+   documents, granting such an exception should only be done under
+   unusual conditions.  The final session agenda should be posted to the
+   working group mailing list at least two weeks before the session and
+   sent at that time to agenda@ietf.org for publication on the IETF web
+   site.
+
+7.2. Internet-Drafts (I-D)
+
+   The Internet-Drafts directory is provided to working groups as a
+   resource for posting and disseminating in-process copies of working
+   group documents. This repository is replicated at various locations
+   around the Internet. It is encouraged that draft documents be posted
+
+
+
+Bradner                  Best Current Practice                 [Page 19]
+
+RFC 2418                Working Group Guidelines          September 1998
+
+
+   as soon as they become reasonably stable.
+
+   It is stressed here that Internet-Drafts are working documents and
+   have no official standards status whatsoever. They may, eventually,
+   turn into a standards-track document or they may sink from sight.
+   Internet-Drafts are submitted to: internet-drafts@ietf.org
+
+   The format of an Internet-Draft must be the same as for an RFC [2].
+   Further, an I-D must contain:
+
+   - Beginning, standard, boilerplate text which is provided by the
+     Secretariat on their web site and in the ftp directory;
+   - The I-D filename; and
+   - The expiration date for the I-D.
+
+   Complete specification of requirements for an Internet-Draft are
+   found in the file "1id-guidelines.txt" in the Internet-Drafts
+   directory at an Internet Repository site.  The organization of the
+   Internet-Drafts directory is found in the file "1id-organization" in
+   the Internet-Drafts directory at an Internet Repository site.  This
+   file also contains the rules for naming Internet-Drafts.  (See [1]
+   for more information about Internet-Drafts.)
+
+7.3. Request For Comments (RFC)
+
+   The work of an IETF working group often results in publication of one
+   or more documents, as part of the Request For Comments (RFCs) [1]
+   series. This series is the archival publication record for the
+   Internet community. A document can be written by an individual in a
+   working group, by a group as a whole with a designated Editor, or by
+   others not involved with the IETF.
+
+   NOTE: The RFC series is a publication mechanism only and publication
+   does not determine the IETF status of a document.  Status is
+   determined through separate, explicit status labels assigned by the
+   IESG on behalf of the IETF.  In other words, the reader is reminded
+   that all Internet Standards are published as RFCs, but NOT all RFCs
+   specify standards [4].
+
+7.4. Working Group Last-Call
+
+   When a WG decides that a document is ready for publication it may be
+   submitted to the IESG for consideration. In most cases the
+   determination that a WG feels that a document is ready for
+   publication is done by the WG Chair issuing a working group Last-
+   Call.  The decision to issue a working group Last-Call is at the
+   discretion of the WG Chair working with the Area Director.  A working
+   group Last-Call serves the same purpose within a working group that
+
+
+
+Bradner                  Best Current Practice                 [Page 20]
+
+RFC 2418                Working Group Guidelines          September 1998
+
+
+   an IESG Last-Call does in the broader IETF community (see [1]).
+
+7.5. Submission of documents
+
+   Once that a WG has determined at least rough consensus exists within
+   the WG for the advancement of a document the following must be done:
+
+   - The version of the relevant document exactly as agreed to by the WG
+     MUST be in the Internet-Drafts directory.
+
+   - The relevant document MUST be formatted according to section 7.3.
+
+   - The WG Chair MUST send email to the relevant Area Director.  A copy
+     of the request MUST be also sent to the IESG Secretariat.  The mail
+     MUST contain the reference to the document's ID filename, and the
+     action requested.  The copy of the message to the IESG Secretariat
+     is to ensure that the request gets recorded by the Secretariat so
+     that they can monitor the progress of the document through the
+     process.
+
+   Unless returned by the IESG to the WG for further development,
+   progressing of the document is then the responsibility of the IESG.
+   After IESG approval, responsibility for final disposition is the
+   joint responsibility of the RFC Editor, the WG Chair and the Document
+   Editor.
+
+8. Review of documents
+
+   The IESG reviews all documents submitted for publication as RFCs.
+   Usually minimal IESG review is necessary in the case of a submission
+   from a WG intended as an Informational or Experimental RFC. More
+   extensive review is undertaken in the case of standards-track
+   documents.
+
+   Prior to the IESG beginning their deliberations on standards-track
+   documents, IETF Secretariat will issue a "Last-Call" to the IETF
+   mailing list (see [1]). This Last Call will announce the intention of
+   the IESG to consider the document, and it will solicit final comments
+   from the IETF within a period of two weeks.  It is important to note
+   that a Last-Call is intended as a brief, final check with the
+   Internet community, to make sure that no important concerns have been
+   missed or misunderstood. The Last-Call should not serve as a more
+   general, in-depth review.
+
+   The IESG review takes into account responses to the Last-Call and
+   will lead to one of these possible conclusions:
+
+
+
+
+
+Bradner                  Best Current Practice                 [Page 21]
+
+RFC 2418                Working Group Guidelines          September 1998
+
+
+   1. The document is accepted as is for the status requested.
+      This fact will be announced by the IETF Secretariat to the IETF
+      mailing list and to the RFC Editor.
+
+   2. The document is accepted as-is but not for the status requested.
+      This fact will be announced by the IETF Secretariat to the IETF
+      mailing list and to the RFC Editor (see [1] for more details).
+
+   3. Changes regarding content are suggested to the author(s)/WG.
+      Suggestions from the IESG must be clear and direct, so as to
+      facilitate working group and author correction of the
+      specification.  If the author(s)/WG can explain to the
+      satisfaction of the IESG why the changes are not necessary, the
+      document will be accepted for publication as under point 1, above.
+      If the changes are made the revised document may be resubmitted
+      for IESG review.
+
+   4. Changes are suggested by the IESG and a change in status is
+      recommended.
+      The process described above for 3 and 2 are followed in that
+      order.
+
+   5. The document is rejected.
+      Any document rejection will be accompanied by specific and
+      thorough arguments from the IESG. Although the IETF and working
+      group process is structured such that this alternative is not
+      likely to arise for documents coming from a working group, the
+      IESG has the right and responsibility to reject documents that the
+      IESG feels are fatally flawed in some way.
+
+      If any individual or group of individuals feels that the review
+      treatment has been unfair, there is the opportunity to make a
+      procedural complaint. The mechanism for this type of complaints is
+      described in [1].
+
+9. Security Considerations
+
+   Documents describing IETF processes, such as this one, do not have an
+   impact on the security of the network infrastructure or of Internet
+   applications.
+
+   It should be noted that all IETF working groups are required to
+   examine and understand the security implications of any technology
+   they develop.  This analysis must be included in any resulting RFCs
+   in a Security Considerations section.  Note that merely noting a
+   significant security hole is no longer sufficient.  IETF developed
+   technologies should not add insecurity to the environment in which
+   they are run.
+
+
+
+Bradner                  Best Current Practice                 [Page 22]
+
+RFC 2418                Working Group Guidelines          September 1998
+
+
+10. Acknowledgments
+
+   This revision of this document relies heavily on the previous version
+   (RFC 1603) which was edited by Erik Huizer and Dave Crocker.  It has
+   been reviewed by the Poisson Working Group.
+
+11. References
+
+   [1] Bradner, S., Editor, "The Internet Standards Process -- Revision
+       3", BCP 9, RFC 2026, October 1996.
+
+   [2] Hovey, R., and S. Bradner, "The Organizations involved in the
+       IETF Standards Process", BCP 11, RFC 2028, October 1996.
+
+   [3] Gavin, J., "IAB and IESG Selection, Confirmation, and Recall
+       Process: Operation of the Nominating and Recall Committees", BCP
+       10, RFC 2282, February 1998.
+
+   [4] Huitema, C., J. Postel, S. Crocker, "Not all RFCs are Standards",
+       RFC 1796, April 1995.
+
+   [5] Postel, J., and J. Reynolds, "Instructions to RFC Authors", RFC
+       2223, October 1997.
+
+   [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+       Level", BCP 14, RFC 2119, March 1997.
+
+
+12. Editor's Address
+
+   Scott Bradner
+   Harvard University
+   1350 Mass Ave.
+   Cambridge MA
+   02138
+   USA
+
+   Phone +1 617 495 3864
+   EMail: sob@harvard.edu
+
+
+
+
+
+
+
+
+
+
+
+
+Bradner                  Best Current Practice                 [Page 23]
+
+RFC 2418                Working Group Guidelines          September 1998
+
+
+   Appendix:  Sample Working Group Charter
+
+   Working Group Name:
+        IP Telephony (iptel)
+
+   IETF Area:
+        Transport Area
+
+   Chair(s):
+        Jonathan Rosenberg <jdrosen@bell-labs.com>
+
+   Transport Area Director(s):
+        Scott Bradner <sob@harvard.edu>
+        Allyn Romanow <allyn@mci.net>
+
+   Responsible Area Director:
+        Allyn Romanow <allyn@mci.net>
+
+   Mailing Lists:
+        General Discussion:iptel@lists.research.bell-labs.com
+        To Subscribe: iptel-request@lists.research.bell-labs.com
+        Archive: http://www.bell-labs.com/mailing-lists/siptel
+
+   Description of Working Group:
+
+   Before Internet telephony can become a widely deployed service, a
+   number of protocols must be deployed. These include signaling and
+   capabilities exchange, but also include a number of "peripheral"
+   protocols for providing related services.
+
+   The primary purpose of this working group is to develop two such
+   supportive protocols and a frameword document. They are:
+
+   1. Call Processing Syntax. When a call is setup between two
+   endpoints, the signaling will generally pass through several servers
+   (such as an H.323 gatekeeper) which are responsible for forwarding,
+   redirecting, or proxying the signaling messages. For example, a user
+   may make a call to j.doe@bigcompany.com. The signaling message to
+   initiate the call will arrive at some server at bigcompany. This
+   server can inform the caller that the callee is busy, forward the
+   call initiation request to another server closer to the user, or drop
+   the call completely (among other possibilities). It is very desirable
+   to allow the callee to provide input to this process, guiding the
+   server in its decision on how to act. This can enable a wide variety
+   of advanced personal mobility and call agent services.
+
+
+
+
+
+
+Bradner                  Best Current Practice                 [Page 24]
+
+RFC 2418                Working Group Guidelines          September 1998
+
+
+   Such preferences can be expressed in a call processing syntax, which
+   can be authored by the user (or generated automatically by some
+   tool), and then uploaded to the server. The group will develop this
+   syntax, and specify means of securely transporting and extending it.
+   The result will be a single standards track RFC.
+
+   2. In addition, the group will write a service model document, which
+   describes the services that are enabled by the call processing
+   syntax, and discusses how the syntax can be used. This document will
+   result in a single RFC.
+
+   3. Gateway Attribute Distribution Protocol. When making a call
+   between an IP host and a PSTN user, a telephony gateway must be used.
+   The selection of such gateways can be based on many criteria,
+   including client expressed preferences, service provider preferences,
+   and availability of gateways, in addition to destination telephone
+   number.  Since gateways outside of the hosts' administrative domain
+   might be used, a protocol is required to allow gateways in remote
+   domains to distribute their attributes (such as PSTN connectivity,
+   supported codecs, etc.) to entities in other domains which must make
+   a selection of a gateway. The protocol must allow for scalable,
+   bandwidth efficient, and very secure transmission of these
+   attributes. The group will investigate and design a protocol for this
+   purpose, generate an Internet Draft, and advance it to RFC as
+   appropriate.
+
+   Goals and Milestones:
+
+   May 98    Issue first Internet-Draft on service framework
+   Jul 98    Submit framework ID to IESG for publication as an RFC.
+   Aug 98    Issue first Internet-Draft on Call Processing Syntax
+   Oct 98    Submit Call processing syntax to IESG for consideration
+             as a Proposed Standard.
+   Dec 98    Achieve consensus on basics of gateway attribute
+             distribution protocol
+   Jan 99    Submit Gateway Attribute Distribution protocol to IESG
+             for consideration as a RFC (info, exp, stds track TB
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bradner                  Best Current Practice                 [Page 25]
+
+RFC 2418                Working Group Guidelines          September 1998
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (1998).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bradner                  Best Current Practice                 [Page 26]
+
diff --git a/doc/rfc/rfc2535.txt b/doc/rfc/rfc2535.txt
new file mode 100644
index 0000000..fe0b3d0
--- /dev/null
+++ b/doc/rfc/rfc2535.txt
@@ -0,0 +1,2635 @@
+
+
+
+
+
+
+Network Working Group                                         D. Eastlake
+Request for Comments: 2535                                            IBM
+Obsoletes: 2065                                                March 1999
+Updates: 2181, 1035, 1034
+Category: Standards Track
+
+                 Domain Name System Security Extensions
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1999).  All Rights Reserved.
+
+Abstract
+
+   Extensions to the Domain Name System (DNS) are described that provide
+   data integrity and authentication to security aware resolvers and
+   applications through the use of cryptographic digital signatures.
+   These digital signatures are included in secured zones as resource
+   records.  Security can also be provided through non-security aware
+   DNS servers in some cases.
+
+   The extensions provide for the storage of authenticated public keys
+   in the DNS.  This storage of keys can support general public key
+   distribution services as well as DNS security.  The stored keys
+   enable security aware resolvers to learn the authenticating key of
+   zones in addition to those for which they are initially configured.
+   Keys associated with DNS names can be retrieved to support other
+   protocols.  Provision is made for a variety of key types and
+   algorithms.
+
+   In addition, the security extensions provide for the optional
+   authentication of DNS protocol transactions and requests.
+
+   This document incorporates feedback on RFC 2065 from early
+   implementers and potential users.
+
+
+
+
+
+
+
+
+Eastlake                    Standards Track                     [Page 1]
+
+RFC 2535                DNS Security Extensions               March 1999
+
+
+Acknowledgments
+
+   The significant contributions and suggestions of the following
+   persons (in alphabetic order) to DNS security are gratefully
+   acknowledged:
+
+      James M. Galvin
+      John Gilmore
+      Olafur Gudmundsson
+      Charlie Kaufman
+      Edward Lewis
+      Thomas Narten
+      Radia J. Perlman
+      Jeffrey I. Schiller
+      Steven (Xunhua) Wang
+      Brian Wellington
+
+Table of Contents
+
+   Abstract...................................................1
+   Acknowledgments............................................2
+   1. Overview of Contents....................................4
+   2. Overview of the DNS Extensions..........................5
+   2.1 Services Not Provided..................................5
+   2.2 Key Distribution.......................................5
+   2.3 Data Origin Authentication and Integrity...............6
+   2.3.1 The SIG Resource Record..............................7
+   2.3.2 Authenticating Name and Type Non-existence...........7
+   2.3.3 Special Considerations With Time-to-Live.............7
+   2.3.4 Special Considerations at Delegation Points..........8
+   2.3.5 Special Considerations with CNAME....................8
+   2.3.6 Signers Other Than The Zone..........................9
+   2.4 DNS Transaction and Request Authentication.............9
+   3. The KEY Resource Record................................10
+   3.1 KEY RDATA format......................................10
+   3.1.1 Object Types, DNS Names, and Keys...................11
+   3.1.2 The KEY RR Flag Field...............................11
+   3.1.3 The Protocol Octet..................................13
+   3.2 The KEY Algorithm Number Specification................14
+   3.3 Interaction of Flags, Algorithm, and Protocol Bytes...15
+   3.4 Determination of Zone Secure/Unsecured Status.........15
+   3.5 KEY RRs in the Construction of Responses..............17
+   4. The SIG Resource Record................................17
+   4.1 SIG RDATA Format......................................17
+   4.1.1 Type Covered Field..................................18
+   4.1.2 Algorithm Number Field..............................18
+   4.1.3 Labels Field........................................18
+   4.1.4 Original TTL Field..................................19
+
+
+
+Eastlake                    Standards Track                     [Page 2]
+
+RFC 2535                DNS Security Extensions               March 1999
+
+
+   4.1.5 Signature Expiration and Inception Fields...........19
+   4.1.6 Key Tag Field.......................................20
+   4.1.7 Signer's Name Field.................................20
+   4.1.8 Signature Field.....................................20
+   4.1.8.1 Calculating Transaction and Request SIGs..........21
+   4.2 SIG RRs in the Construction of Responses..............21
+   4.3 Processing Responses and SIG RRs......................22
+   4.4 Signature Lifetime, Expiration, TTLs, and Validity....23
+   5. Non-existent Names and Types...........................24
+   5.1 The NXT Resource Record...............................24
+   5.2 NXT RDATA Format......................................25
+   5.3 Additional Complexity Due to Wildcards................26
+   5.4 Example...............................................26
+   5.5 Special Considerations at Delegation Points...........27
+   5.6 Zone Transfers........................................27
+   5.6.1 Full Zone Transfers.................................28
+   5.6.2 Incremental Zone Transfers..........................28
+   6. How to Resolve Securely and the AD and CD Bits.........29
+   6.1 The AD and CD Header Bits.............................29
+   6.2 Staticly Configured Keys..............................31
+   6.3 Chaining Through The DNS..............................31
+   6.3.1 Chaining Through KEYs...............................31
+   6.3.2 Conflicting Data....................................33
+   6.4 Secure Time...........................................33
+   7. ASCII Representation of Security RRs...................34
+   7.1 Presentation of KEY RRs...............................34
+   7.2 Presentation of SIG RRs...............................35
+   7.3 Presentation of NXT RRs...............................36
+   8. Canonical Form and Order of Resource Records...........36
+   8.1 Canonical RR Form.....................................36
+   8.2 Canonical DNS Name Order..............................37
+   8.3 Canonical RR Ordering Within An RRset.................37
+   8.4 Canonical Ordering of RR Types........................37
+   9. Conformance............................................37
+   9.1 Server Conformance....................................37
+   9.2 Resolver Conformance..................................38
+   10. Security Considerations...............................38
+   11. IANA Considerations...................................39
+   References................................................39
+   Author's Address..........................................41
+   Appendix A: Base 64 Encoding..............................42
+   Appendix B: Changes from RFC 2065.........................44
+   Appendix C: Key Tag Calculation...........................46
+   Full Copyright Statement..................................47
+
+
+
+
+
+
+
+Eastlake                    Standards Track                     [Page 3]
+
+RFC 2535                DNS Security Extensions               March 1999
+
+
+1. Overview of Contents
+
+   This document standardizes extensions of the Domain Name System (DNS)
+   protocol to support DNS security and public key distribution. It
+   assumes that the reader is familiar with the Domain Name System,
+   particularly as described in RFCs 1033, 1034, 1035 and later RFCs. An
+   earlier version of these extensions appears in RFC 2065.  This
+   replacement for that RFC incorporates early implementation experience
+   and requests from  potential users.
+
+   Section 2 provides an overview of the extensions and the key
+   distribution, data origin authentication, and transaction and request
+   security they provide.
+
+   Section 3 discusses the KEY resource record, its structure, and use
+   in DNS responses.  These resource records represent the public keys
+   of entities named in the DNS and are used for key distribution.
+
+   Section 4 discusses the SIG digital signature resource record, its
+   structure, and use in DNS responses.  These resource records are used
+   to authenticate other resource records in the DNS and optionally to
+   authenticate DNS transactions and requests.
+
+   Section 5 discusses the NXT resource record (RR) and its use in DNS
+   responses including full and incremental zone transfers.  The NXT RR
+   permits authenticated denial of the existence of a name or of an RR
+   type for an existing name.
+
+   Section 6 discusses how a resolver can be configured with a starting
+   key or keys and proceed to securely resolve DNS requests.
+   Interactions between resolvers and servers are discussed for various
+   combinations of security aware and security non-aware.  Two
+   additional DNS header bits are defined for signaling between
+   resolvers and servers.
+
+   Section 7 describes the ASCII representation of the security resource
+   records for use in master files and elsewhere.
+
+   Section 8 defines the canonical form and order of RRs for DNS
+   security purposes.
+
+   Section 9 defines levels of conformance for resolvers and servers.
+
+   Section 10 provides a few paragraphs on overall security
+   considerations.
+
+   Section 11 specified IANA considerations for allocation of additional
+   values of paramters defined in this document.
+
+
+
+Eastlake                    Standards Track                     [Page 4]
+
+RFC 2535                DNS Security Extensions               March 1999
+
+
+   Appendix A gives details of base 64 encoding which is used in the
+   file representation of some RRs defined in this document.
+
+   Appendix B summarizes changes between this memo and RFC 2065.
+
+   Appendix C specified how to calculate the simple checksum used as a
+   key tag in most SIG RRs.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+2. Overview of the DNS Extensions
+
+   The Domain Name System (DNS) protocol security extensions provide
+   three distinct services: key distribution as described in Section 2.2
+   below, data origin authentication as described in Section 2.3 below,
+   and transaction and request authentication, described in Section 2.4
+   below.
+
+   Special considerations related to "time to live", CNAMEs, and
+   delegation points are also discussed in Section 2.3.
+
+2.1 Services Not Provided
+
+   It is part of the design philosophy of the DNS that the data in it is
+   public and that the DNS gives the same answers to all inquirers.
+   Following this philosophy, no attempt has been made to include any
+   sort of access control lists or other means to differentiate
+   inquirers.
+
+   No effort has been made to provide for any confidentiality for
+   queries or responses.  (This service may be available via IPSEC [RFC
+   2401], TLS, or other security protocols.)
+
+   Protection is not provided against denial of service.
+
+2.2 Key Distribution
+
+   A resource record format is defined to associate keys with DNS names.
+   This permits the DNS to be used as a public key distribution
+   mechanism in support of DNS security itself and other protocols.
+
+   The syntax of a KEY resource record (RR) is described in Section 3.
+   It includes an algorithm identifier, the actual public key
+   parameter(s), and a variety of flags including those indicating the
+   type of entity the key is associated with and/or asserting that there
+   is no key associated with that entity.
+
+
+
+Eastlake                    Standards Track                     [Page 5]
+
+RFC 2535                DNS Security Extensions               March 1999
+
+
+   Under conditions described in Section 3.5, security aware DNS servers
+   will automatically attempt to return KEY resources as additional
+   information, along with those resource records actually requested, to
+   minimize the number of queries needed.
+
+2.3 Data Origin Authentication and Integrity
+
+   Authentication is provided by associating with resource record sets
+   (RRsets [RFC 2181]) in the DNS cryptographically generated digital
+   signatures. Commonly, there will be a single private key that
+   authenticates an entire zone but there might be multiple keys for
+   different algorithms, signers, etc. If a security aware resolver
+   reliably learns a public key of the zone, it can authenticate, for
+   signed data read from that zone, that it is properly authorized.  The
+   most secure implementation is for the zone private key(s) to be kept
+   off-line and used to re-sign all of the records in the zone
+   periodically.  However, there are cases, for example dynamic update
+   [RFCs 2136, 2137], where DNS private keys need to be on-line [RFC
+   2541].
+
+   The data origin authentication key(s) are associated with the zone
+   and not with the servers that store copies of the data.  That means
+   compromise of a secondary server or, if the key(s) are kept off line,
+   even the primary server for a zone, will not necessarily affect the
+   degree of assurance that a resolver has that it can determine whether
+   data is genuine.
+
+   A resolver could learn a public key of a zone either by reading it
+   from the DNS or by having it staticly configured.  To reliably learn
+   a public key by reading it from the DNS, the key itself must be
+   signed with a key the resolver trusts. The resolver must be
+   configured with at least a public key which authenticates one zone as
+   a starting point. From there, it can securely read public keys of
+   other zones, if the intervening zones in the DNS tree are secure and
+   their signed keys accessible.
+
+   Adding data origin authentication and integrity requires no change to
+   the "on-the-wire" DNS protocol beyond the addition of the signature
+   resource type and the key resource type needed for key distribution.
+   (Data non-existence authentication also requires the NXT RR as
+   described in 2.3.2.)  This service can be supported by existing
+   resolver and caching server implementations so long as they can
+   support the additional resource types (see Section 9). The one
+   exception is that CNAME referrals in a secure zone can not be
+   authenticated if they are from non-security aware servers (see
+   Section 2.3.5).
+
+
+
+
+
+Eastlake                    Standards Track                     [Page 6]
+
+RFC 2535                DNS Security Extensions               March 1999
+
+
+   If signatures are separately retrieved and verified when retrieving
+   the information they authenticate, there will be more trips to the
+   server and performance will suffer.  Security aware servers mitigate
+   that degradation by attempting to send the signature(s) needed (see
+   Section 4.2).
+
+2.3.1 The SIG Resource Record
+
+   The syntax of a SIG resource record (signature) is described in
+   Section 4.  It cryptographicly binds the RRset being signed to the
+   signer and a validity interval.
+
+   Every name in a secured zone will have associated with it at least
+   one SIG resource record for each resource type under that name except
+   for glue address RRs and delegation point NS RRs.  A security aware
+   server will attempt to return, with RRs retrieved, the corresponding
+   SIGs.  If a server is not security aware, the resolver must retrieve
+   all the SIG records for a name and select the one or ones that sign
+   the resource record set(s) that resolver is interested in.
+
+2.3.2 Authenticating Name and Type Non-existence
+
+   The above security mechanism only provides a way to sign existing
+   RRsets in a zone.  "Data origin" authentication is not obviously
+   provided for the non-existence of a domain name in a zone or the
+   non-existence of a type for an existing name.  This gap is filled by
+   the NXT RR which authenticatably asserts a range of non-existent
+   names in a zone and the non-existence of types for the existing name
+   just before that range.
+
+   Section 5 below covers the NXT RR.
+
+2.3.3 Special Considerations With Time-to-Live
+
+   A digital signature will fail to verify if any change has occurred to
+   the data between the time it was originally signed and the time the
+   signature is verified.  This conflicts with our desire to have the
+   time-to-live (TTL) field of resource records tick down while they are
+   cached.
+
+   This could be avoided by leaving the time-to-live out of the digital
+   signature, but that would allow unscrupulous servers to set
+   arbitrarily long TTL values undetected.  Instead, we include the
+   "original" TTL in the signature and communicate that data along with
+   the current TTL. Unscrupulous servers under this scheme can
+   manipulate the TTL but a security aware resolver will bound the TTL
+   value it uses at the original signed value.  Separately, signatures
+   include a signature inception time and a signature expiration time. A
+
+
+
+Eastlake                    Standards Track                     [Page 7]
+
+RFC 2535                DNS Security Extensions               March 1999
+
+
+   resolver that knows the absolute time can determine securely whether
+   a signature is in effect.  It is not possible to rely solely on the
+   signature expiration as a substitute for the TTL, however, since the
+   TTL is primarily a database consistency mechanism and non-security
+   aware servers that depend on TTL must still be supported.
+
+2.3.4 Special Considerations at Delegation Points
+
+   DNS security would like to view each zone as a unit of data
+   completely under the control of the zone owner with each entry
+   (RRset) signed by a special private key held by the zone manager.
+   But the DNS protocol views the leaf nodes in a zone, which are also
+   the apex nodes of a subzone (i.e., delegation points), as "really"
+   belonging to the subzone.  These nodes occur in two master files and
+   might have RRs signed by both the upper and lower zone's keys. A
+   retrieval could get a mixture of these RRs and SIGs, especially since
+   one server could be serving both the zone above and below a
+   delegation point. [RFC 2181]
+
+   There MUST be a zone KEY RR, signed by its superzone, for every
+   subzone if the superzone is secure. This will normally appear in the
+   subzone and may also be included in the superzone.  But, in the case
+   of an unsecured subzone which can not or will not be modified to add
+   any security RRs, a KEY declaring the subzone to be unsecured MUST
+   appear with the superzone signature in the superzone, if the
+   superzone is secure. For all but one other RR type the data from the
+   subzone is more authoritative so only the subzone KEY RR should be
+   signed in the superzone if it appears there. The NS and any glue
+   address RRs SHOULD only be signed in the subzone. The SOA and any
+   other RRs that have the zone name as owner should appear only in the
+   subzone and thus are signed only there. The NXT RR type is the
+   exceptional case that will always appear differently and
+   authoritatively in both the superzone and subzone, if both are
+   secure, as described in Section 5.
+
+2.3.5 Special Considerations with CNAME
+
+   There is a problem when security related RRs with the same owner name
+   as a CNAME RR are retrieved from a non-security-aware server. In
+   particular, an initial retrieval for the CNAME or any other type may
+   not retrieve any associated SIG, KEY, or NXT RR. For retrieved types
+   other than CNAME, it will retrieve that type at the target name of
+   the CNAME (or chain of CNAMEs) and will also return the CNAME.  In
+   particular, a specific retrieval for type SIG will not get the SIG,
+   if any, at the original CNAME domain name but rather a SIG at the
+   target name.
+
+
+
+
+
+Eastlake                    Standards Track                     [Page 8]
+
+RFC 2535                DNS Security Extensions               March 1999
+
+
+   Security aware servers must be used to securely CNAME in DNS.
+   Security aware servers MUST (1) allow KEY, SIG, and NXT RRs along
+   with CNAME RRs, (2) suppress CNAME processing on retrieval of these
+   types as well as on retrieval of the type CNAME, and (3)
+   automatically return SIG RRs authenticating the CNAME or CNAMEs
+   encountered in resolving a query.  This is a change from the previous
+   DNS standard [RFCs 1034/1035] which prohibited any other RR type at a
+   node where a CNAME RR was present.
+
+2.3.6 Signers Other Than The Zone
+
+   There are cases where the signer in a SIG resource record is other
+   than one of the private key(s) used to authenticate a zone.
+
+   One is for support of dynamic update [RFC 2136] (or future requests
+   which require secure authentication) where an entity is permitted to
+   authenticate/update its records [RFC 2137] and the zone is operating
+   in a mode where the zone key is not on line. The public key of the
+   entity must be present in the DNS and be signed by a zone level key
+   but the other RR(s) may be signed with the entity's key.
+
+   A second case is support of transaction and request authentication as
+   described in Section 2.4.
+
+   In additions, signatures can be included on resource records within
+   the DNS for use by applications other than DNS. DNS related
+   signatures authenticate that data originated with the authority of a
+   zone owner or that a request or transaction originated with the
+   relevant entity. Other signatures can provide other types of
+   assurances.
+
+2.4 DNS Transaction and Request Authentication
+
+   The data origin authentication service described above protects
+   retrieved resource records and the non-existence of resource records
+   but provides no protection for DNS requests or for message headers.
+
+   If header bits are falsely set by a bad server, there is little that
+   can be done.  However, it is possible to add transaction
+   authentication.  Such authentication means that a resolver can be
+   sure it is at least getting messages from the server it thinks it
+   queried and that the response is from the query it sent (i.e., that
+   these messages have not been diddled in transit).  This is
+   accomplished by optionally adding a special SIG resource record at
+   the end of the reply which digitally signs the concatenation of the
+   server's response and the resolver's query.
+
+
+
+
+
+Eastlake                    Standards Track                     [Page 9]
+
+RFC 2535                DNS Security Extensions               March 1999
+
+
+   Requests can also be authenticated by including a special SIG RR at
+   the end of the request.  Authenticating requests serves no function
+   in older DNS servers and requests with a non-empty additional
+   information section produce error returns or may even be ignored by
+   many of them. However, this syntax for signing requests is defined as
+   a way of authenticating secure dynamic update requests [RFC 2137] or
+   future requests requiring authentication.
+
+   The private keys used in transaction security belong to the entity
+   composing the reply, not to the zone involved.  Request
+   authentication may also involve the private key of the host or other
+   entity composing the request or other private keys depending on the
+   request authority it is sought to establish. The corresponding public
+   key(s) are normally stored in and retrieved from the DNS for
+   verification.
+
+   Because requests and replies are highly variable, message
+   authentication SIGs can not be pre-calculated.  Thus it will be
+   necessary to keep the private key on-line, for example in software or
+   in a directly connected piece of hardware.
+
+3. The KEY Resource Record
+
+   The KEY resource record (RR) is used to store a public key that is
+   associated with a Domain Name System (DNS) name.  This can be the
+   public key of a zone, a user, or a host or other end entity. Security
+   aware DNS implementations MUST be designed to handle at least two
+   simultaneously valid keys of the same type associated with the same
+   name.
+
+   The type number for the KEY RR is 25.
+
+   A KEY RR is, like any other RR, authenticated by a SIG RR.  KEY RRs
+   must be signed by a zone level key.
+
+3.1 KEY RDATA format
+
+   The RDATA for a KEY RR consists of flags, a protocol octet, the
+   algorithm number octet, and the public key itself.  The format is as
+   follows:
+
+
+
+
+
+
+
+
+
+
+
+Eastlake                    Standards Track                    [Page 10]
+
+RFC 2535                DNS Security Extensions               March 1999
+
+
+                        1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |             flags             |    protocol   |   algorithm   |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                                                               /
+   /                          public key                           /
+   /                                                               /
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
+
+   The KEY RR is not intended for storage of certificates and a separate
+   certificate RR has been developed for that purpose, defined in [RFC
+   2538].
+
+   The meaning of the KEY RR owner name, flags, and protocol octet are
+   described in Sections 3.1.1 through 3.1.5 below.  The flags and
+   algorithm must be examined before any data following the algorithm
+   octet as they control the existence and format of any following data.
+   The algorithm and public key fields are described in Section 3.2.
+   The format of the public key is algorithm dependent.
+
+   KEY RRs do not specify their validity period but their authenticating
+   SIG RR(s) do as described in Section 4 below.
+
+3.1.1 Object Types, DNS Names, and Keys
+
+   The public key in a KEY RR is for the object named in the owner name.
+
+   A DNS name may refer to three different categories of things.  For
+   example, foo.host.example could be (1) a zone, (2) a host or other
+   end entity , or (3) the mapping into a DNS name of the user or
+   account foo@host.example.  Thus, there are flag bits, as described
+   below, in the KEY RR to indicate with which of these roles the owner
+   name and public key are associated.  Note that an appropriate zone
+   KEY RR MUST occur at the apex node of a secure zone and zone KEY RRs
+   occur only at delegation points.
+
+3.1.2 The KEY RR Flag Field
+
+   In the "flags" field:
+
+     0   1   2   3   4   5   6   7   8   9   0   1   2   3   4   5
+   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+   |  A/C  | Z | XT| Z | Z | NAMTYP| Z | Z | Z | Z |      SIG      |
+   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+
+   Bit 0 and 1 are the key "type" bits whose values have the following
+   meanings:
+
+
+
+Eastlake                    Standards Track                    [Page 11]
+
+RFC 2535                DNS Security Extensions               March 1999
+
+
+           10: Use of the key is prohibited for authentication.
+           01: Use of the key is prohibited for confidentiality.
+           00: Use of the key for authentication and/or confidentiality
+               is permitted. Note that DNS security makes use of keys
+               for authentication only. Confidentiality use flagging is
+               provided for use of keys in other protocols.
+               Implementations not intended to support key distribution
+               for confidentiality MAY require that the confidentiality
+               use prohibited bit be on for keys they serve.
+           11: If both bits are one, the "no key" value, there is no key
+               information and the RR stops after the algorithm octet.
+               By the use of this "no key" value, a signed KEY RR can
+               authenticatably assert that, for example, a zone is not
+               secured.  See section 3.4 below.
+
+   Bits 2 is reserved and must be zero.
+
+   Bits 3 is reserved as a flag extension bit.  If it is a one, a second
+          16 bit flag field is added after the algorithm octet and
+          before the key data.  This bit MUST NOT be set unless one or
+          more such additional bits have been defined and are non-zero.
+
+   Bits 4-5 are reserved and must be zero.
+
+   Bits 6 and 7 form a field that encodes the name type. Field values
+   have the following meanings:
+
+           00: indicates that this is a key associated with a "user" or
+               "account" at an end entity, usually a host.  The coding
+               of the owner name is that used for the responsible
+               individual mailbox in the SOA and RP RRs: The owner name
+               is the user name as the name of a node under the entity
+               name.  For example, "j_random_user" on
+               host.subdomain.example could have a public key associated
+               through a KEY RR with name
+               j_random_user.host.subdomain.example.  It could be used
+               in a security protocol where authentication of a user was
+               desired.  This key might be useful in IP or other
+               security for a user level service such a telnet, ftp,
+               rlogin, etc.
+           01: indicates that this is a zone key for the zone whose name
+               is the KEY RR owner name.  This is the public key used
+               for the primary DNS security feature of data origin
+               authentication.  Zone KEY RRs occur only at delegation
+               points.
+           10: indicates that this is a key associated with the non-zone
+               "entity" whose name is the RR owner name.  This will
+               commonly be a host but could, in some parts of the DNS
+
+
+
+Eastlake                    Standards Track                    [Page 12]
+
+RFC 2535                DNS Security Extensions               March 1999
+
+
+               tree, be some other type of entity such as a telephone
+               number [RFC 1530] or numeric IP address.  This is the
+               public key used in connection with DNS request and
+               transaction authentication services.  It could also be
+               used in an IP-security protocol where authentication at
+               the host, rather than user, level was desired, such as
+               routing, NTP, etc.
+           11: reserved.
+
+   Bits 8-11 are reserved and must be zero.
+
+   Bits 12-15 are the "signatory" field.  If non-zero, they indicate
+              that the key can validly sign things as specified in DNS
+              dynamic update [RFC 2137].  Note that zone keys (see bits
+              6 and 7 above) always have authority to sign any RRs in
+              the zone regardless of the value of the signatory field.
+
+3.1.3 The Protocol Octet
+
+   It is anticipated that keys stored in DNS will be used in conjunction
+   with a variety of Internet protocols.  It is intended that the
+   protocol octet and possibly some of the currently unused (must be
+   zero) bits in the KEY RR flags as specified in the future will be
+   used to indicate a key's validity for different protocols.
+
+   The following values of the Protocol Octet are reserved as indicated:
+
+        VALUE   Protocol
+
+          0      -reserved
+          1     TLS
+          2     email
+          3     dnssec
+          4     IPSEC
+         5-254   - available for assignment by IANA
+        255     All
+
+   In more detail:
+        1 is reserved for use in connection with TLS.
+        2 is reserved for use in connection with email.
+        3 is used for DNS security.  The protocol field SHOULD be set to
+          this value for zone keys and other keys used in DNS security.
+          Implementations that can determine that a key is a DNS
+          security key by the fact that flags label it a zone key or the
+          signatory flag field is non-zero are NOT REQUIRED to check the
+          protocol field.
+        4 is reserved to refer to the Oakley/IPSEC [RFC 2401] protocol
+          and indicates that this key is valid for use in conjunction
+
+
+
+Eastlake                    Standards Track                    [Page 13]
+
+RFC 2535                DNS Security Extensions               March 1999
+
+
+          with that security standard.  This key could be used in
+          connection with secured communication on behalf of an end
+          entity or user whose name is the owner name of the KEY RR if
+          the entity or user flag bits are set.  The presence of a KEY
+          resource with this protocol value is an assertion that the
+          host speaks Oakley/IPSEC.
+        255 indicates that the key can be used in connection with any
+          protocol for which KEY RR protocol octet values have been
+          defined.  The use of this value is discouraged and the use of
+          different keys for different protocols is encouraged.
+
+3.2 The KEY Algorithm Number Specification
+
+   This octet is the key algorithm parallel to the same field for the
+   SIG resource as described in Section 4.1.  The following values are
+   assigned:
+
+   VALUE   Algorithm
+
+     0      - reserved, see Section 11
+     1     RSA/MD5 [RFC 2537] - recommended
+     2     Diffie-Hellman [RFC 2539] - optional, key only
+     3     DSA [RFC 2536] - MANDATORY
+     4     reserved for elliptic curve crypto
+   5-251    - available, see Section 11
+   252     reserved for indirect keys
+   253     private - domain name (see below)
+   254     private - OID (see below)
+   255      - reserved, see Section 11
+
+   Algorithm specific formats and procedures are given in separate
+   documents.  The mandatory to implement for interoperability algorithm
+   is number 3, DSA.  It is recommended that the RSA/MD5 algorithm,
+   number 1, also be implemented.  Algorithm 2 is used to indicate
+   Diffie-Hellman keys and algorithm 4 is reserved for elliptic curve.
+
+   Algorithm number 252 indicates an indirect key format where the
+   actual key material is elsewhere.  This format is to be defined in a
+   separate document.
+
+   Algorithm numbers 253 and 254 are reserved for private use and will
+   never be assigned a specific algorithm.  For number 253, the public
+   key area and the signature begin with a wire encoded domain name.
+   Only local domain name compression is permitted.  The domain name
+   indicates the private algorithm to use and the remainder of the
+   public key area is whatever is required by that algorithm.  For
+   number 254, the public key area for the KEY RR and the signature
+   begin with an unsigned length byte followed by a BER encoded Object
+
+
+
+Eastlake                    Standards Track                    [Page 14]
+
+RFC 2535                DNS Security Extensions               March 1999
+
+
+   Identifier (ISO OID) of that length.  The OID indicates the private
+   algorithm in use and the remainder of the area is whatever is
+   required by that algorithm.  Entities should only use domain names
+   and OIDs they control to designate their private algorithms.
+
+   Values 0 and 255 are reserved but the value 0 is used in the
+   algorithm field when that field is not used.  An example is in a KEY
+   RR with the top two flag bits on, the "no-key" value, where no key is
+   present.
+
+3.3 Interaction of Flags, Algorithm, and Protocol Bytes
+
+   Various combinations of the no-key type flags, algorithm byte,
+   protocol byte, and any future assigned protocol indicating flags are
+   possible.  The meaning of these combinations is indicated below:
+
+   NK = no key type (flags bits 0 and 1 on)
+   AL = algorithm byte
+   PR = protocols indicated by protocol byte or future assigned flags
+
+   x represents any valid non-zero value(s).
+
+    AL  PR   NK  Meaning
+     0   0   0   Illegal, claims key but has bad algorithm field.
+     0   0   1   Specifies total lack of security for owner zone.
+     0   x   0   Illegal, claims key but has bad algorithm field.
+     0   x   1   Specified protocols unsecured, others may be secure.
+     x   0   0   Gives key but no protocols to use it.
+     x   0   1   Denies key for specific algorithm.
+     x   x   0   Specifies key for protocols.
+     x   x   1   Algorithm not understood for protocol.
+
+3.4 Determination of Zone Secure/Unsecured Status
+
+   A zone KEY RR with the "no-key" type field value (both key type flag
+   bits 0 and 1 on) indicates that the zone named is unsecured while a
+   zone KEY RR with a key present indicates that the zone named is
+   secure.  The secured versus unsecured status of a zone may vary with
+   different cryptographic algorithms.  Even for the same algorithm,
+   conflicting zone KEY RRs may be present.
+
+   Zone KEY RRs, like all RRs, are only trusted if they are
+   authenticated by a SIG RR whose signer field is a signer for which
+   the resolver has a public key they trust and where resolver policy
+   permits that signer to sign for the KEY owner name.  Untrusted zone
+   KEY RRs MUST be ignored in determining the security status of the
+   zone.  However, there can be multiple sets of trusted zone KEY RRs
+   for a zone with different algorithms, signers, etc.
+
+
+
+Eastlake                    Standards Track                    [Page 15]
+
+RFC 2535                DNS Security Extensions               March 1999
+
+
+   For any particular algorithm, zones can be (1) secure, indicating
+   that any retrieved RR must be authenticated by a SIG RR or it will be
+   discarded as bogus, (2) unsecured, indicating that SIG RRs are not
+   expected or required for RRs retrieved from the zone, or (3)
+   experimentally secure, which indicates that SIG RRs might or might
+   not be present but must be checked if found.  The status of a zone is
+   determined as follows:
+
+   1. If, for a zone and algorithm, every trusted zone KEY RR for the
+      zone says there is no key for that zone, it is unsecured for that
+      algorithm.
+
+   2. If, there is at least one trusted no-key zone KEY RR and one
+      trusted key specifying zone KEY RR, then that zone is only
+      experimentally secure for the algorithm.  Both authenticated and
+      non-authenticated RRs for it should be accepted by the resolver.
+
+   3. If every trusted zone KEY RR that the zone and algorithm has is
+      key specifying, then it is secure for that algorithm and only
+      authenticated RRs from it will be accepted.
+
+   Examples:
+
+   (1)  A resolver initially trusts only signatures by the superzone of
+   zone Z within the DNS hierarchy.  Thus it will look only at the KEY
+   RRs that are signed by the superzone.  If it finds only no-key KEY
+   RRs, it will assume the zone is not secure.  If it finds only key
+   specifying KEY RRs, it will assume the zone is secure and reject any
+   unsigned responses.  If it finds both, it will assume the zone is
+   experimentally secure
+
+   (2)  A resolver trusts the superzone of zone Z (to which it got
+   securely from its local zone) and a third party, cert-auth.example.
+   When considering data from zone Z, it may be signed by the superzone
+   of Z, by cert-auth.example, by both, or by neither.  The following
+   table indicates whether zone Z will be considered secure,
+   experimentally secure, or unsecured, depending on the signed zone KEY
+   RRs for Z;
+
+                      c e r t - a u t h . e x a m p l e
+
+        KEY RRs|   None    |  NoKeys   |  Mixed   |   Keys   |
+     S       --+-----------+-----------+----------+----------+
+     u  None   | illegal   | unsecured | experim. | secure   |
+     p       --+-----------+-----------+----------+----------+
+     e  NoKeys | unsecured | unsecured | experim. | secure   |
+     r       --+-----------+-----------+----------+----------+
+     Z  Mixed  | experim.  | experim.  | experim. | secure   |
+
+
+
+Eastlake                    Standards Track                    [Page 16]
+
+RFC 2535                DNS Security Extensions               March 1999
+
+
+     o       --+-----------+-----------+----------+----------+
+     n  Keys   | secure    | secure    | secure   | secure   |
+     e         +-----------+-----------+----------+----------+
+
+3.5 KEY RRs in the Construction of Responses
+
+   An explicit request for KEY RRs does not cause any special additional
+   information processing except, of course, for the corresponding SIG
+   RR from a security aware server (see Section 4.2).
+
+   Security aware DNS servers include KEY RRs as additional information
+   in responses, where a KEY is available, in the following cases:
+
+   (1) On the retrieval of SOA or NS RRs, the KEY RRset with the same
+   name (perhaps just a zone key) SHOULD be included as additional
+   information if space is available. If not all additional information
+   will fit, type A and AAAA glue RRs have higher priority than KEY
+   RR(s).
+
+   (2) On retrieval of type A or AAAA RRs, the KEY RRset with the same
+   name (usually just a host RR and NOT the zone key (which usually
+   would have a different name)) SHOULD be included if space is
+   available.  On inclusion of A or AAAA RRs as additional information,
+   the KEY RRset with the same name should also be included but with
+   lower priority than the A or AAAA RRs.
+
+4. The SIG Resource Record
+
+   The SIG or "signature" resource record (RR) is the fundamental way
+   that data is authenticated in the secure Domain Name System (DNS). As
+   such it is the heart of the security provided.
+
+   The SIG RR unforgably authenticates an RRset [RFC 2181] of a
+   particular type, class, and name and binds it to a time interval and
+   the signer's domain name.  This is done using cryptographic
+   techniques and the signer's private key.  The signer is frequently
+   the owner of the zone from which the RR originated.
+
+   The type number for the SIG RR type is 24.
+
+4.1 SIG RDATA Format
+
+   The RDATA portion of a SIG RR is as shown below.  The integrity of
+   the RDATA information is protected by the signature field.
+
+
+
+
+
+
+
+Eastlake                    Standards Track                    [Page 17]
+
+RFC 2535                DNS Security Extensions               March 1999
+
+
+                           1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
+       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |        type covered           |  algorithm    |     labels    |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                         original TTL                          |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                      signature expiration                     |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                      signature inception                      |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |            key  tag           |                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+         signer's name         +
+      |                                                               /
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-/
+      /                                                               /
+      /                            signature                          /
+      /                                                               /
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+4.1.1 Type Covered Field
+
+   The "type covered" is the type of the other RRs covered by this SIG.
+
+4.1.2 Algorithm Number Field
+
+   This octet is as described in section 3.2.
+
+4.1.3 Labels Field
+
+   The "labels" octet is an unsigned count of how many labels there are
+   in the original SIG RR owner name not counting the null label for
+   root and not counting any initial "*" for a wildcard.  If a secured
+   retrieval is the result of wild card substitution, it is necessary
+   for the resolver to use the original form of the name in verifying
+   the digital signature.  This field makes it easy to determine the
+   original form.
+
+   If, on retrieval, the RR appears to have a longer name than indicated
+   by "labels", the resolver can tell it is the result of wildcard
+   substitution.  If the RR owner name appears to be shorter than the
+   labels count, the SIG RR must be considered corrupt and ignored.  The
+   maximum number of labels allowed in the current DNS is 127 but the
+   entire octet is reserved and would be required should DNS names ever
+   be expanded to 255 labels.  The following table gives some examples.
+   The value of "labels" is at the top, the retrieved owner name on the
+   left, and the table entry is the name to use in signature
+   verification except that "bad" means the RR is corrupt.
+
+
+
+Eastlake                    Standards Track                    [Page 18]
+
+RFC 2535                DNS Security Extensions               March 1999
+
+
+   labels= |  0  |   1  |    2   |      3   |      4   |
+   --------+-----+------+--------+----------+----------+
+          .|   . | bad  |  bad   |    bad   |    bad   |
+         d.|  *. |   d. |  bad   |    bad   |    bad   |
+       c.d.|  *. | *.d. |   c.d. |    bad   |    bad   |
+     b.c.d.|  *. | *.d. | *.c.d. |   b.c.d. |    bad   |
+   a.b.c.d.|  *. | *.d. | *.c.d. | *.b.c.d. | a.b.c.d. |
+
+4.1.4 Original TTL Field
+
+   The "original TTL" field is included in the RDATA portion to avoid
+   (1) authentication problems that caching servers would otherwise
+   cause by decrementing the real TTL field and (2) security problems
+   that unscrupulous servers could otherwise cause by manipulating the
+   real TTL field.  This original TTL is protected by the signature
+   while the current TTL field is not.
+
+   NOTE:  The "original TTL" must be restored into the covered RRs when
+   the signature is verified (see Section 8).  This generaly implies
+   that all RRs for a particular type, name, and class, that is, all the
+   RRs in any particular RRset, must have the same TTL to start with.
+
+4.1.5 Signature Expiration and Inception Fields
+
+   The SIG is valid from the "signature inception" time until the
+   "signature expiration" time.  Both are unsigned numbers of seconds
+   since the start of 1 January 1970, GMT, ignoring leap seconds.  (See
+   also Section 4.4.)  Ring arithmetic is used as for DNS SOA serial
+   numbers [RFC 1982] which means that these times can never be more
+   than about 68 years in the past or the future.  This means that these
+   times are ambiguous modulo ~136.09 years.  However there is no
+   security flaw because keys are required to be changed to new random
+   keys by [RFC 2541] at least every five years.  This means that the
+   probability that the same key is in use N*136.09 years later should
+   be the same as the probability that a random guess will work.
+
+   A SIG RR may have an expiration time numerically less than the
+   inception time if the expiration time is near the 32 bit wrap around
+   point and/or the signature is long lived.
+
+   (To prevent misordering of network requests to update a zone
+   dynamically, monotonically increasing "signature inception" times may
+   be necessary.)
+
+   A secure zone must be considered changed for SOA serial number
+   purposes not only when its data is updated but also when new SIG RRs
+   are inserted (ie, the zone or any part of it is re-signed).
+
+
+
+
+Eastlake                    Standards Track                    [Page 19]
+
+RFC 2535                DNS Security Extensions               March 1999
+
+
+4.1.6 Key Tag Field
+
+   The "key Tag" is a two octet quantity that is used to efficiently
+   select between multiple keys which may be applicable and thus check
+   that a public key about to be used for the computationally expensive
+   effort to check the signature is possibly valid.  For algorithm 1
+   (MD5/RSA) as defined in [RFC 2537], it is the next to the bottom two
+   octets of the public key modulus needed to decode the signature
+   field.  That is to say, the most significant 16 of the least
+   significant 24 bits of the modulus in network (big endian) order. For
+   all other algorithms, including private algorithms, it is calculated
+   as a simple checksum of the KEY RR as described in Appendix C.
+
+4.1.7 Signer's Name Field
+
+   The "signer's name" field is the domain name of the signer generating
+   the SIG RR.  This is the owner name of the public KEY RR that can be
+   used to verify the signature.  It is frequently the zone which
+   contained the RRset being authenticated.  Which signers should be
+   authorized to sign what is a significant resolver policy question as
+   discussed in Section 6. The signer's name may be compressed with
+   standard DNS name compression when being transmitted over the
+   network.
+
+4.1.8 Signature Field
+
+   The actual signature portion of the SIG RR binds the other RDATA
+   fields to the RRset of the "type covered" RRs with that owner name
+   and class.  This covered RRset is thereby authenticated.  To
+   accomplish this, a data sequence is constructed as follows:
+
+         data = RDATA | RR(s)...
+
+   where "|" is concatenation,
+
+   RDATA is the wire format of all the RDATA fields in the SIG RR itself
+   (including the canonical form of the signer's name) before but not
+   including the signature, and
+
+   RR(s) is the RRset of the RR(s) of the type covered with the same
+   owner name and class as the SIG RR in canonical form and order as
+   defined in Section 8.
+
+   How this data sequence is processed into the signature is algorithm
+   dependent.  These algorithm dependent formats and procedures are
+   described in separate documents (Section 3.2).
+
+
+
+
+
+Eastlake                    Standards Track                    [Page 20]
+
+RFC 2535                DNS Security Extensions               March 1999
+
+
+   SIGs SHOULD NOT be included in a zone for any "meta-type" such as
+   ANY, AXFR, etc. (but see section 5.6.2 with regard to IXFR).
+
+4.1.8.1 Calculating Transaction and Request SIGs
+
+   A response message from a security aware server may optionally
+   contain a special SIG at the end of the additional information
+   section to authenticate the transaction.
+
+   This SIG has a "type covered" field of zero, which is not a valid RR
+   type.  It is calculated by using a "data" (see Section 4.1.8) of the
+   entire preceding DNS reply message, including DNS header but not the
+   IP header and before the reply RR counts have been adjusted for the
+   inclusion of any transaction SIG, concatenated with the entire DNS
+   query message that produced this response, including the query's DNS
+   header and any request SIGs but not its IP header.  That is
+
+      data = full response (less transaction SIG) | full query
+
+   Verification of the transaction SIG (which is signed by the server
+   host key, not the zone key) by the requesting resolver shows that the
+   query and response were not tampered with in transit, that the
+   response corresponds to the intended query, and that the response
+   comes from the queried server.
+
+   A DNS request may be optionally signed by including one or more SIGs
+   at the end of the query. Such SIGs are identified by having a "type
+   covered" field of zero. They sign the preceding DNS request message
+   including DNS header but not including the IP header or any request
+   SIGs at the end and before the request RR counts have been adjusted
+   for the inclusions of any request SIG(s).
+
+   WARNING: Request SIGs are unnecessary for any currently defined
+   request other than update [RFC 2136, 2137] and will cause some old
+   DNS servers to give an error return or ignore a query.  However, such
+   SIGs may in the future be needed for other requests.
+
+   Except where needed to authenticate an update or similar privileged
+   request, servers are not required to check request SIGs.
+
+4.2 SIG RRs in the Construction of Responses
+
+   Security aware DNS servers SHOULD, for every authenticated RRset the
+   query will return, attempt to send the available SIG RRs which
+   authenticate the requested RRset.  The following rules apply to the
+   inclusion of SIG RRs in responses:
+
+
+
+
+
+Eastlake                    Standards Track                    [Page 21]
+
+RFC 2535                DNS Security Extensions               March 1999
+
+
+     1. when an RRset is placed in a response, its SIG RR has a higher
+        priority for inclusion than additional RRs that may need to be
+        included.  If space does not permit its inclusion, the response
+        MUST be considered truncated except as provided in 2 below.
+
+     2. When a SIG RR is present in the zone for an additional
+        information section RR, the response MUST NOT be considered
+        truncated merely because space does not permit the inclusion of
+        the SIG RR with the additional information.
+
+     3. SIGs to authenticate glue records and NS RRs for subzones at a
+        delegation point are unnecessary and MUST NOT be sent.
+
+     4. If a SIG covers any RR that would be in the answer section of
+        the response, its automatic inclusion MUST be in the answer
+        section.  If it covers an RR that would appear in the authority
+        section, its automatic inclusion MUST be in the authority
+        section.  If it covers an RR that would appear in the additional
+        information section it MUST appear in the additional information
+        section.  This is a change in the existing standard [RFCs 1034,
+        1035] which contemplates only NS and SOA RRs in the authority
+        section.
+
+     5. Optionally, DNS transactions may be authenticated by a SIG RR at
+        the end of the response in the additional information section
+        (Section 4.1.8.1).  Such SIG RRs are signed by the DNS server
+        originating the response.  Although the signer field MUST be a
+        name of the originating server host, the owner name, class, TTL,
+        and original TTL, are meaningless.  The class and TTL fields
+        SHOULD be zero.  To conserve space, the owner name SHOULD be
+        root (a single zero octet).  If transaction authentication is
+        desired, that SIG RR must be considered the highest priority for
+        inclusion.
+
+4.3 Processing Responses and SIG RRs
+
+   The following rules apply to the processing of SIG RRs included in a
+   response:
+
+     1. A security aware resolver that receives a response from a
+        security aware server via a secure communication with the AD bit
+        (see Section 6.1) set, MAY choose to accept the RRs as received
+        without verifying the zone SIG RRs.
+
+     2. In other cases, a security aware resolver SHOULD verify the SIG
+        RRs for the RRs of interest.  This may involve initiating
+        additional queries for SIG or KEY RRs, especially in the case of
+
+
+
+
+Eastlake                    Standards Track                    [Page 22]
+
+RFC 2535                DNS Security Extensions               March 1999
+
+
+        getting a response from a server that does not implement
+        security.  (As explained in 2.3.5 above, it will not be possible
+        to secure CNAMEs being served up by non-secure resolvers.)
+
+        NOTE: Implementers might expect the above SHOULD to be a MUST.
+        However, local policy or the calling application may not require
+        the security services.
+
+     3. If SIG RRs are received in response to a user query explicitly
+        specifying the SIG type, no special processing is required.
+
+   If the message does not pass integrity checks or the SIG does not
+   check against the signed RRs, the SIG RR is invalid and should be
+   ignored.  If all of the SIG RR(s) purporting to authenticate an RRset
+   are invalid, then the RRset is not authenticated.
+
+   If the SIG RR is the last RR in a response in the additional
+   information section and has a type covered of zero, it is a
+   transaction signature of the response and the query that produced the
+   response.  It MAY be optionally checked and the message rejected if
+   the checks fail.  But even if the checks succeed, such a transaction
+   authentication SIG does NOT directly authenticate any RRs in the
+   message.  Only a proper SIG RR signed by the zone or a key tracing
+   its authority to the zone or to static resolver configuration can
+   directly authenticate RRs, depending on resolver policy (see Section
+   6).  If a resolver does not implement transaction and/or request
+   SIGs, it MUST ignore them without error.
+
+   If all checks indicate that the SIG RR is valid then RRs verified by
+   it should be considered authenticated.
+
+4.4 Signature Lifetime, Expiration, TTLs, and Validity
+
+   Security aware servers MUST NOT consider SIG RRs to authenticate
+   anything before their signature inception or after its expiration
+   time (see also Section 6).  Security aware servers MUST NOT consider
+   any RR to be authenticated after all its signatures have expired.
+   When a secure server caches authenticated data, if the TTL would
+   expire at a time further in the future than the authentication
+   expiration time, the server SHOULD trim the TTL in the cache entry
+   not to extent beyond the authentication expiration time.  Within
+   these constraints, servers should continue to follow DNS TTL aging.
+   Thus authoritative servers should continue to follow the zone refresh
+   and expire parameters and a non-authoritative server should count
+   down the TTL and discard RRs when the TTL is zero (even for a SIG
+   that has not yet reached its authentication expiration time).  In
+   addition, when RRs are transmitted in a query response, the TTL
+
+
+
+
+Eastlake                    Standards Track                    [Page 23]
+
+RFC 2535                DNS Security Extensions               March 1999
+
+
+   should be trimmed so that current time plus the TTL does not extend
+   beyond the authentication expiration time.  Thus, in general, the TTL
+   on a transmitted RR would be
+
+      min(authExpTim,max(zoneMinTTL,min(originalTTL,currentTTL)))
+
+   When signatures are generated, signature expiration times should be
+   set far enough in the future that it is quite certain that new
+   signatures can be generated before the old ones expire.  However,
+   setting expiration too far into the future could mean a long time to
+   flush any bad data or signatures that may have been generated.
+
+   It is recommended that signature lifetime be a small multiple of the
+   TTL (ie, 4 to 16 times the TTL) but not less than a reasonable
+   maximum re-signing interval and not less than the zone expiry time.
+
+5. Non-existent Names and Types
+
+   The SIG RR mechanism described in Section 4 above provides strong
+   authentication of RRs that exist in a zone.  But it is not clear
+   above how to verifiably deny the existence of a name in a zone or a
+   type for an existent name.
+
+   The nonexistence of a name in a zone is indicated by the NXT ("next")
+   RR for a name interval containing the nonexistent name. An NXT RR or
+   RRs and its or their SIG(s) are returned in the authority section,
+   along with the error, if the server is security aware.  The same is
+   true for a non-existent type under an existing name except that there
+   is no error indication other than an empty answer section
+   accompanying the NXT(s). This is a change in the existing standard
+   [RFCs 1034/1035] which contemplates only NS and SOA RRs in the
+   authority section. NXT RRs will also be returned if an explicit query
+   is made for the NXT type.
+
+   The existence of a complete set of NXT records in a zone means that
+   any query for any name and any type to a security aware server
+   serving the zone will result in an reply containing at least one
+   signed RR unless it is a query for delegation point NS or glue A or
+   AAAA RRs.
+
+5.1 The NXT Resource Record
+
+   The NXT resource record is used to securely indicate that RRs with an
+   owner name in a certain name interval do not exist in a zone and to
+   indicate what RR types are present for an existing name.
+
+
+
+
+
+
+Eastlake                    Standards Track                    [Page 24]
+
+RFC 2535                DNS Security Extensions               March 1999
+
+
+   The owner name of the NXT RR is an existing name in the zone.  It's
+   RDATA is a "next" name and a type bit map. Thus the NXT RRs in a zone
+   create a chain of all of the literal owner names in that zone,
+   including unexpanded wildcards but omitting the owner name of glue
+   address records unless they would otherwise be included. This implies
+   a canonical ordering of all domain names in a zone as described in
+   Section 8. The presence of the NXT RR means that no name between its
+   owner name and the name in its RDATA area exists and that no other
+   types exist under its owner name.
+
+   There is a potential problem with the last NXT in a zone as it wants
+   to have an owner name which is the last existing name in canonical
+   order, which is easy, but it is not obvious what name to put in its
+   RDATA to indicate the entire remainder of the name space.  This is
+   handled by treating the name space as circular and putting the zone
+   name in the RDATA of the last NXT in a zone.
+
+   The NXT RRs for a zone SHOULD be automatically calculated and added
+   to the zone when SIGs are added.  The NXT RR's TTL SHOULD NOT exceed
+   the zone minimum TTL.
+
+   The type number for the NXT RR is 30.
+
+   NXT RRs are only signed by zone level keys.
+
+5.2 NXT RDATA Format
+
+   The RDATA for an NXT RR consists simply of a domain name followed by
+   a bit map, as shown below.
+
+                        1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                  next domain name                             /
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                    type bit map                               /
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   The NXT RR type bit map format currently defined is one bit per RR
+   type present for the owner name.  A one bit indicates that at least
+   one RR of that type is present for the owner name.  A zero indicates
+   that no such RR is present.  All bits not specified because they are
+   beyond the end of the bit map are assumed to be zero.  Note that bit
+   30, for NXT, will always be on so the minimum bit map length is
+   actually four octets. Trailing zero octets are prohibited in this
+   format.  The first bit represents RR type zero (an illegal type which
+   can not be present) and so will be zero in this format.  This format
+   is not used if there exists an RR with a type number greater than
+
+
+
+Eastlake                    Standards Track                    [Page 25]
+
+RFC 2535                DNS Security Extensions               March 1999
+
+
+   127.  If the zero bit of the type bit map is a one, it indicates that
+   a different format is being used which will always be the case if a
+   type number greater than 127 is present.
+
+   The domain name may be compressed with standard DNS name compression
+   when being transmitted over the network.  The size of the bit map can
+   be inferred from the RDLENGTH and the length of the next domain name.
+
+5.3 Additional Complexity Due to Wildcards
+
+   Proving that a non-existent name response is correct or that a
+   wildcard expansion response is correct makes things a little more
+   complex.
+
+   In particular, when a non-existent name response is returned, an NXT
+   must be returned showing that the exact name queried did not exist
+   and, in general, one or more additional NXT's need to be returned to
+   also prove that there wasn't a wildcard whose expansion should have
+   been returned. (There is no need to return multiple copies of the
+   same NXT.) These NXTs, if any, are returned in the authority section
+   of the response.
+
+   Furthermore, if a wildcard expansion is returned in a response, in
+   general one or more NXTs needs to also be returned in the authority
+   section to prove that no more specific name (including possibly more
+   specific wildcards in the zone) existed on which the response should
+   have been based.
+
+5.4 Example
+
+   Assume zone foo.nil has entries for
+
+          big.foo.nil,
+          medium.foo.nil.
+          small.foo.nil.
+          tiny.foo.nil.
+
+   Then a query to a security aware server for huge.foo.nil would
+   produce an error reply with an RCODE of NXDOMAIN and the authority
+   section data including something like the following:
+
+
+
+
+
+
+
+
+
+
+
+Eastlake                    Standards Track                    [Page 26]
+
+RFC 2535                DNS Security Extensions               March 1999
+
+
+   foo.nil.    NXT big.foo.nil NS KEY SOA NXT ;prove no *.foo.nil
+   foo.nil.    SIG NXT 1 2 ( ;type-cov=NXT, alg=1, labels=2
+                    19970102030405 ;signature expiration
+                    19961211100908 ;signature inception
+                    2143           ;key identifier
+                    foo.nil.       ;signer
+   AIYADP8d3zYNyQwW2EM4wXVFdslEJcUx/fxkfBeH1El4ixPFhpfHFElxbvKoWmvjDTCm
+   fiYy2X+8XpFjwICHc398kzWsTMKlxovpz2FnCTM= ;signature (640 bits)
+                          )
+   big.foo.nil. NXT medium.foo.nil. A MX SIG NXT ;prove no huge.foo.nil
+   big.foo.nil. SIG NXT 1 3 ( ;type-cov=NXT, alg=1, labels=3
+                    19970102030405 ;signature expiration
+                    19961211100908 ;signature inception
+                    2143           ;key identifier
+                    foo.nil.       ;signer
+    MxFcby9k/yvedMfQgKzhH5er0Mu/vILz45IkskceFGgiWCn/GxHhai6VAuHAoNUz4YoU
+    1tVfSCSqQYn6//11U6Nld80jEeC8aTrO+KKmCaY= ;signature (640 bits)
+                             )
+   Note that this response implies that big.foo.nil is an existing name
+   in the zone and thus has other RR types associated with it than NXT.
+   However, only the NXT (and its SIG) RR appear in the response to this
+   query for huge.foo.nil, which is a non-existent name.
+
+5.5 Special Considerations at Delegation Points
+
+   A name (other than root) which is the head of a zone also appears as
+   the leaf in a superzone.  If both are secure, there will always be
+   two different NXT RRs with the same name.  They can be easily
+   distinguished by their signers, the next domain name fields, the
+   presence of the SOA type bit, etc.  Security aware servers should
+   return the correct NXT automatically when required to authenticate
+   the non-existence of a name and both NXTs, if available, on explicit
+   query for type NXT.
+
+   Non-security aware servers will never automatically return an NXT and
+   some old implementations may only return the NXT from the subzone on
+   explicit queries.
+
+5.6 Zone Transfers
+
+   The subsections below describe how full and incremental zone
+   transfers are secured.
+
+   SIG RRs secure all authoritative RRs transferred for both full and
+   incremental [RFC 1995] zone transfers.  NXT RRs are an essential
+   element in secure zone transfers and assure that every authoritative
+   name and type will be present; however, if there are multiple SIGs
+   with the same name and type covered, a subset of the SIGs could be
+
+
+
+Eastlake                    Standards Track                    [Page 27]
+
+RFC 2535                DNS Security Extensions               March 1999
+
+
+   sent as long as at least one is present and, in the case of unsigned
+   delegation point NS or glue A or AAAA RRs a subset of these RRs or
+   simply a modified set could be sent as long as at least one of each
+   type is included.
+
+   When an incremental or full zone transfer request is received with
+   the same or newer version number than that of the server's copy of
+   the zone, it is replied to with just the SOA RR of the server's
+   current version and the SIG RRset verifying that SOA RR.
+
+   The complete NXT chains specified in this document enable a resolver
+   to obtain, by successive queries chaining through NXTs, all of the
+   names in a zone even if zone transfers are prohibited.  Different
+   format NXTs may be specified in the future to avoid this.
+
+5.6.1 Full Zone Transfers
+
+   To provide server authentication that a complete transfer has
+   occurred, transaction authentication SHOULD be used on full zone
+   transfers.  This provides strong server based protection for the
+   entire zone in transit.
+
+5.6.2 Incremental Zone Transfers
+
+   Individual RRs in an incremental (IXFR) transfer [RFC 1995] can be
+   verified in the same way as for a full zone transfer and the
+   integrity of the NXT name chain and correctness of the NXT type bits
+   for the zone after the incremental RR deletes and adds can check each
+   disjoint area of the zone updated.  But the completeness of an
+   incremental transfer can not be confirmed because usually neither the
+   deleted RR section nor the added RR section has a compete zone NXT
+   chain.  As a result, a server which securely supports IXFR must
+   handle IXFR SIG RRs for each incremental transfer set that it
+   maintains.
+
+   The IXFR SIG is calculated over the incremental zone update
+   collection of RRs in the order in which it is transmitted: old SOA,
+   then deleted RRs, then new SOA and added RRs.  Within each section,
+   RRs must be ordered as specified in Section 8.  If condensation of
+   adjacent incremental update sets is done by the zone owner, the
+   original IXFR SIG for each set included in the condensation must be
+   discarded and a new on IXFR SIG calculated to cover the resulting
+   condensed set.
+
+   The IXFR SIG really belongs to the zone as a whole, not to the zone
+   name.  Although it SHOULD be correct for the zone name, the labels
+   field of an IXFR SIG is otherwise meaningless.  The IXFR SIG is only
+   sent as part of an incremental zone transfer.  After validation of
+
+
+
+Eastlake                    Standards Track                    [Page 28]
+
+RFC 2535                DNS Security Extensions               March 1999
+
+
+   the IXFR SIG, the transferred RRs MAY be considered valid without
+   verification of the internal SIGs if such trust in the server
+   conforms to local policy.
+
+6. How to Resolve Securely and the AD and CD Bits
+
+   Retrieving or resolving secure data from the Domain Name System (DNS)
+   involves starting with one or more trusted public keys that have been
+   staticly configured at the resolver.  With starting trusted keys, a
+   resolver willing to perform cryptography can progress securely
+   through the secure DNS structure to the zone of interest as described
+   in Section 6.3. Such trusted public keys would normally be configured
+   in a manner similar to that described in Section 6.2.  However, as a
+   practical matter, a security aware resolver would still gain some
+   confidence in the results it returns even if it was not configured
+   with any keys but trusted what it got from a local well known server
+   as if it were staticly configured.
+
+   Data stored at a security aware server needs to be internally
+   categorized as Authenticated, Pending, or Insecure. There is also a
+   fourth transient state of Bad which indicates that all SIG checks
+   have explicitly failed on the data. Such Bad data is not retained at
+   a security aware server. Authenticated means that the data has a
+   valid SIG under a KEY traceable via a chain of zero or more SIG and
+   KEY RRs allowed by the resolvers policies to a KEY staticly
+   configured at the resolver. Pending data has no authenticated SIGs
+   and at least one additional SIG the resolver is still trying to
+   authenticate.  Insecure data is data which it is known can never be
+   either Authenticated or found Bad in the zone where it was found
+   because it is in or has been reached via a unsecured zone or because
+   it is unsigned glue address or delegation point NS data. Behavior in
+   terms of control of and flagging based on such data labels is
+   described in Section 6.1.
+
+   The proper validation of signatures requires a reasonably secure
+   shared opinion of the absolute time between resolvers and servers as
+   described in Section 6.4.
+
+6.1 The AD and CD Header Bits
+
+   Two previously unused bits are allocated out of the DNS
+   query/response format header. The AD (authentic data) bit indicates
+   in a response that all the data included in the answer and authority
+   portion of the response has been authenticated by the server
+   according to the policies of that server. The CD (checking disabled)
+   bit indicates in a query that Pending (non-authenticated) data is
+   acceptable to the resolver sending the query.
+
+
+
+
+Eastlake                    Standards Track                    [Page 29]
+
+RFC 2535                DNS Security Extensions               March 1999
+
+
+   These bits are allocated from the previously must-be-zero Z field as
+   follows:
+
+                                           1  1  1  1  1  1
+             0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
+            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+            |                      ID                       |
+            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+            |QR|   Opcode  |AA|TC|RD|RA| Z|AD|CD|   RCODE   |
+            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+            |                    QDCOUNT                    |
+            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+            |                    ANCOUNT                    |
+            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+            |                    NSCOUNT                    |
+            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+            |                    ARCOUNT                    |
+            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+   These bits are zero in old servers and resolvers.  Thus the responses
+   of old servers are not flagged as authenticated to security aware
+   resolvers and queries from non-security aware resolvers do not assert
+   the checking disabled bit and thus will be answered by security aware
+   servers only with Authenticated or Insecure data. Security aware
+   resolvers MUST NOT trust the AD bit unless they trust the server they
+   are talking to and either have a secure path to it or use DNS
+   transaction security.
+
+   Any security aware resolver willing to do cryptography SHOULD assert
+   the CD bit on all queries to permit it to impose its own policies and
+   to reduce DNS latency time by allowing security aware servers to
+   answer with Pending data.
+
+   Security aware servers MUST NOT return Bad data.  For non-security
+   aware resolvers or security aware resolvers requesting service by
+   having the CD bit clear, security aware servers MUST return only
+   Authenticated or Insecure data in the answer and authority sections
+   with the AD bit set in the response. Security aware servers SHOULD
+   return Pending data, with the AD bit clear in the response, to
+   security aware resolvers requesting this service by asserting the CD
+   bit in their request.  The AD bit MUST NOT be set on a response
+   unless all of the RRs in the answer and authority sections of the
+   response are either Authenticated or Insecure.  The AD bit does not
+   cover the additional information section.
+
+
+
+
+
+
+
+Eastlake                    Standards Track                    [Page 30]
+
+RFC 2535                DNS Security Extensions               March 1999
+
+
+6.2 Staticly Configured Keys
+
+   The public key to authenticate a zone SHOULD be defined in local
+   configuration files before that zone is loaded at the primary server
+   so the zone can be authenticated.
+
+   While it might seem logical for everyone to start with a public key
+   associated with the root zone and staticly configure this in every
+   resolver, this has problems.  The logistics of updating every DNS
+   resolver in the world should this key ever change would be severe.
+   Furthermore, many organizations will explicitly wish their "interior"
+   DNS implementations to completely trust only their own DNS servers.
+   Interior resolvers of such organizations can then go through the
+   organization's zone servers to access data outside the organization's
+   domain and need not be configured with keys above the organization's
+   DNS apex.
+
+   Host resolvers that are not part of a larger organization may be
+   configured with a key for the domain of their local ISP whose
+   recursive secure DNS caching server they use.
+
+6.3 Chaining Through The DNS
+
+   Starting with one or more trusted keys for any zone, it should be
+   possible to retrieve signed keys for that zone's subzones which have
+   a key. A secure sub-zone is indicated by a KEY RR with non-null key
+   information appearing with the NS RRs in the sub-zone and which may
+   also be present in the parent.  These make it possible to descend
+   within the tree of zones.
+
+6.3.1 Chaining Through KEYs
+
+   In general, some RRset that you wish to validate in the secure DNS
+   will be signed by one or more SIG RRs.  Each of these SIG RRs has a
+   signer under whose name is stored the public KEY to use in
+   authenticating the SIG.  Each of those KEYs will, generally, also be
+   signed with a SIG.  And those SIGs will have signer names also
+   referring to KEYs.  And so on. As a result, authentication leads to
+   chains of alternating SIG and KEY RRs with the first SIG signing the
+   original data whose authenticity is to be shown and the final KEY
+   being some trusted key staticly configured at the resolver performing
+   the authentication.
+
+   In testing such a chain, the validity periods of the SIGs encountered
+   must be intersected to determine the validity period of the
+   authentication of the data, a purely algorithmic process. In
+   addition, the validation of each SIG over the data with reference to
+   a KEY must meet the objective cryptographic test implied by the
+
+
+
+Eastlake                    Standards Track                    [Page 31]
+
+RFC 2535                DNS Security Extensions               March 1999
+
+
+   cryptographic algorithm used (although even here the resolver may
+   have policies as to trusted algorithms and key lengths).  Finally,
+   the judgement that a SIG with a particular signer name can
+   authenticate data (possibly a KEY RRset) with a particular owner
+   name, is primarily a policy question.  Ultimately, this is a policy
+   local to the resolver and any clients that depend on that resolver's
+   decisions.  It is, however, recommended, that the policy below be
+   adopted:
+
+        Let A < B mean that A is a shorter domain name than B formed by
+        dropping one or more whole labels from the left end of B, i.e.,
+        A is a direct or indirect superdomain of B.  Let A = B mean that
+        A and B are the same domain name (i.e., are identical after
+        letter case canonicalization).  Let A > B mean that A is a
+        longer domain name than B formed by adding one or more whole
+        labels on the left end of B, i.e., A is a direct or indirect
+        subdomain of B
+
+        Let Static be the owner names of the set of staticly configured
+        trusted keys at a resolver.
+
+        Then Signer is a valid signer name for a SIG authenticating an
+        RRset (possibly a KEY RRset) with owner name Owner at the
+        resolver if any of the following three rules apply:
+
+        (1) Owner > or = Signer (except that if Signer is root, Owner
+        must be root or a top level domain name).  That is, Owner is the
+        same as or a subdomain of Signer.
+
+        (2) ( Owner < Signer ) and ( Signer > or = some Static ).  That
+        is, Owner is a superdomain of Signer and Signer is staticly
+        configured or a subdomain of a staticly configured key.
+
+        (3) Signer = some Static.  That is, the signer is exactly some
+        staticly configured key.
+
+   Rule 1 is the rule for descending the DNS tree and includes a special
+   prohibition on the root zone key due to the restriction that the root
+   zone be only one label deep.  This is the most fundamental rule.
+
+   Rule 2 is the rule for ascending the DNS tree from one or more
+   staticly configured keys.  Rule 2 has no effect if only root zone
+   keys are staticly configured.
+
+   Rule 3 is a rule permitting direct cross certification.  Rule 3 has
+   no effect if only root zone keys are staticly configured.
+
+
+
+
+
+Eastlake                    Standards Track                    [Page 32]
+
+RFC 2535                DNS Security Extensions               March 1999
+
+
+   Great care should be taken that the consequences have been fully
+   considered before making any local policy adjustments to these rules
+   (other than dispensing with rules 2 and 3 if only root zone keys are
+   staticly configured).
+
+6.3.2 Conflicting Data
+
+   It is possible that there will be multiple SIG-KEY chains that appear
+   to authenticate conflicting RRset answers to the same query.  A
+   resolver should choose only the most reliable answer to return and
+   discard other data.  This choice of most reliable is a matter of
+   local policy which could take into account differing trust in
+   algorithms, key sizes, staticly configured keys, zones traversed,
+   etc.  The technique given below is recommended for taking into
+   account SIG-KEY chain length.
+
+   A resolver should keep track of the number of successive secure zones
+   traversed from a staticly configured key starting point to any secure
+   zone it can reach.  In general, the lower such a distance number is,
+   the greater the confidence in the data.  Staticly configured data
+   should be given a distance number of zero.  If a query encounters
+   different Authenticated data for the same query with different
+   distance values, that with a larger value should be ignored unless
+   some other local policy covers the case.
+
+   A security conscious resolver should completely refuse to step from a
+   secure zone into a unsecured zone unless the unsecured zone is
+   certified to be non-secure by the presence of an authenticated KEY RR
+   for the unsecured zone with the no-key type value.  Otherwise the
+   resolver is getting bogus or spoofed data.
+
+   If legitimate unsecured zones are encountered in traversing the DNS
+   tree, then no zone can be trusted as secure that can be reached only
+   via information from such non-secure zones. Since the unsecured zone
+   data could have been spoofed, the "secure" zone reached via it could
+   be counterfeit.  The "distance" to data in such zones or zones
+   reached via such zones could be set to 256 or more as this exceeds
+   the largest possible distance through secure zones in the DNS.
+
+6.4 Secure Time
+
+   Coordinated interpretation of the time fields in SIG RRs requires
+   that reasonably consistent time be available to the hosts
+   implementing the DNS security extensions.
+
+   A variety of time synchronization protocols exist including the
+   Network Time Protocol (NTP [RFC 1305, 2030]).  If such protocols are
+   used, they MUST be used securely so that time can not be spoofed.
+
+
+
+Eastlake                    Standards Track                    [Page 33]
+
+RFC 2535                DNS Security Extensions               March 1999
+
+
+   Otherwise, for example, a host could get its clock turned back and
+   might then believe old SIG RRs, and the data they authenticate, which
+   were valid but are no longer.
+
+7. ASCII Representation of Security RRs
+
+   This section discusses the format for master file and other ASCII
+   presentation of the three DNS security resource records.
+
+   The algorithm field in KEY and SIG RRs can be represented as either
+   an unsigned integer or symbolicly.  The following initial symbols are
+   defined as indicated:
+
+        Value  Symbol
+
+        001    RSAMD5
+        002    DH
+        003    DSA
+        004    ECC
+        252    INDIRECT
+        253    PRIVATEDNS
+        254    PRIVATEOID
+
+7.1 Presentation of KEY RRs
+
+   KEY RRs may appear as single logical lines in a zone data master file
+   [RFC 1033].
+
+   The flag field is represented as an unsigned integer or a sequence of
+   mnemonics as follows separated by instances of the verticle bar ("|")
+   character:
+
+     BIT  Mnemonic  Explanation
+    0-1           key type
+        NOCONF    =1 confidentiality use prohibited
+        NOAUTH    =2 authentication use prohibited
+        NOKEY     =3 no key present
+    2   FLAG2     - reserved
+    3   EXTEND    flags extension
+    4   FLAG4     - reserved
+    5   FLAG5     - reserved
+    6-7           name type
+        USER      =0 (default, may be omitted)
+        ZONE      =1
+        HOST      =2 (host or other end entity)
+        NTYP3     - reserved
+    8   FLAG8     - reserved
+    9   FLAG9     - reserved
+
+
+
+Eastlake                    Standards Track                    [Page 34]
+
+RFC 2535                DNS Security Extensions               March 1999
+
+
+   10   FLAG10    - reserved
+   11   FLAG11    - reserved
+   12-15          signatory field, values 0 to 15
+            can be represented by SIG0, SIG1, ... SIG15
+
+   No flag mnemonic need be present if the bit or field it represents is
+   zero.
+
+   The protocol octet can be represented as either an unsigned integer
+   or symbolicly.  The following initial symbols are defined:
+
+        000    NONE
+        001    TLS
+        002    EMAIL
+        003    DNSSEC
+        004    IPSEC
+        255    ALL
+
+   Note that if the type flags field has the NOKEY value, nothing
+   appears after the algorithm octet.
+
+   The remaining public key portion is represented in base 64 (see
+   Appendix A) and may be divided up into any number of white space
+   separated substrings, down to single base 64 digits, which are
+   concatenated to obtain the full signature.  These substrings can span
+   lines using the standard parenthesis.
+
+   Note that the public key may have internal sub-fields but these do
+   not appear in the master file representation.  For example, with
+   algorithm 1 there is a public exponent size, then a public exponent,
+   and then a modulus.  With algorithm 254, there will be an OID size,
+   an OID, and algorithm dependent information. But in both cases only a
+   single logical base 64 string will appear in the master file.
+
+7.2 Presentation of SIG RRs
+
+   A data SIG RR may be represented as a single logical line in a zone
+   data file [RFC 1033] but there are some special considerations as
+   described below.  (It does not make sense to include a transaction or
+   request authenticating SIG RR in a file as they are a transient
+   authentication that covers data including an ephemeral transaction
+   number and so must be calculated in real time.)
+
+   There is no particular problem with the signer, covered type, and
+   times.  The time fields appears in the form YYYYMMDDHHMMSS where YYYY
+   is the year, the first MM is the month number (01-12), DD is the day
+   of the month (01-31), HH is the hour in 24 hours notation (00-23),
+   the second MM is the minute (00-59), and SS is the second (00-59).
+
+
+
+Eastlake                    Standards Track                    [Page 35]
+
+RFC 2535                DNS Security Extensions               March 1999
+
+
+   The original TTL field appears as an unsigned integer.
+
+   If the original TTL, which applies to the type signed, is the same as
+   the TTL of the SIG RR itself, it may be omitted.  The date field
+   which follows it is larger than the maximum possible TTL so there is
+   no ambiguity.
+
+   The "labels" field appears as an unsigned integer.
+
+   The key tag appears as an unsigned number.
+
+   However, the signature itself can be very long.  It is the last data
+   field and is represented in base 64 (see Appendix A) and may be
+   divided up into any number of white space separated substrings, down
+   to single base 64 digits, which are concatenated to obtain the full
+   signature.  These substrings can be split between lines using the
+   standard parenthesis.
+
+7.3 Presentation of NXT RRs
+
+   NXT RRs do not appear in original unsigned zone master files since
+   they should be derived from the zone as it is being signed.  If a
+   signed file with NXTs added is printed or NXTs are printed by
+   debugging code, they appear as the next domain name followed by the
+   RR type present bits as an unsigned interger or sequence of RR
+   mnemonics.
+
+8. Canonical Form and Order of Resource Records
+
+   This section specifies, for purposes of domain name system (DNS)
+   security, the canonical form of resource records (RRs), their name
+   order, and their overall order.  A canonical name order is necessary
+   to construct the NXT name chain.  A canonical form and ordering
+   within an RRset is necessary in consistently constructing and
+   verifying SIG RRs.  A canonical ordering of types within a name is
+   required in connection with incremental transfer (Section 5.6.2).
+
+8.1 Canonical RR Form
+
+   For purposes of DNS security, the canonical form for an RR is the
+   wire format of the RR with domain names (1) fully expanded (no name
+   compression via pointers), (2) all domain name letters set to lower
+   case, (3) owner name wild cards in master file form (no substitution
+   made for *), and (4) the original TTL substituted for the current
+   TTL.
+
+
+
+
+
+
+Eastlake                    Standards Track                    [Page 36]
+
+RFC 2535                DNS Security Extensions               March 1999
+
+
+8.2 Canonical DNS Name Order
+
+   For purposes of DNS security, the canonical ordering of owner names
+   is to sort individual labels as unsigned left justified octet strings
+   where the absence of a octet sorts before a zero value octet and
+   upper case letters are treated as lower case letters.  Names in a
+   zone are sorted by sorting on the highest level label and then,
+   within those names with the same highest level label by the next
+   lower label, etc. down to leaf node labels.  Within a zone, the zone
+   name itself always exists and all other names are the zone name with
+   some prefix of lower level labels.  Thus the zone name itself always
+   sorts first.
+
+   Example:
+          foo.example
+          a.foo.example
+          yljkjljk.a.foo.example
+          Z.a.foo.example
+          zABC.a.FOO.EXAMPLE
+          z.foo.example
+          *.z.foo.example
+          \200.z.foo.example
+
+8.3 Canonical RR Ordering Within An RRset
+
+   Within any particular owner name and type, RRs are sorted by RDATA as
+   a left justified unsigned octet sequence where the absence of an
+   octet sorts before the zero octet.
+
+8.4 Canonical Ordering of RR Types
+
+   When RRs of the same name but different types must be ordered, they
+   are ordered by type, considering the type to be an unsigned integer,
+   except that SIG RRs are placed immediately after the type they cover.
+   Thus, for example, an A record would be put before an MX record
+   because A is type 1 and MX is type 15 but if both were signed, the
+   order would be A < SIG(A) < MX < SIG(MX).
+
+9. Conformance
+
+   Levels of server and resolver conformance are defined below.
+
+9.1 Server Conformance
+
+   Two levels of server conformance for DNS security are defined as
+   follows:
+
+
+
+
+
+Eastlake                    Standards Track                    [Page 37]
+
+RFC 2535                DNS Security Extensions               March 1999
+
+
+   BASIC:  Basic server compliance is the ability to store and retrieve
+   (including zone transfer) SIG, KEY, and NXT RRs.  Any secondary or
+   caching server for a secure zone MUST have at least basic compliance
+   and even then some things, such as secure CNAMEs, will not work
+   without full compliance.
+
+   FULL:  Full server compliance adds the following to basic compliance:
+   (1) ability to read SIG, KEY, and NXT RRs in zone files and (2)
+   ability, given a zone file and private key, to add appropriate SIG
+   and NXT RRs, possibly via a separate application, (3) proper
+   automatic inclusion of SIG, KEY, and NXT RRs in responses, (4)
+   suppression of CNAME following on retrieval of the security type RRs,
+   (5) recognize the CD query header bit and set the AD query header
+   bit, as appropriate, and (6) proper handling of the two NXT RRs at
+   delegation points.  Primary servers for secure zones MUST be fully
+   compliant and for complete secure operation, all secondary, caching,
+   and other servers handling the zone SHOULD be fully compliant as
+   well.
+
+9.2 Resolver Conformance
+
+   Two levels of resolver compliance (including the resolver portion of
+   a server) are defined for DNS Security:
+
+   BASIC: A basic compliance resolver can handle SIG, KEY, and NXT RRs
+   when they are explicitly requested.
+
+   FULL: A fully compliant resolver (1) understands KEY, SIG, and NXT
+   RRs including verification of SIGs at least for the mandatory
+   algorithm, (2) maintains appropriate information in its local caches
+   and database to indicate which RRs have been authenticated and to
+   what extent they have been authenticated, (3) performs additional
+   queries as necessary to attempt to obtain KEY, SIG, or NXT RRs when
+   needed, (4) normally sets the CD query header bit on its queries.
+
+10. Security Considerations
+
+   This document specifies extensions to the Domain Name System (DNS)
+   protocol to provide data integrity and data origin authentication,
+   public key distribution, and optional transaction and request
+   security.
+
+   It should be noted that, at most, these extensions guarantee the
+   validity of resource records, including KEY resource records,
+   retrieved from the DNS.  They do not magically solve other security
+   problems.  For example, using secure DNS you can have high confidence
+   in the IP address you retrieve for a host name; however, this does
+   not stop someone for substituting an unauthorized host at that
+
+
+
+Eastlake                    Standards Track                    [Page 38]
+
+RFC 2535                DNS Security Extensions               March 1999
+
+
+   address or capturing packets sent to that address and falsely
+   responding with packets apparently from that address.  Any reasonably
+   complete security system will require the protection of many
+   additional facets of the Internet beyond DNS.
+
+   The implementation of NXT RRs as described herein enables a resolver
+   to determine all the names in a zone even if zone transfers are
+   prohibited (section 5.6).  This is an active area of work and may
+   change.
+
+   A number of precautions in DNS implementation have evolved over the
+   years to harden the insecure DNS against spoofing.  These precautions
+   should not be abandoned but should be considered to provide
+   additional protection in case of key compromise in secure DNS.
+
+11. IANA Considerations
+
+   KEY RR flag bits 2 and 8-11 and all flag extension field bits can be
+   assigned by IETF consensus as defined in RFC 2434.  The remaining
+   values of the NAMTYP flag field and flag bits 4 and 5 (which could
+   conceivably become an extension of the NAMTYP field) can only be
+   assigned by an IETF Standards Action [RFC 2434].
+
+   Algorithm numbers 5 through 251 are available for assignment should
+   sufficient reason arise.  However, the designation of a new algorithm
+   could have a major impact on interoperability and requires an IETF
+   Standards Action [RFC 2434].  The existence of the private algorithm
+   types 253 and 254 should satify most needs for private or proprietary
+   algorithms.
+
+   Additional values of the Protocol Octet (5-254) can be assigned by
+   IETF Consensus [RFC 2434].
+
+   The meaning of the first bit of the NXT RR "type bit map" being a one
+   can only be assigned by a standards action.
+
+References
+
+   [RFC 1033]  Lottor, M., "Domain Administrators Operations Guide", RFC
+               1033, November 1987.
+
+   [RFC 1034]  Mockapetris, P., "Domain Names - Concepts and
+               Facilities", STD 13, RFC 1034, November 1987.
+
+   [RFC 1035]  Mockapetris, P., "Domain Names - Implementation and
+               Specifications", STD 13, RFC 1035, November 1987.
+
+
+
+
+
+Eastlake                    Standards Track                    [Page 39]
+
+RFC 2535                DNS Security Extensions               March 1999
+
+
+   [RFC 1305]  Mills, D., "Network Time Protocol (v3)", RFC 1305, March
+               1992.
+
+   [RFC 1530]  Malamud, C. and M. Rose, "Principles of Operation for the
+               TPC.INT Subdomain: General Principles and Policy", RFC
+               1530, October 1993.
+
+   [RFC 2401]  Kent, S. and R. Atkinson, "Security Architecture for the
+               Internet Protocol", RFC 2401, November 1998.
+
+   [RFC 1982]  Elz, R. and R. Bush, "Serial Number Arithmetic", RFC
+               1982, September 1996.
+
+   [RFC 1995]  Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
+               August 1996.
+
+   [RFC 2030]  Mills, D., "Simple Network Time Protocol (SNTP) Version 4
+               for IPv4, IPv6 and OSI", RFC 2030, October 1996.
+
+   [RFC 2045]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+               Extensions (MIME) Part One: Format of Internet Message
+               Bodies", RFC 2045, November 1996.
+
+   [RFC 2065]  Eastlake, D. and C. Kaufman, "Domain Name System Security
+               Extensions", RFC 2065, January 1997.
+
+   [RFC 2119]  Bradner, S., "Key words for use in RFCs to Indicate
+               Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC 2136]  Vixie, P., Thomson, S., Rekhter, Y. and J. Bound,
+               "Dynamic Updates in the Domain Name System (DNS UPDATE)",
+               RFC 2136, April 1997.
+
+   [RFC 2137]  Eastlake, D., "Secure Domain Name System Dynamic Update",
+               RFC 2137, April 1997.
+
+   [RFC 2181]  Elz, R. and R. Bush, "Clarifications to the DNS
+               Specification", RFC 2181, July 1997.
+
+   [RFC 2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
+               IANA Considerations Section in RFCs", BCP 26, RFC 2434,
+               October 1998.
+
+   [RFC 2537]  Eastlake, D., "RSA/MD5 KEYs and SIGs in the Domain Name
+               System (DNS)", RFC 2537, March 1999.
+
+   [RFC 2539]  Eastlake, D., "Storage of Diffie-Hellman Keys in the
+               Domain Name System (DNS)", RFC 2539, March 1999.
+
+
+
+Eastlake                    Standards Track                    [Page 40]
+
+RFC 2535                DNS Security Extensions               March 1999
+
+
+   [RFC 2536]  Eastlake, D., "DSA KEYs and SIGs in the Domain Name
+               System (DNS)", RFC 2536, March 1999.
+
+   [RFC 2538]  Eastlake, D. and O. Gudmundsson, "Storing Certificates in
+               the Domain Name System", RFC 2538, March 1999.
+
+   [RFC 2541]  Eastlake, D., "DNS Operational Security Considerations",
+               RFC 2541, March 1999.
+
+   [RSA FAQ] - RSADSI Frequently Asked Questions periodic posting.
+
+Author's Address
+
+   Donald E. Eastlake 3rd
+   IBM
+   65 Shindegan Hill Road
+   RR #1
+   Carmel, NY 10512
+
+   Phone:   +1-914-784-7913 (w)
+            +1-914-276-2668 (h)
+   Fax:     +1-914-784-3833 (w-fax)
+   EMail:   dee3@us.ibm.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake                    Standards Track                    [Page 41]
+
+RFC 2535                DNS Security Extensions               March 1999
+
+
+Appendix A: Base 64 Encoding
+
+   The following encoding technique is taken from [RFC 2045] by N.
+   Borenstein and N. Freed.  It is reproduced here in an edited form for
+   convenience.
+
+   A 65-character subset of US-ASCII is used, enabling 6 bits to be
+   represented per printable character. (The extra 65th character, "=",
+   is used to signify a special processing function.)
+
+   The encoding process represents 24-bit groups of input bits as output
+   strings of 4 encoded characters. Proceeding from left to right, a
+   24-bit input group is formed by concatenating 3 8-bit input groups.
+   These 24 bits are then treated as 4 concatenated 6-bit groups, each
+   of which is translated into a single digit in the base 64 alphabet.
+
+   Each 6-bit group is used as an index into an array of 64 printable
+   characters. The character referenced by the index is placed in the
+   output string.
+
+                         Table 1: The Base 64 Alphabet
+
+      Value Encoding  Value Encoding  Value Encoding  Value Encoding
+          0 A            17 R            34 i            51 z
+          1 B            18 S            35 j            52 0
+          2 C            19 T            36 k            53 1
+          3 D            20 U            37 l            54 2
+          4 E            21 V            38 m            55 3
+          5 F            22 W            39 n            56 4
+          6 G            23 X            40 o            57 5
+          7 H            24 Y            41 p            58 6
+          8 I            25 Z            42 q            59 7
+          9 J            26 a            43 r            60 8
+         10 K            27 b            44 s            61 9
+         11 L            28 c            45 t            62 +
+         12 M            29 d            46 u            63 /
+         13 N            30 e            47 v
+         14 O            31 f            48 w         (pad) =
+         15 P            32 g            49 x
+         16 Q            33 h            50 y
+
+   Special processing is performed if fewer than 24 bits are available
+   at the end of the data being encoded.  A full encoding quantum is
+   always completed at the end of a quantity.  When fewer than 24 input
+   bits are available in an input group, zero bits are added (on the
+   right) to form an integral number of 6-bit groups.  Padding at the
+   end of the data is performed using the '=' character.  Since all base
+   64 input is an integral number of octets, only the following cases
+
+
+
+Eastlake                    Standards Track                    [Page 42]
+
+RFC 2535                DNS Security Extensions               March 1999
+
+
+   can arise: (1) the final quantum of encoding input is an integral
+   multiple of 24 bits; here, the final unit of encoded output will be
+   an integral multiple of 4 characters with no "=" padding, (2) the
+   final quantum of encoding input is exactly 8 bits; here, the final
+   unit of encoded output will be two characters followed by two "="
+   padding characters, or (3) the final quantum of encoding input is
+   exactly 16 bits; here, the final unit of encoded output will be three
+   characters followed by one "=" padding character.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake                    Standards Track                    [Page 43]
+
+RFC 2535                DNS Security Extensions               March 1999
+
+
+Appendix B: Changes from RFC 2065
+
+   This section summarizes the most important changes that have been
+   made since RFC 2065.
+
+   1. Most of Section 7 of [RFC 2065] called "Operational
+      Considerations", has been removed and may be made into a separate
+      document [RFC 2541].
+
+   2. The KEY RR has been changed by (2a) eliminating the "experimental"
+      flag as unnecessary, (2b) reserving a flag  bit for flags
+      expansion, (2c) more compactly encoding a number of bit fields in
+      such a way as to leave unchanged bits actually used by the limited
+      code currently deployed, (2d) eliminating the IPSEC and email flag
+      bits which are replaced by values of the protocol field and adding
+      a protocol field value for DNS security itself, (2e) adding
+      material to indicate that zone KEY RRs occur only at delegation
+      points, and (2f) removing the description of the RSA/MD5 algorithm
+      to a separate document [RFC 2537].  Section 3.4 describing the
+      meaning of various combinations of "no-key" and key present KEY
+      RRs has been added and the secure / unsecure status of a zone has
+      been clarified as being per algorithm.
+
+   3. The SIG RR has been changed by (3a) renaming the "time signed"
+      field to be the "signature inception" field, (3b) clarifying that
+      signature expiration and inception use serial number ring
+      arithmetic, (3c) changing the definition of the key footprint/tag
+      for algorithms other than 1 and adding Appendix C to specify its
+      calculation.  In addition, the SIG covering type AXFR has been
+      eliminated while one covering IXFR [RFC 1995] has been added (see
+      section 5.6).
+
+   4. Algorithm 3, the DSA algorithm, is now designated as the mandatory
+      to implement algorithm.  Algorithm 1, the RSA/MD5 algorithm, is
+      now a recommended option.  Algorithm 2 and 4 are designated as the
+      Diffie-Hellman key and elliptic cryptography algorithms
+      respectively, all to be defined in separate documents. Algorithm
+      code point 252 is designated to indicate "indirect" keys, to be
+      defined in a separate document, where the actual key is elsewhere.
+      Both the KEY and SIG RR definitions have been simplified by
+      eliminating the "null" algorithm 253 as defined in [RFC 2065].
+      That algorithm had been included because at the time it was
+      thought it might be useful in DNS dynamic update [RFC 2136]. It
+      was in fact not so used and it is dropped to simplify DNS
+      security.  Howver, that algorithm number has been re-used to
+      indicate private algorithms where a domain name specifies the
+      algorithm.
+
+
+
+
+Eastlake                    Standards Track                    [Page 44]
+
+RFC 2535                DNS Security Extensions               March 1999
+
+
+   5. The NXT RR has been changed so that (5a) the NXT RRs in a zone
+      cover all names, including wildcards as literal names without
+      expansion, except for glue address records whose names would not
+      otherwise appear, (5b) all NXT bit map areas whose first octet has
+      bit zero set have been reserved for future definition, (5c) the
+      number of and circumstances under which an NXT must be returned in
+      connection with wildcard names has been extended, and (5d) in
+      connection with the bit map, references to the WKS RR have been
+      removed and verticle bars ("|") have been added between the RR
+      type mnemonics in the ASCII representation.
+
+   6. Information on the canonical form and ordering of RRs has been
+      moved into a separate Section 8.
+
+   7. A subsection covering incremental and full zone transfer has been
+      added in Section 5.
+
+   8. Concerning DNS chaining: Further specification and policy
+      recommendations on secure resolution have been added, primarily in
+      Section 6.3.1.  It is now clearly stated that authenticated data
+      has a validity period of the intersection of the validity periods
+      of the SIG RRs in its authentication chain.  The requirement to
+      staticly configure a superzone's key signed by a zone in all of
+      the zone's authoritative servers has been removed.  The
+      recommendation to continue DNS security checks in a secure island
+      of DNS data that is separated from other parts of the DNS tree by
+      insecure zones and does not contain a zone for which a key has
+      been staticly configured was dropped.
+
+   9. It was clarified that the presence of the AD bit in a response
+      does not apply to the additional information section or to glue
+      address or delegation point NS RRs.  The AD bit only indicates
+      that the answer and authority sections of the response are
+      authoritative.
+
+   10. It is now required that KEY RRs and NXT RRs be signed only with
+       zone-level keys.
+
+   11.  Add IANA Considerations section and references to RFC 2434.
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake                    Standards Track                    [Page 45]
+
+RFC 2535                DNS Security Extensions               March 1999
+
+
+Appendix C: Key Tag Calculation
+
+   The key tag field in the SIG RR is just a means of more efficiently
+   selecting the correct KEY RR to use when there is more than one KEY
+   RR candidate available, for example, in verifying a signature.  It is
+   possible for more than one candidate key to have the same tag, in
+   which case each must be tried until one works or all fail.  The
+   following reference implementation of how to calculate the Key Tag,
+   for all algorithms other than algorithm 1, is in ANSI C.  It is coded
+   for clarity, not efficiency.  (See section 4.1.6 for how to determine
+   the Key Tag of an algorithm 1 key.)
+
+   /* assumes int is at least 16 bits
+      first byte of the key tag is the most significant byte of return
+      value
+      second byte of the key tag is the least significant byte of
+      return value
+      */
+
+   int keytag (
+
+           unsigned char key[],  /* the RDATA part of the KEY RR */
+           unsigned int keysize, /* the RDLENGTH */
+           )
+   {
+   long int    ac;    /* assumed to be 32 bits or larger */
+
+   for ( ac = 0, i = 0; i < keysize; ++i )
+       ac += (i&1) ? key[i] : key[i]<<8;
+   ac += (ac>>16) & 0xFFFF;
+   return ac & 0xFFFF;
+   }
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake                    Standards Track                    [Page 46]
+
+RFC 2535                DNS Security Extensions               March 1999
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (1999).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake                    Standards Track                    [Page 47]
+
diff --git a/doc/rfc/rfc2536.txt b/doc/rfc/rfc2536.txt
new file mode 100644
index 0000000..88be242
--- /dev/null
+++ b/doc/rfc/rfc2536.txt
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+Network Working Group                                        D. EastLake
+Request for Comments: 2536                                           IBM
+Category: Standards Track                                     March 1999
+
+
+           DSA KEYs and SIGs in the Domain Name System (DNS)
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1999).  All Rights Reserved.
+
+Abstract
+
+   A standard method for storing US Government Digital Signature
+   Algorithm keys and signatures in the Domain Name System is described
+   which utilizes DNS KEY and SIG resource records.
+
+Table of Contents
+
+   Abstract...................................................1
+   1. Introduction............................................1
+   2. DSA KEY Resource Records................................2
+   3. DSA SIG Resource Records................................3
+   4. Performance Considerations..............................3
+   5. Security Considerations.................................4
+   6. IANA Considerations.....................................4
+   References.................................................5
+   Author's Address...........................................5
+   Full Copyright Statement...................................6
+
+1. Introduction
+
+   The Domain Name System (DNS) is the global hierarchical replicated
+   distributed database system for Internet addressing, mail proxy, and
+   other information. The DNS has been extended to include digital
+   signatures and cryptographic keys as described in [RFC 2535].  Thus
+   the DNS can now be secured and can be used for secure key
+   distribution.
+
+
+
+
+
+Eastlake                    Standards Track                     [Page 1]
+
+RFC 2536                     DSA in the DNS                   March 1999
+
+
+   This document describes how to store US Government Digital Signature
+   Algorithm (DSA) keys and signatures in the DNS.  Familiarity with the
+   US Digital Signature Algorithm is assumed [Schneier].  Implementation
+   of DSA is mandatory for DNS security.
+
+2. DSA KEY Resource Records
+
+   DSA public keys are stored in the DNS as KEY RRs using algorithm
+   number 3 [RFC 2535].  The structure of the algorithm specific portion
+   of the RDATA part of this RR is as shown below.  These fields, from Q
+   through Y are the "public key" part of the DSA KEY RR.
+
+   The period of key validity is not in the KEY RR but is indicated by
+   the SIG RR(s) which signs and authenticates the KEY RR(s) at that
+   domain name.
+
+           Field     Size
+           -----     ----
+            T         1  octet
+            Q        20  octets
+            P        64 + T*8  octets
+            G        64 + T*8  octets
+            Y        64 + T*8  octets
+
+   As described in [FIPS 186] and [Schneier]: T is a key size parameter
+   chosen such that 0 <= T <= 8.  (The meaning for algorithm 3 if the T
+   octet is greater than 8 is reserved and the remainder of the RDATA
+   portion may have a different format in that case.)  Q is a prime
+   number selected at key generation time such that 2**159 < Q < 2**160
+   so Q is always 20 octets long and, as with all other fields, is
+   stored in "big-endian" network order.  P, G, and Y are calculated as
+   directed by the FIPS 186 key generation algorithm [Schneier].  P is
+   in the range 2**(511+64T) < P < 2**(512+64T) and so is 64 + 8*T
+   octets long.  G and Y are quantities modulus P and so can be up to
+   the same length as P and are allocated fixed size fields with the
+   same number of octets as P.
+
+   During the key generation process, a random number X must be
+   generated such that 1 <= X <= Q-1.  X is the private key and is used
+   in the final step of public key generation where Y is computed as
+
+             Y = G**X mod P
+
+
+
+
+
+
+
+
+
+Eastlake                    Standards Track                     [Page 2]
+
+RFC 2536                     DSA in the DNS                   March 1999
+
+
+3. DSA SIG Resource Records
+
+   The signature portion of the SIG RR RDATA area, when using the US
+   Digital Signature Algorithm, is shown below with fields in the order
+   they occur.  See [RFC 2535] for fields in the SIG RR RDATA which
+   precede the signature itself.
+
+           Field     Size
+           -----     ----
+            T         1 octet
+            R        20 octets
+            S        20 octets
+
+   The data signed is determined as specified in [RFC 2535].  Then the
+   following steps are taken, as specified in [FIPS 186], where Q, P, G,
+   and Y are as specified in the public key [Schneier]:
+
+           hash = SHA-1 ( data )
+
+           Generate a random K such that 0 < K < Q.
+
+           R = ( G**K mod P ) mod Q
+
+           S = ( K**(-1) * (hash + X*R) ) mod Q
+
+   Since Q is 160 bits long, R and S can not be larger than 20 octets,
+   which is the space allocated.
+
+   T is copied from the public key.  It is not logically necessary in
+   the SIG but is present so that values of T > 8 can more conveniently
+   be used as an escape for extended versions of DSA or other algorithms
+   as later specified.
+
+4. Performance Considerations
+
+   General signature generation speeds are roughly the same for RSA [RFC
+   2537] and DSA.  With sufficient pre-computation, signature generation
+   with DSA is faster than RSA.  Key generation is also faster for DSA.
+   However, signature verification is an order of magnitude slower than
+   RSA when the RSA public exponent is chosen to be small as is
+   recommended for KEY RRs used in domain name system (DNS) data
+   authentication.
+
+   Current DNS implementations are optimized for small transfers,
+   typically less than 512 bytes including overhead.  While larger
+   transfers will perform correctly and work is underway to make larger
+   transfers more efficient, it is still advisable at this time to make
+   reasonable efforts to minimize the size of KEY RR sets stored within
+
+
+
+Eastlake                    Standards Track                     [Page 3]
+
+RFC 2536                     DSA in the DNS                   March 1999
+
+
+   the DNS consistent with adequate security.  Keep in mind that in a
+   secure zone, at least one authenticating SIG RR will also be
+   returned.
+
+5. Security Considerations
+
+   Many of the general security consideration in [RFC 2535] apply.  Keys
+   retrieved from the DNS should not be trusted unless (1) they have
+   been securely obtained from a secure resolver or independently
+   verified by the user and (2) this secure resolver and secure
+   obtainment or independent verification conform to security policies
+   acceptable to the user.  As with all cryptographic algorithms,
+   evaluating the necessary strength of the key is essential and
+   dependent on local policy.
+
+   The key size limitation of a maximum of 1024 bits ( T = 8 ) in the
+   current DSA standard may limit the security of DSA.  For particularly
+   critical applications, implementors are encouraged to consider the
+   range of available algorithms and key sizes.
+
+   DSA assumes the ability to frequently generate high quality random
+   numbers.  See [RFC 1750] for guidance.  DSA is designed so that if
+   manipulated rather than random numbers are used, very high bandwidth
+   covert channels are possible.  See [Schneier] and more recent
+   research.  The leakage of an entire DSA private key in only two DSA
+   signatures has been demonstrated.  DSA provides security only if
+   trusted implementations, including trusted random number generation,
+   are used.
+
+6. IANA Considerations
+
+   Allocation of meaning to values of the T parameter that are not
+   defined herein requires an IETF standards actions.  It is intended
+   that values unallocated herein be used to cover future extensions of
+   the DSS standard.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake                    Standards Track                     [Page 4]
+
+RFC 2536                     DSA in the DNS                   March 1999
+
+
+References
+
+   [FIPS 186]   U.S. Federal Information Processing Standard: Digital
+                Signature Standard.
+
+   [RFC 1034]   Mockapetris, P., "Domain Names - Concepts and
+                Facilities", STD 13, RFC 1034, November 1987.
+
+   [RFC 1035]   Mockapetris, P., "Domain Names - Implementation and
+                Specification", STD 13, RFC 1035, November 1987.
+
+   [RFC 1750]   Eastlake, D., Crocker, S. and J. Schiller, "Randomness
+                Recommendations for Security", RFC 1750, December 1994.
+
+   [RFC 2535]   Eastlake, D., "Domain Name System Security Extensions",
+                RFC 2535, March 1999.
+
+   [RFC 2537]   Eastlake, D., "RSA/MD5 KEYs and SIGs in the Domain Name
+                System (DNS)", RFC 2537, March 1999.
+
+   [Schneier]   Schneier, B., "Applied Cryptography Second Edition:
+                protocols, algorithms, and source code in C", 1996.
+
+Author's Address
+
+   Donald E. Eastlake 3rd
+   IBM
+   65 Shindegan Hill Road, RR #1
+   Carmel, NY 10512
+
+   Phone:   +1-914-276-2668(h)
+            +1-914-784-7913(w)
+   Fax:     +1-914-784-3833(w)
+   EMail:   dee3@us.ibm.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake                    Standards Track                     [Page 5]
+
+RFC 2536                     DSA in the DNS                   March 1999
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (1999).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake                    Standards Track                     [Page 6]
+
diff --git a/doc/rfc/rfc2537.txt b/doc/rfc/rfc2537.txt
new file mode 100644
index 0000000..cb75cf5
--- /dev/null
+++ b/doc/rfc/rfc2537.txt
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+Network Working Group                                        D. Eastlake
+Request for Comments: 2537                                           IBM
+Category: Standards Track                                     March 1999
+
+
+         RSA/MD5 KEYs and SIGs in the Domain Name System (DNS)
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1999).  All Rights Reserved.
+
+Abstract
+
+   A standard method for storing RSA keys and and RSA/MD5 based
+   signatures in the Domain Name System is described which utilizes DNS
+   KEY and SIG resource records.
+
+Table of Contents
+
+   Abstract...................................................1
+   1. Introduction............................................1
+   2. RSA Public KEY Resource Records.........................2
+   3. RSA/MD5 SIG Resource Records............................2
+   4. Performance Considerations..............................3
+   5. Security Considerations.................................4
+   References.................................................4
+   Author's Address...........................................5
+   Full Copyright Statement...................................6
+
+1. Introduction
+
+   The Domain Name System (DNS) is the global hierarchical replicated
+   distributed database system for Internet addressing, mail proxy, and
+   other information. The DNS has been extended to include digital
+   signatures and cryptographic keys as described in [RFC 2535].  Thus
+   the DNS can now be secured and used for secure key distribution.
+
+
+
+
+
+
+
+Eastlake                    Standards Track                     [Page 1]
+
+RFC 2537            RSA/MD5 KEYs and SIGs in the DNS          March 1999
+
+
+   This document describes how to store RSA keys and and RSA/MD5 based
+   signatures in the DNS.  Familiarity with the RSA algorithm is assumed
+   [Schneier].  Implementation of the RSA algorithm in DNS is
+   recommended.
+
+   The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY"
+   in this document are to be interpreted as described in RFC 2119.
+
+2. RSA Public KEY Resource Records
+
+   RSA public keys are stored in the DNS as KEY RRs using algorithm
+   number 1 [RFC 2535].  The structure of the algorithm specific portion
+   of the RDATA part of such RRs is as shown below.
+
+           Field             Size
+           -----             ----
+           exponent length   1 or 3 octets (see text)
+           exponent          as specified by length field
+           modulus           remaining space
+
+   For interoperability, the exponent and modulus are each currently
+   limited to 4096 bits in length.  The public key exponent is a
+   variable length unsigned integer.  Its length in octets is
+   represented as one octet if it is in the range of 1 to 255 and by a
+   zero octet followed by a two octet unsigned length if it is longer
+   than 255 bytes.  The public key modulus field is a multiprecision
+   unsigned integer.  The length of the modulus can be determined from
+   the RDLENGTH and the preceding RDATA fields including the exponent.
+   Leading zero octets are prohibited in the exponent and modulus.
+
+3. RSA/MD5 SIG Resource Records
+
+   The signature portion of the SIG RR RDATA area, when using the
+   RSA/MD5 algorithm, is calculated as shown below.  The data signed is
+   determined as specified in [RFC 2535].  See [RFC 2535] for fields in
+   the SIG RR RDATA which precede the signature itself.
+
+
+     hash = MD5 ( data )
+
+     signature = ( 00 | 01 | FF* | 00 | prefix | hash ) ** e (mod n)
+
+
+
+
+
+
+
+
+
+
+Eastlake                    Standards Track                     [Page 2]
+
+RFC 2537            RSA/MD5 KEYs and SIGs in the DNS          March 1999
+
+
+   where MD5 is the message digest algorithm documented in [RFC 1321],
+   "|" is concatenation, "e" is the private key exponent of the signer,
+   and "n" is the modulus of the signer's public key.  01, FF, and 00
+   are fixed octets of the corresponding hexadecimal value. "prefix" is
+   the ASN.1 BER MD5 algorithm designator prefix specified in [RFC
+   2437], that is,
+
+      hex 3020300c06082a864886f70d020505000410 [NETSEC].
+
+   This prefix is included to make it easier to use RSAREF (or similar
+   packages such as EuroRef).  The FF octet MUST be repeated the maximum
+   number of times such that the value of the quantity being
+   exponentiated is the same length in octets as the value of n.
+
+   (The above specifications are identical to the corresponding part of
+   Public Key Cryptographic Standard #1 [RFC 2437].)
+
+   The size of n, including most and least significant bits (which will
+   be 1) MUST be not less than 512 bits and not more than 4096 bits.  n
+   and e SHOULD be chosen such that the public exponent is small.
+
+   Leading zero bytes are permitted in the RSA/MD5 algorithm signature.
+
+   A public exponent of 3 minimizes the effort needed to verify a
+   signature.  Use of 3 as the public exponent is weak for
+   confidentiality uses since, if the same data can be collected
+   encrypted under three different keys with an exponent of 3 then,
+   using the Chinese Remainder Theorem [NETSEC], the original plain text
+   can be easily recovered.  This weakness is not significant for DNS
+   security because we seek only authentication, not confidentiality.
+
+4. Performance Considerations
+
+   General signature generation speeds are roughly the same for RSA and
+   DSA [RFC 2536].  With sufficient pre-computation, signature
+   generation with DSA is faster than RSA.  Key generation is also
+   faster for DSA.  However, signature verification is an order of
+   magnitude slower with DSA when the RSA public exponent is chosen to
+   be small as is recommended for KEY RRs used in domain name system
+   (DNS) data authentication.
+
+   Current DNS implementations are optimized for small transfers,
+   typically less than 512 bytes including overhead.  While larger
+   transfers will perform correctly and work is underway to make larger
+
+
+
+
+
+
+
+Eastlake                    Standards Track                     [Page 3]
+
+RFC 2537            RSA/MD5 KEYs and SIGs in the DNS          March 1999
+
+
+   transfers more efficient, it is still advisable at this time to make
+   reasonable efforts to minimize the size of KEY RR sets stored within
+   the DNS consistent with adequate security.  Keep in mind that in a
+   secure zone, at least one authenticating SIG RR will also be
+   returned.
+
+5. Security Considerations
+
+   Many of the general security consideration in [RFC 2535] apply.  Keys
+   retrieved from the DNS should not be trusted unless (1) they have
+   been securely obtained from a secure resolver or independently
+   verified by the user and (2) this secure resolver and secure
+   obtainment or independent verification conform to security policies
+   acceptable to the user.  As with all cryptographic algorithms,
+   evaluating the necessary strength of the key is essential and
+   dependent on local policy.
+
+   For interoperability, the RSA key size is limited to 4096 bits.  For
+   particularly critical applications, implementors are encouraged to
+   consider the range of available algorithms and key sizes.
+
+References
+
+   [NETSEC]     Kaufman, C., Perlman, R. and M. Speciner, "Network
+                Security: PRIVATE Communications in a PUBLIC World",
+                Series in Computer Networking and Distributed
+                Communications, 1995.
+
+   [RFC 2437]   Kaliski, B. and J. Staddon, "PKCS #1: RSA Cryptography
+                Specifications Version 2.0", RFC 2437, October 1998.
+
+   [RFC 1034]   Mockapetris, P., "Domain Names - Concepts and
+                Facilities", STD 13, RFC 1034, November 1987.
+
+   [RFC 1035]   Mockapetris, P., "Domain Names - Implementation and
+                Specification", STD 13, RFC 1035, November 1987.
+
+   [RFC 1321]   Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321
+                April 1992.
+
+   [RFC 2535]   Eastlake, D., "Domain Name System Security Extensions",
+                RFC 2535, March 1999.
+
+   [RFC 2536]   EastLake, D., "DSA KEYs and SIGs in the Domain Name
+                System (DNS)", RFC 2536, March 1999.
+
+
+
+
+
+
+Eastlake                    Standards Track                     [Page 4]
+
+RFC 2537            RSA/MD5 KEYs and SIGs in the DNS          March 1999
+
+
+   [Schneier]   Bruce Schneier, "Applied Cryptography Second Edition:
+                protocols, algorithms, and source code in C", 1996, John
+                Wiley and Sons, ISBN 0-471-11709-9.
+
+Author's Address
+
+   Donald E. Eastlake 3rd
+   IBM
+   65 Shindegan Hill Road, RR #1
+   Carmel, NY 10512
+
+   Phone:   +1-914-276-2668(h)
+            +1-914-784-7913(w)
+   Fax:     +1-914-784-3833(w)
+   EMail:   dee3@us.ibm.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake                    Standards Track                     [Page 5]
+
+RFC 2537            RSA/MD5 KEYs and SIGs in the DNS          March 1999
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (1999).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake                    Standards Track                     [Page 6]
+
diff --git a/doc/rfc/rfc2538.txt b/doc/rfc/rfc2538.txt
new file mode 100644
index 0000000..c53e3ef
--- /dev/null
+++ b/doc/rfc/rfc2538.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+Network Working Group                                        D. Eastlake
+Request for Comments: 2538                                           IBM
+Category: Standards Track                                 O. Gudmundsson
+                                                                TIS Labs
+                                                              March 1999
+
+
+          Storing Certificates in the Domain Name System (DNS)
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1999).  All Rights Reserved.
+
+Abstract
+
+   Cryptographic public key are frequently published and their
+   authenticity demonstrated by certificates.  A CERT resource record
+   (RR) is defined so that such certificates and related certificate
+   revocation lists can be stored in the Domain Name System (DNS).
+
+Table of Contents
+
+   Abstract...................................................1
+   1. Introduction............................................2
+   2. The CERT Resource Record................................2
+   2.1 Certificate Type Values................................3
+   2.2 Text Representation of CERT RRs........................4
+   2.3 X.509 OIDs.............................................4
+   3. Appropriate Owner Names for CERT RRs....................5
+   3.1 X.509 CERT RR Names....................................5
+   3.2 PGP CERT RR Names......................................6
+   4. Performance Considerations..............................6
+   5. IANA Considerations.....................................7
+   6. Security Considerations.................................7
+   References.................................................8
+   Authors' Addresses.........................................9
+   Full Copyright Notice.....................................10
+
+
+
+
+
+
+Eastlake & Gudmundsson      Standards Track                     [Page 1]
+
+RFC 2538            Storing Certificates in the DNS           March 1999
+
+
+1. Introduction
+
+   Public keys are frequently published in the form of a certificate and
+   their authenticity is commonly demonstrated by certificates and
+   related certificate revocation lists (CRLs).  A certificate is a
+   binding, through a cryptographic digital signature, of a public key,
+   a validity interval and/or conditions, and identity, authorization,
+   or other information. A certificate revocation list is a list of
+   certificates that are revoked, and incidental information, all signed
+   by the signer (issuer) of the revoked certificates. Examples are
+   X.509 certificates/CRLs in the X.500 directory system or PGP
+   certificates/revocations used by PGP software.
+
+   Section 2 below specifies a CERT resource record (RR) for the storage
+   of certificates in the Domain Name System.
+
+   Section 3 discusses appropriate owner names for CERT RRs.
+
+   Sections 4, 5, and 6 below cover performance, IANA, and security
+   considerations, respectively.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+2. The CERT Resource Record
+
+   The CERT resource record (RR) has the structure given below.  Its RR
+   type code is 37.
+
+                         1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
+     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |             type              |             key tag           |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |   algorithm   |                                               /
+    +---------------+            certificate or CRL                 /
+    /                                                               /
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
+
+   The type field is the certificate type as define in section 2.1
+   below.
+
+   The algorithm field has the same meaning as the algorithm field in
+   KEY and SIG RRs [RFC 2535] except that a zero algorithm field
+   indicates the algorithm is unknown to a secure DNS, which may simply
+   be the result of the algorithm not having been standardized for
+   secure DNS.
+
+
+
+Eastlake & Gudmundsson      Standards Track                     [Page 2]
+
+RFC 2538            Storing Certificates in the DNS           March 1999
+
+
+   The key tag field is the 16 bit value computed for the key embedded
+   in the certificate as specified in the DNSSEC Standard [RFC 2535].
+   This field is used as an efficiency measure to pick which CERT RRs
+   may be applicable to a particular key.  The key tag can be calculated
+   for the key in question and then only CERT RRs with the same key tag
+   need be examined. However, the key must always be transformed to the
+   format it would have as the public key portion of a KEY RR before the
+   key tag is computed.  This is only possible if the key is applicable
+   to an algorithm (and limits such as key size limits) defined for DNS
+   security.  If it is not, the algorithm field MUST BE zero and the tag
+   field is meaningless and SHOULD BE zero.
+
+2.1 Certificate Type Values
+
+   The following values are defined or reserved:
+
+    Value  Mnemonic  Certificate Type
+    -----  --------  ----------- ----
+        0            reserved
+        1   PKIX     X.509 as per PKIX
+        2   SPKI     SPKI cert
+        3   PGP      PGP cert
+    4-252            available for IANA assignment
+      253   URI      URI private
+      254   OID      OID private
+    255-65534        available for IANA assignment
+    65535            reserved
+
+   The PKIX type is reserved to indicate an X.509 certificate conforming
+   to the profile being defined by the IETF PKIX working group.  The
+   certificate section will start with a one byte unsigned OID length
+   and then an X.500 OID indicating the nature of the remainder of the
+   certificate section (see 2.3 below).  (NOTE: X.509 certificates do
+   not include their X.500 directory type designating OID as a prefix.)
+
+   The SPKI type is reserved to indicate a certificate formated as to be
+   specified by the IETF SPKI working group.
+
+   The PGP type indicates a Pretty Good Privacy certificate as described
+   in RFC 2440 and its extensions and successors.
+
+   The URI private type indicates a certificate format defined by an
+   absolute URI.  The certificate portion of the CERT RR MUST begin with
+   a null terminated URI [RFC 2396] and the data after the null is the
+   private format certificate itself.  The URI SHOULD be such that a
+   retrieval from it will lead to documentation on the format of the
+   certificate.  Recognition of private certificate types need not be
+   based on URI equality but can use various forms of pattern matching
+
+
+
+Eastlake & Gudmundsson      Standards Track                     [Page 3]
+
+RFC 2538            Storing Certificates in the DNS           March 1999
+
+
+   so that, for example, subtype or version information can also be
+   encoded into the URI.
+
+   The OID private type indicates a private format certificate specified
+   by a an ISO OID prefix.  The certificate section will start with a
+   one byte unsigned OID length and then a BER encoded OID indicating
+   the nature of the remainder of the certificate section.  This can be
+   an X.509 certificate format or some other format.  X.509 certificates
+   that conform to the IETF PKIX profile SHOULD be indicated by the PKIX
+   type, not the OID private type.  Recognition of private certificate
+   types need not be based on OID equality but can use various forms of
+   pattern matching such as OID prefix.
+
+2.2 Text Representation of CERT RRs
+
+   The RDATA portion of a CERT RR has the type field as an unsigned
+   integer or as a mnemonic symbol as listed in section 2.1 above.
+
+   The key tag field is represented as an unsigned integer.
+
+   The algorithm field is represented as an unsigned integer or a
+   mnemonic symbol as listed in [RFC 2535].
+
+   The certificate / CRL portion is represented in base 64 and may be
+   divided up into any number of white space separated substrings, down
+   to single base 64 digits, which are concatenated to obtain the full
+   signature.  These substrings can span lines using the standard
+   parenthesis.
+
+   Note that the certificate / CRL portion may have internal sub-fields
+   but these do not appear in the master file representation.  For
+   example, with type 254, there will be an OID size, an OID, and then
+   the certificate / CRL proper. But only a single logical base 64
+   string will appear in the text representation.
+
+2.3 X.509 OIDs
+
+   OIDs have been defined in connection with the X.500 directory for
+   user certificates, certification authority certificates, revocations
+   of certification authority, and revocations of user certificates.
+   The following table lists the OIDs, their BER encoding, and their
+   length prefixed hex format for use in CERT RRs:
+
+
+
+
+
+
+
+
+
+Eastlake & Gudmundsson      Standards Track                     [Page 4]
+
+RFC 2538            Storing Certificates in the DNS           March 1999
+
+
+    id-at-userCertificate
+        = { joint-iso-ccitt(2) ds(5) at(4) 36 }
+           == 0x 03 55 04 24
+    id-at-cACertificate
+        = { joint-iso-ccitt(2) ds(5) at(4) 37 }
+           == 0x 03 55 04 25
+    id-at-authorityRevocationList
+        = { joint-iso-ccitt(2) ds(5) at(4) 38 }
+           == 0x 03 55 04 26
+    id-at-certificateRevocationList
+        = { joint-iso-ccitt(2) ds(5) at(4) 39 }
+           == 0x 03 55 04 27
+
+3. Appropriate Owner Names for CERT RRs
+
+   It is recommended that certificate CERT RRs be stored under a domain
+   name related to their subject, i.e., the name of the entity intended
+   to control the private key corresponding to the public key being
+   certified.  It is recommended that certificate revocation list CERT
+   RRs be stored under a domain name related to their issuer.
+
+   Following some of the guidelines below may result in the use in DNS
+   names of characters that require DNS quoting which is to use a
+   backslash followed by the octal representation of the ASCII code for
+   the character such as \000 for NULL.
+
+3.1 X.509 CERT RR Names
+
+   Some X.509 versions permit multiple names to be associated with
+   subjects and issuers under "Subject Alternate Name" and "Issuer
+   Alternate Name".  For example, x.509v3 has such Alternate Names with
+   an ASN.1 specification as follows:
+
+         GeneralName ::= CHOICE {
+            otherName                  [0] INSTANCE OF OTHER-NAME,
+            rfc822Name                 [1] IA5String,
+            dNSName                    [2] IA5String,
+            x400Address                [3] EXPLICIT OR-ADDRESS.&Type,
+            directoryName              [4] EXPLICIT Name,
+            ediPartyName               [5] EDIPartyName,
+            uniformResourceIdentifier  [6] IA5String,
+            iPAddress                  [7] OCTET STRING,
+            registeredID               [8] OBJECT IDENTIFIER
+         }
+
+   The recommended locations of CERT storage are as follows, in priority
+   order:
+
+
+
+
+Eastlake & Gudmundsson      Standards Track                     [Page 5]
+
+RFC 2538            Storing Certificates in the DNS           March 1999
+
+
+   (1) If a domain name is included in the identification in the
+       certificate or CRL, that should be used.
+   (2) If a domain name is not included but an IP address is included,
+       then the translation of that IP address into the appropriate
+       inverse domain name should be used.
+   (3) If neither of the above it used but a URI containing a domain
+       name is present, that domain name should be used.
+   (4) If none of the above is included but a character string name is
+       included, then it should be treated as described for PGP names in
+       3.2 below.
+   (5) If none of the above apply, then the distinguished name (DN)
+       should be mapped into a domain name as specified in RFC 2247.
+
+   Example 1: Assume that an X.509v3 certificate is issued to /CN=John
+   Doe/DC=Doe/DC=com/DC=xy/O=Doe Inc/C=XY/ with Subject Alternative
+   names of (a) string "John (the Man) Doe", (b) domain name john-
+   doe.com, and (c) uri <https://www.secure.john-doe.com:8080/>.  Then
+   the storage locations recommended, in priority order, would be
+       (1) john-doe.com,
+       (2) www.secure.john-doe.com, and
+       (3) Doe.com.xy.
+
+   Example 2:  Assume that an X.509v3 certificate is issued to /CN=James
+   Hacker/L=Basingstoke/O=Widget Inc/C=GB/ with Subject Alternate names
+   of (a) domain name widget.foo.example, (b) IPv4 address
+   10.251.13.201, and (c) string "James Hacker
+   <hacker@mail.widget.foo.example>".  Then the storage locations
+   recommended, in priority order, would be
+        (1) widget.foo.example,
+        (2) 201.13.251.10.in-addr.arpa, and
+        (3) hacker.mail.widget.foo.example.
+
+3.2 PGP CERT RR Names
+
+   PGP signed keys (certificates) use a general character string User ID
+   [RFC 2440]. However, it is recommended by PGP that such names include
+   the RFC 822 email address of the party, as in "Leslie Example
+   <Leslie@host.example>".  If such a format is used, the CERT should be
+   under the standard translation of the email address into a domain
+   name, which would be leslie.host.example in this case.  If no RFC 822
+   name can be extracted from the string name no specific domain name is
+   recommended.
+
+4. Performance Considerations
+
+   Current Domain Name System (DNS) implementations are optimized for
+   small transfers, typically not more than 512 bytes including
+   overhead.  While larger transfers will perform correctly and work is
+
+
+
+Eastlake & Gudmundsson      Standards Track                     [Page 6]
+
+RFC 2538            Storing Certificates in the DNS           March 1999
+
+
+   underway to make larger transfers more efficient, it is still
+   advisable at this time to make every reasonable effort to minimize
+   the size of certificates stored within the DNS.  Steps that can be
+   taken may include using the fewest possible optional or extensions
+   fields and using short field values for variable length fields that
+   must be included.
+
+5. IANA Considerations
+
+   Certificate types 0x0000 through 0x00FF and 0xFF00 through 0xFFFF can
+   only be assigned by an IETF standards action [RFC 2434] (and this
+   document assigns 0x0001 through 0x0003 and 0x00FD and 0x00FE).
+   Certificate types 0x0100 through 0xFEFF are assigned through IETF
+   Consensus [RFC 2434] based on RFC documentation of the certificate
+   type.  The availability of private types under 0x00FD and 0x00FE
+   should satisfy most requirements for proprietary or private types.
+
+6. Security Considerations
+
+   By definition, certificates contain their own authenticating
+   signature.  Thus it is reasonable to store certificates in non-secure
+   DNS zones or to retrieve certificates from DNS with DNS security
+   checking not implemented or deferred for efficiency.  The results MAY
+   be trusted if the certificate chain is verified back to a known
+   trusted key and this conforms with the user's security policy.
+
+   Alternatively, if certificates are retrieved from a secure DNS zone
+   with DNS security checking enabled and are verified by DNS security,
+   the key within the retrieved certificate MAY be trusted without
+   verifying the certificate chain if this conforms with the user's
+   security policy.
+
+   CERT RRs are not used in connection with securing the DNS security
+   additions so there are no security considerations related to CERT RRs
+   and securing the DNS itself.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake & Gudmundsson      Standards Track                     [Page 7]
+
+RFC 2538            Storing Certificates in the DNS           March 1999
+
+
+References
+
+   RFC 1034   Mockapetris, P., "Domain Names - Concepts and Facilities",
+              STD 13, RFC 1034, November 1987.
+
+   RFC 1035   Mockapetris, P., "Domain Names - Implementation and
+              Specifications", STD 13, RFC 1035, November 1987.
+
+   RFC 2119   Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   RFC 2247   Kille, S., Wahl, M., Grimstad, A., Huber, R. and S.
+              Sataluri, "Using Domains in LDAP/X.500 Distinguished
+              Names", RFC 2247, January 1998.
+
+   RFC 2396   Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
+              Resource Identifiers (URI): Generic Syntax", RFC 2396,
+              August 1998.
+
+   RFC 2440   Callas, J., Donnerhacke, L., Finney, H. and R.  Thayer,
+              "OpenPGP Message Format", RFC 2240, November 1998.
+
+   RFC 2434   Narten, T. and H. Alvestrand, "Guidelines for Writing an
+              IANA Considerations Section in RFCs", BCP 26, RFC 2434,
+              October 1998.
+
+   RFC 2535   Eastlake, D., "Domain Name System (DNS) Security
+              Extensions", RFC 2535, March 1999.
+
+   RFC 2459   Housley, R., Ford, W., Polk, W. and D. Solo, "Internet
+              X.509 Public Key Infrastructure Certificate and CRL
+              Profile", RFC 2459, January 1999.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake & Gudmundsson      Standards Track                     [Page 8]
+
+RFC 2538            Storing Certificates in the DNS           March 1999
+
+
+Authors' Addresses
+
+   Donald E. Eastlake 3rd
+   IBM
+   65 Shindegan Hill Road
+   RR#1
+   Carmel, NY 10512 USA
+
+   Phone:   +1-914-784-7913 (w)
+            +1-914-276-2668 (h)
+   Fax:     +1-914-784-3833 (w-fax)
+   EMail:   dee3@us.ibm.com
+
+
+   Olafur Gudmundsson
+   TIS Labs at Network Associates
+   3060 Washington Rd, Route 97
+   Glenwood MD 21738
+
+   Phone: +1 443-259-2389
+   EMail: ogud@tislabs.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake & Gudmundsson      Standards Track                     [Page 9]
+
+RFC 2538            Storing Certificates in the DNS           March 1999
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (1999).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake & Gudmundsson      Standards Track                    [Page 10]
+
diff --git a/doc/rfc/rfc2539.txt b/doc/rfc/rfc2539.txt
new file mode 100644
index 0000000..cf32523
--- /dev/null
+++ b/doc/rfc/rfc2539.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Network Working Group                                        D. Eastlake
+Request for Comments: 2539                                           IBM
+Category: Standards Track                                     March 1999
+
+
+     Storage of Diffie-Hellman Keys in the Domain Name System (DNS)
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1999).  All Rights Reserved.
+
+Abstract
+
+   A standard method for storing Diffie-Hellman keys in the Domain Name
+   System is described which utilizes DNS KEY resource records.
+
+Acknowledgements
+
+   Part of the format for Diffie-Hellman keys and the description
+   thereof was taken from a work in progress by:
+
+      Ashar Aziz <ashar.aziz@eng.sun.com>
+      Tom Markson <markson@incog.com>
+      Hemma Prafullchandra <hemma@eng.sun.com>
+
+   In addition, the following person provided useful comments that have
+   been incorporated:
+
+      Ran Atkinson <rja@inet.org>
+      Thomas Narten <narten@raleigh.ibm.com>
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake                    Standards Track                     [Page 1]
+
+RFC 2539             Diffie-Hellman Keys in the DNS           March 1999
+
+
+Table of Contents
+
+   Abstract...................................................1
+   Acknowledgements...........................................1
+   1. Introduction............................................2
+   1.1 About This Document....................................2
+   1.2 About Diffie-Hellman...................................2
+   2. Diffie-Hellman KEY Resource Records.....................3
+   3. Performance Considerations..............................4
+   4. IANA Considerations.....................................4
+   5. Security Considerations.................................4
+   References.................................................5
+   Author's Address...........................................5
+   Appendix A: Well known prime/generator pairs...............6
+   A.1. Well-Known Group 1:  A 768 bit prime..................6
+   A.2. Well-Known Group 2:  A 1024 bit prime.................6
+   Full Copyright Notice......................................7
+
+1. Introduction
+
+   The Domain Name System (DNS) is the current global hierarchical
+   replicated distributed database system for Internet addressing, mail
+   proxy, and similar information. The DNS has been extended to include
+   digital signatures and cryptographic keys as described in [RFC 2535].
+   Thus the DNS can now be used for secure key distribution.
+
+1.1 About This Document
+
+   This document describes how to store Diffie-Hellman keys in the DNS.
+   Familiarity with the Diffie-Hellman key exchange algorithm is assumed
+   [Schneier].
+
+1.2 About Diffie-Hellman
+
+   Diffie-Hellman requires two parties to interact to derive keying
+   information which can then be used for authentication.  Since DNS SIG
+   RRs are primarily used as stored authenticators of zone information
+   for many different resolvers, no Diffie-Hellman algorithm SIG RR is
+   defined. For example, assume that two parties have local secrets "i"
+   and "j".  Assume they each respectively calculate X and Y as follows:
+
+                X = g**i ( mod p ) Y = g**j ( mod p )
+
+   They exchange these quantities and then each calculates a Z as
+   follows:
+
+                Zi = Y**i ( mod p ) Zj = X**j ( mod p )
+
+
+
+
+Eastlake                    Standards Track                     [Page 2]
+
+RFC 2539             Diffie-Hellman Keys in the DNS           March 1999
+
+
+   shared secret between the two parties that an adversary who does not
+   know i or j will not be able to learn from the exchanged messages
+   (unless the adversary can derive i or j by performing a discrete
+   logarithm mod p which is hard for strong p and g).
+
+   The private key for each party is their secret i (or j).  The public
+   key is the pair p and g, which must be the same for the parties, and
+   their individual X (or Y).
+
+2. Diffie-Hellman KEY Resource Records
+
+   Diffie-Hellman keys are stored in the DNS as KEY RRs using algorithm
+   number 2.  The structure of the RDATA portion of this RR is as shown
+   below.  The first 4 octets, including the flags, protocol, and
+   algorithm fields are common to all KEY RRs as described in [RFC
+   2535].  The remainder, from prime length through public value is the
+   "public key" part of the KEY RR. The period of key validity is not in
+   the KEY RR but is indicated by the SIG RR(s) which signs and
+   authenticates the KEY RR(s) at that domain name.
+
+                         1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
+     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |           KEY flags           |    protocol   |  algorithm=2  |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |     prime length (or flag)    |  prime (p) (or special)       /
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    /  prime (p)  (variable length) |       generator length        |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    | generator (g) (variable length)                               |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |     public value length       | public value (variable length)/
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    /  public value (g^i mod p)    (variable length)                |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Prime length is length of the Diffie-Hellman prime (p) in bytes if it
+   is 16 or greater.  Prime contains the binary representation of the
+   Diffie-Hellman prime with most significant byte first (i.e., in
+   network order). If "prime length" field is 1 or 2, then the "prime"
+   field is actually an unsigned index into a table of 65,536
+   prime/generator pairs and the generator length SHOULD be zero.  See
+   Appedix A for defined table entries and Section 4 for information on
+   allocating additional table entries.  The meaning of a zero or 3
+   through 15 value for "prime length" is reserved.
+
+
+
+
+
+
+Eastlake                    Standards Track                     [Page 3]
+
+RFC 2539             Diffie-Hellman Keys in the DNS           March 1999
+
+
+   Generator length is the length of the generator (g) in bytes.
+   Generator is the binary representation of generator with most
+   significant byte first.  PublicValueLen is the Length of the Public
+   Value (g**i (mod p)) in bytes.  PublicValue is the binary
+   representation of the DH public value with most significant byte
+   first.
+
+   The corresponding algorithm=2 SIG resource record is not used so no
+   format for it is defined.
+
+3. Performance Considerations
+
+   Current DNS implementations are optimized for small transfers,
+   typically less than 512 bytes including overhead.  While larger
+   transfers will perform correctly and work is underway to make larger
+   transfers more efficient, it is still advisable to make reasonable
+   efforts to minimize the size of KEY RR sets stored within the DNS
+   consistent with adequate security.  Keep in mind that in a secure
+   zone, an authenticating SIG RR will also be returned.
+
+4. IANA Considerations
+
+   Assignment of meaning to Prime Lengths of 0 and 3 through 15 requires
+   an IETF consensus.
+
+   Well known prime/generator pairs number 0x0000 through 0x07FF can
+   only be assigned by an IETF standards action and this Proposed
+   Standard assigns 0x0001 through 0x0002. Pairs number 0s0800 through
+   0xBFFF can be assigned based on RFC documentation.  Pairs number
+   0xC000 through 0xFFFF are available for private use and are not
+   centrally coordinated. Use of such private pairs outside of a closed
+   environment may result in conflicts.
+
+5. Security Considerations
+
+   Many of the general security consideration in [RFC 2535] apply.  Keys
+   retrieved from the DNS should not be trusted unless (1) they have
+   been securely obtained from a secure resolver or independently
+   verified by the user and (2) this secure resolver and secure
+   obtainment or independent verification conform to security policies
+   acceptable to the user.  As with all cryptographic algorithms,
+   evaluating the necessary strength of the key is important and
+   dependent on local policy.
+
+   In addition, the usual Diffie-Hellman key strength considerations
+   apply. (p-1)/2 should also be prime, g should be primitive mod p, p
+   should be "large", etc.  [Schneier]
+
+
+
+
+Eastlake                    Standards Track                     [Page 4]
+
+RFC 2539             Diffie-Hellman Keys in the DNS           March 1999
+
+
+References
+
+   [RFC 1034]   Mockapetris, P., "Domain Names - Concepts and
+                Facilities", STD 13, RFC 1034, November 1987.
+
+   [RFC 1035]   Mockapetris, P., "Domain Names - Implementation and
+                Specification", STD 13, RFC 1035, November 1987.
+
+   [RFC 2535]   Eastlake, D., "Domain Name System Security Extensions",
+                RFC 2535, March 1999.
+
+   [Schneier]   Bruce Schneier, "Applied Cryptography: Protocols,
+                Algorithms, and Source Code in C", 1996, John Wiley and
+                Sons
+
+Author's Address
+
+   Donald E. Eastlake 3rd
+   IBM
+   65 Shindegan Hill Road, RR #1
+   Carmel, NY 10512
+
+   Phone:   +1-914-276-2668(h)
+            +1-914-784-7913(w)
+   Fax:     +1-914-784-3833(w)
+   EMail:   dee3@us.ibm.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake                    Standards Track                     [Page 5]
+
+RFC 2539             Diffie-Hellman Keys in the DNS           March 1999
+
+
+Appendix A: Well known prime/generator pairs
+
+   These numbers are copied from the IPSEC effort where the derivation
+   of these values is more fully explained and additional information is
+   available.  Richard Schroeppel performed all the mathematical and
+   computational work for this appendix.
+
+A.1. Well-Known Group 1:  A 768 bit prime
+
+   The prime is 2^768 - 2^704 - 1 + 2^64 * { [2^638 pi] + 149686 }.  Its
+   decimal value is
+          155251809230070893513091813125848175563133404943451431320235
+          119490296623994910210725866945387659164244291000768028886422
+          915080371891804634263272761303128298374438082089019628850917
+          0691316593175367469551763119843371637221007210577919
+
+   Prime modulus: Length (32 bit words): 24, Data (hex):
+            FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
+            29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
+            EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
+            E485B576 625E7EC6 F44C42E9 A63A3620 FFFFFFFF FFFFFFFF
+
+   Generator: Length (32 bit words): 1, Data (hex): 2
+
+A.2. Well-Known Group 2:  A 1024 bit prime
+
+   The prime is 2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }.
+   Its decimal value is
+         179769313486231590770839156793787453197860296048756011706444
+         423684197180216158519368947833795864925541502180565485980503
+         646440548199239100050792877003355816639229553136239076508735
+         759914822574862575007425302077447712589550957937778424442426
+         617334727629299387668709205606050270810842907692932019128194
+         467627007
+
+   Prime modulus:  Length (32 bit words): 32, Data (hex):
+            FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
+            29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
+            EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
+            E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
+            EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381
+            FFFFFFFF FFFFFFFF
+
+   Generator: Length (32 bit words):  1, Data (hex): 2
+
+
+
+
+
+
+
+Eastlake                    Standards Track                     [Page 6]
+
+RFC 2539             Diffie-Hellman Keys in the DNS           March 1999
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (1999).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake                    Standards Track                     [Page 7]
+
diff --git a/doc/rfc/rfc2540.txt b/doc/rfc/rfc2540.txt
new file mode 100644
index 0000000..6314806
--- /dev/null
+++ b/doc/rfc/rfc2540.txt
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+Network Working Group                                        D. Eastlake
+Request for Comments: 2540                                           IBM
+Category: Experimental                                        March 1999
+
+
+             Detached Domain Name System (DNS) Information
+
+Status of this Memo
+
+   This memo defines an Experimental Protocol for the Internet
+   community.  It does not specify an Internet standard of any kind.
+   Discussion and suggestions for improvement are requested.
+   Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1999).  All Rights Reserved.
+
+Abstract
+
+   A standard format is defined for representing detached DNS
+   information.  This is anticipated to be of use for storing
+   information retrieved from the Domain Name System (DNS), including
+   security information, in archival contexts or contexts not connected
+   to the Internet.
+
+Table of Contents
+
+   Abstract...................................................1
+   1. Introduction............................................1
+   2. General Format..........................................2
+   2.1 Binary Format..........................................3
+   2.2. Text Format...........................................4
+   3. Usage Example...........................................4
+   4. IANA Considerations.....................................4
+   5. Security Considerations.................................4
+   References.................................................5
+   Author's Address...........................................5
+   Full Copyright Statement...................................6
+
+1. Introduction
+
+   The Domain Name System (DNS) is a replicated hierarchical distributed
+   database system [RFC 1034, 1035] that can provide highly available
+   service.  It provides the operational basis for Internet host name to
+   address translation, automatic SMTP mail routing, and other basic
+   Internet functions.  The DNS has been extended as described in [RFC
+   2535] to permit the general storage of public cryptographic keys in
+
+
+
+Eastlake                      Experimental                      [Page 1]
+
+RFC 2540                Detached DNS Information              March 1999
+
+
+   the DNS and to enable the authentication of information retrieved
+   from the DNS though digital signatures.
+
+   The DNS was not originally designed for storage of information
+   outside of the active zones and authoritative master files that are
+   part of the connected DNS.  However there may be cases where this is
+   useful, particularly in connection with archived security
+   information.
+
+2. General Format
+
+   The formats used for detached Domain Name System (DNS) information
+   are similar to those used for connected DNS information. The primary
+   difference is that elements of the connected DNS system (unless they
+   are an authoritative server for the zone containing the information)
+   are required to count down the Time To Live (TTL) associated with
+   each DNS Resource Record (RR) and discard them (possibly fetching a
+   fresh copy) when the TTL reaches zero.  In contrast to this, detached
+   information may be stored in a off-line file, where it can not be
+   updated, and perhaps used to authenticate historic data or it might
+   be received via non-DNS protocols long after it was retrieved from
+   the DNS.  Therefore, it is not practical to count down detached DNS
+   information TTL and it may be necessary to keep the data beyond the
+   point where the TTL (which is defined as an unsigned field) would
+   underflow.  To preserve information as to the freshness of this
+   detached data, it is accompanied by its retrieval time.
+
+   Whatever retrieves the information from the DNS must associate this
+   retrieval time with it.  The retrieval time remains fixed thereafter.
+   When the current time minus the retrieval time exceeds the TTL for
+   any particular detached RR, it is no longer a valid copy within the
+   normal connected DNS scheme.  This may make it invalid in context for
+   some detached purposes as well.  If the RR is a SIG (signature) RR it
+   also has an expiration time.  Regardless of the TTL, it and any RRs
+   it signs can not be considered authenticated after the signature
+   expiration time.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake                      Experimental                      [Page 2]
+
+RFC 2540                Detached DNS Information              March 1999
+
+
+2.1 Binary Format
+
+   The standard binary format for detached DNS information is as
+   follows:
+
+                         1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
+     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |                      first retrieval time                     |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |          RR count             |                               |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     Resource Records (RRs)    |
+    /                                                               /
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
+    |                       next retrieval time                     |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |          RR count             |                               |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+     Resource Records (RRs)    |
+    /                                                               /
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    /                              ...                              /
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |     hex 20    |
+    +-+-+-+-+-+-+-+-+
+
+   Retrieval time - the time that the immediately following information
+       was obtained from the connected DNS system.  It is an unsigned
+       number of seconds since the start of 1 January 1970, GMT,
+       ignoring leap seconds, in network (big-endian) order.  Note that
+       this time can not be before the initial proposal of this
+       standard.  Therefore, the initial byte of an actual retrieval
+       time, considered as a 32 bit unsigned quantity, would always be
+       larger than 20 hex.  The end of detached DNS information is
+       indicated by a "retrieval time" field initial byte equal to 0x20.
+       Use of a "retrieval time" field with a leading unsigned byte of
+       zero indicates a 64 bit (actually 8 leading zero bits plus a 56
+       bit quantity).  This 64 bit format will be required when
+       retrieval time is larger than 0xFFFFFFFF, which is some time in
+       the year 2106.  The meaning of retrieval times with an initial
+       byte between 0x01 and 0x1F is reserved (see section 5).
+       Retrieval times will not generally be 32 bit aligned with respect
+       to each other due to the variable length nature of RRs.
+
+   RR count - an unsigned integer number (with bytes in network order)
+       of following resource records retrieved at the preceding
+       retrieval time.
+
+
+
+
+
+Eastlake                      Experimental                      [Page 3]
+
+RFC 2540                Detached DNS Information              March 1999
+
+
+   Resource Records - the actual data which is in the same format as if
+       it were being transmitted in a DNS response.  In particular, name
+       compression via pointers is permitted with the origin at the
+       beginning of the particular detached information data section,
+       just after the RR count.
+
+2.2. Text Format
+
+   The standard text format for detached DNS information is as
+   prescribed for zone master files [RFC 1035] except that the $INCLUDE
+   control entry is prohibited and the new $DATE entry is required
+   (unless the information set is empty). $DATE is followed by the date
+   and time that the following information was obtained from the DNS
+   system as described for retrieval time in section 2.1 above.  It is
+   in the text format YYYYMMDDHHMMSS where YYYY is the year (which may
+   be more than four digits to cover years after 9999), the first MM is
+   the month number (01-12), DD is the day of the month (01-31), HH is
+   the hour in 24 hours notation (00-23), the second MM is the minute
+   (00-59), and SS is the second (00-59).  Thus a $DATE must appear
+   before the first RR and at every change in retrieval time through the
+   detached information.
+
+3. Usage Example
+
+   A document might be authenticated by a key retrieved from the DNS in
+   a KEY resource record (RR).  To later prove the authenticity of this
+   document, it would be desirable to preserve the KEY RR for that
+   public key, the SIG RR signing that KEY RR, the KEY RR for the key
+   used to authenticate that SIG, and so on through SIG and KEY RRs
+   until a well known trusted key is reached, perhaps the key for the
+   DNS root or some third party authentication service. (In some cases
+   these KEY RRs will actually be sets of KEY RRs with the same owner
+   and class because SIGs actually sign such record sets.)
+
+   This information could be preserved as a set of detached DNS
+   information blocks.
+
+4. IANA Considerations
+
+   Allocation of meanings to retrieval time fields with a initial byte
+   of between 0x01 and 0x1F requires an IETF consensus.
+
+5. Security Considerations
+
+   The entirety of this document concerns a means to represent detached
+   DNS information.  Such detached resource records may be security
+   relevant and/or secured information as described in [RFC 2535].  The
+   detached format provides no overall security for sets of detached
+
+
+
+Eastlake                      Experimental                      [Page 4]
+
+RFC 2540                Detached DNS Information              March 1999
+
+
+   information or for the association between retrieval time and
+   information.  This can be provided by wrapping the detached
+   information format with some other form of signature.  However, if
+   the detached information is accompanied by SIG RRs, its validity
+   period is indicated in those SIG RRs so the retrieval time might be
+   of secondary importance.
+
+References
+
+   [RFC 1034]   Mockapetris, P., "Domain Names - Concepts and
+                Facilities", STD 13, RFC 1034, November 1987.
+
+   [RFC 1035]   Mockapetris, P., " Domain Names - Implementation and
+                Specifications", STD 13, RFC 1035, November 1987.
+
+   [RFC 2535]   Eastlake, D., "Domain Name System Security Extensions",
+                RFC 2535, March 1999.
+
+Author's Address
+
+   Donald E. Eastlake 3rd
+   IBM
+   65 Shindegan Hill Road, RR #1
+   Carmel, NY 10512
+
+   Phone:   +1-914-276-2668(h)
+            +1-914-784-7913(w)
+   Fax:     +1-914-784-3833(w)
+   EMail:   dee3@us.ibm.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake                      Experimental                      [Page 5]
+
+RFC 2540                Detached DNS Information              March 1999
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (1999).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake                      Experimental                      [Page 6]
+
diff --git a/doc/rfc/rfc2541.txt b/doc/rfc/rfc2541.txt
new file mode 100644
index 0000000..a62ed2b
--- /dev/null
+++ b/doc/rfc/rfc2541.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Network Working Group                                        D. Eastlake
+Request for Comments: 2541                                           IBM
+Category: Informational                                       March 1999
+
+
+                DNS Security Operational Considerations
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1999).  All Rights Reserved.
+
+Abstract
+
+   Secure DNS is based on cryptographic techniques.  A necessary part of
+   the strength of these techniques is careful attention to the
+   operational aspects of key and signature generation, lifetime, size,
+   and storage.  In addition, special attention must be paid to the
+   security of the high level zones, particularly the root zone.  This
+   document discusses these operational aspects for keys and signatures
+   used in connection with the KEY and SIG DNS resource records.
+
+Acknowledgments
+
+   The contributions and suggestions of the following persons (in
+   alphabetic order) are gratefully acknowledged:
+
+         John Gilmore
+         Olafur Gudmundsson
+         Charlie Kaufman
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake                     Informational                      [Page 1]
+
+RFC 2541        DNS Security Operational Considerations       March 1999
+
+
+Table of Contents
+
+   Abstract...................................................1
+   Acknowledgments............................................1
+   1. Introduction............................................2
+   2. Public/Private Key Generation...........................2
+   3. Public/Private Key Lifetimes............................2
+   4. Public/Private Key Size Considerations..................3
+   4.1 RSA Key Sizes..........................................3
+   4.2 DSS Key Sizes..........................................4
+   5. Private Key Storage.....................................4
+   6. High Level Zones, The Root Zone, and The Meta-Root Key..5
+   7. Security Considerations.................................5
+   References.................................................6
+   Author's Address...........................................6
+   Full Copyright Statement...................................7
+
+1. Introduction
+
+   This document describes operational considerations for the
+   generation, lifetime, size, and storage of DNS cryptographic keys and
+   signatures for use in the KEY and SIG resource records [RFC 2535].
+   Particular attention is paid to high level zones and the root zone.
+
+2. Public/Private Key Generation
+
+   Careful generation of all keys is a sometimes overlooked but
+   absolutely essential element in any cryptographically secure system.
+   The strongest algorithms used with the longest keys are still of no
+   use if an adversary can guess enough to lower the size of the likely
+   key space so that it can be exhaustively searched.  Technical
+   suggestions for the generation of random keys will be found in [RFC
+   1750].
+
+   Long term keys are particularly sensitive as they will represent a
+   more valuable target and be subject to attack for a longer time than
+   short period keys.  It is strongly recommended that long term key
+   generation occur off-line in a manner isolated from the network via
+   an air gap or, at a minimum, high level secure hardware.
+
+3. Public/Private Key Lifetimes
+
+   No key should be used forever.  The longer a key is in use, the
+   greater the probability that it will have been compromised through
+   carelessness, accident, espionage, or cryptanalysis.  Furthermore, if
+
+
+
+
+
+
+Eastlake                     Informational                      [Page 2]
+
+RFC 2541        DNS Security Operational Considerations       March 1999
+
+
+   key rollover is a rare event, there is an increased risk that, when
+   the time does come to change the key, no one at the site will
+   remember how to do it or operational problems will have developed in
+   the key rollover procedures.
+
+   While public key lifetime is a matter of local policy, these
+   considerations imply that, unless there are extraordinary
+   circumstances, no long term key should have a lifetime significantly
+   over four years.  In fact, a reasonable guideline for long term keys
+   that are kept off-line and carefully guarded is a 13 month lifetime
+   with the intent that they be replaced every year.  A reasonable
+   maximum lifetime for keys that are used for transaction security or
+   the like and are kept on line is 36 days with the intent that they be
+   replaced monthly or more often.  In many cases, a key lifetime of
+   somewhat over a day may be reasonable.
+
+   On the other hand, public keys with too short a lifetime can lead to
+   excessive resource consumption in re-signing data and retrieving
+   fresh information because cached information becomes stale.  In the
+   Internet environment, almost all public keys should have lifetimes no
+   shorter than three minutes, which is a reasonable estimate of maximum
+   packet delay even in unusual circumstances.
+
+4. Public/Private Key Size Considerations
+
+   There are a number of factors that effect public key size choice for
+   use in the DNS security extension.  Unfortunately, these factors
+   usually do not all point in the same direction.  Choice of zone key
+   size should generally be made by the zone administrator depending on
+   their local conditions.
+
+   For most schemes, larger keys are more secure but slower.  In
+   addition, larger keys increase the size of the KEY and SIG RRs.  This
+   increases the chance of DNS UDP packet overflow and the possible
+   necessity for using higher overhead TCP in responses.
+
+4.1 RSA Key Sizes
+
+   Given a small public exponent, verification (the most common
+   operation) for the MD5/RSA algorithm will vary roughly with the
+   square of the modulus length, signing will vary with the cube of the
+   modulus length, and key generation (the least common operation) will
+   vary with the fourth power of the modulus length.  The current best
+   algorithms for factoring a modulus and breaking RSA security vary
+   roughly with the 1.6 power of the modulus itself.  Thus going from a
+   640 bit modulus to a 1280 bit modulus only increases the verification
+   time by a factor of 4 but may increase the work factor of breaking
+   the key by over 2^900.
+
+
+
+Eastlake                     Informational                      [Page 3]
+
+RFC 2541        DNS Security Operational Considerations       March 1999
+
+
+   The recommended minimum RSA algorithm modulus size is 704 bits which
+   is believed by the author to be secure at this time.  But high level
+   zones in the DNS tree may wish to set a higher minimum, perhaps 1000
+   bits, for security reasons.  (Since the United States National
+   Security Agency generally permits export of encryption systems using
+   an RSA modulus of up to 512 bits, use of that small a modulus, i.e.
+   n, must be considered weak.)
+
+   For an RSA key used only to secure data and not to secure other keys,
+   704 bits should be adequate at this time.
+
+4.2 DSS Key Sizes
+
+   DSS keys are probably roughly as strong as an RSA key of the same
+   length but DSS signatures are significantly smaller.
+
+5. Private Key Storage
+
+   It is recommended that, where possible, zone private keys and the
+   zone file master copy be kept and used in off-line, non-network
+   connected, physically secure machines only.  Periodically an
+   application can be run to add authentication to a zone by adding SIG
+   and NXT RRs and adding no-key type KEY RRs for subzones/algorithms
+   where a real KEY RR for the subzone with that algorithm is not
+   provided. Then the augmented file can be transferred, perhaps by
+   sneaker-net, to the networked zone primary server machine.
+
+   The idea is to have a one way information flow to the network to
+   avoid the possibility of tampering from the network.  Keeping the
+   zone master file on-line on the network and simply cycling it through
+   an off-line signer does not do this.  The on-line version could still
+   be tampered with if the host it resides on is compromised.  For
+   maximum security, the master copy of the zone file should be off net
+   and should not be updated based on an unsecured network mediated
+   communication.
+
+   This is not possible if the zone is to be dynamically updated
+   securely [RFC 2137]. At least a private key capable of updating the
+   SOA and NXT chain must be on line in that case.
+
+   Secure resolvers must be configured with some trusted on-line public
+   key information (or a secure path to such a resolver) or they will be
+   unable to authenticate.  Although on line, this public key
+   information must be protected or it could be altered so that spoofed
+   DNS data would appear authentic.
+
+
+
+
+
+
+Eastlake                     Informational                      [Page 4]
+
+RFC 2541        DNS Security Operational Considerations       March 1999
+
+
+   Non-zone private keys, such as host or user keys, generally have to
+   be kept on line to be used for real-time purposes such as DNS
+   transaction security.
+
+6. High Level Zones, The Root Zone, and The Meta-Root Key
+
+   Higher level zones are generally more sensitive than lower level
+   zones.  Anyone controlling or breaking the security of a zone thereby
+   obtains authority over all of its subdomains (except in the case of
+   resolvers that have locally configured the public key of a
+   subdomain).  Therefore, extra care should be taken with high level
+   zones and strong keys used.
+
+   The root zone is the most critical of all zones.  Someone controlling
+   or compromising the security of the root zone would control the
+   entire DNS name space of all resolvers using that root zone (except
+   in the case of resolvers that have locally configured the public key
+   of a subdomain). Therefore, the utmost care must be taken in the
+   securing of the root zone. The strongest and most carefully handled
+   keys should be used.  The root zone private key should always be kept
+   off line.
+
+   Many resolvers will start at a root server for their access to and
+   authentication of DNS data.  Securely updating an enormous population
+   of resolvers around the world will be extremely difficult.  Yet the
+   guidelines in section 3 above would imply that the root zone private
+   key be changed annually or more often and if it were staticly
+   configured at all these resolvers, it would have to be updated when
+   changed.
+
+   To permit relatively frequent change to the root zone key yet
+   minimize exposure of the ultimate key of the DNS tree, there will be
+   a "meta-root" key used very rarely and then only to sign a sequence
+   of regular root key RRsets with overlapping time validity periods
+   that are to be rolled out. The root zone contains the meta-root and
+   current regular root KEY RR(s) signed by SIG RRs under both the
+   meta-root and other root private key(s) themselves.
+
+   The utmost security in the storage and use of the meta-root key is
+   essential.  The exact techniques are precautions to be used are
+   beyond the scope of this document.  Because of its special position,
+   it may be best to continue with the same meta-root key for an
+   extended period of time such as ten to fifteen years.
+
+7. Security Considerations
+
+   The entirety of this document is concerned with operational
+   considerations of public/private key pair DNS Security.
+
+
+
+Eastlake                     Informational                      [Page 5]
+
+RFC 2541        DNS Security Operational Considerations       March 1999
+
+
+References
+
+   [RFC 1034]   Mockapetris, P., "Domain Names - Concepts and
+                Facilities", STD 13, RFC 1034, November 1987.
+
+   [RFC 1035]   Mockapetris, P., "Domain Names - Implementation and
+                Specifications", STD 13, RFC 1035, November 1987.
+
+   [RFC 1750]   Eastlake, D., Crocker, S. and J. Schiller, "Randomness
+                Requirements for Security", RFC 1750, December 1994.
+
+   [RFC 2065]   Eastlake, D. and C. Kaufman, "Domain Name System
+                Security Extensions", RFC 2065, January 1997.
+
+   [RFC 2137]   Eastlake, D., "Secure Domain Name System Dynamic
+                Update", RFC 2137, April 1997.
+
+   [RFC 2535]   Eastlake, D., "Domain Name System Security Extensions",
+                RFC 2535, March 1999.
+
+   [RSA FAQ]    RSADSI Frequently Asked Questions periodic posting.
+
+Author's Address
+
+   Donald E. Eastlake 3rd
+   IBM
+   65 Shindegan Hill Road, RR #1
+   Carmel, NY 10512
+
+   Phone:   +1-914-276-2668(h)
+            +1-914-784-7913(w)
+   Fax:     +1-914-784-3833(w)
+   EMail:   dee3@us.ibm.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake                     Informational                      [Page 6]
+
+RFC 2541        DNS Security Operational Considerations       March 1999
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (1999).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake                     Informational                      [Page 7]
+
diff --git a/doc/rfc/rfc2553.txt b/doc/rfc/rfc2553.txt
new file mode 100644
index 0000000..6989bf3
--- /dev/null
+++ b/doc/rfc/rfc2553.txt
@@ -0,0 +1,2299 @@
+
+
+
+
+
+
+Network Working Group                                        R. Gilligan
+Request for Comments: 2553                                      FreeGate
+Obsoletes: 2133                                               S. Thomson
+Category: Informational                                         Bellcore
+                                                                J. Bound
+                                                                  Compaq
+                                                              W. Stevens
+                                                              Consultant
+                                                              March 1999
+
+
+               Basic Socket Interface Extensions for IPv6
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1999).  All Rights Reserved.
+
+Abstract
+
+   The de facto standard application program interface (API) for TCP/IP
+   applications is the "sockets" interface.  Although this API was
+   developed for Unix in the early 1980s it has also been implemented on
+   a wide variety of non-Unix systems.  TCP/IP applications written
+   using the sockets API have in the past enjoyed a high degree of
+   portability and we would like the same portability with IPv6
+   applications.  But changes are required to the sockets API to support
+   IPv6 and this memo describes these changes.  These include a new
+   socket address structure to carry IPv6 addresses, new address
+   conversion functions, and some new socket options.  These extensions
+   are designed to provide access to the basic IPv6 features required by
+   TCP and UDP applications, including multicasting, while introducing a
+   minimum of change into the system and providing complete
+   compatibility for existing IPv4 applications.  Additional extensions
+   for advanced IPv6 features (raw sockets and access to the IPv6
+   extension headers) are defined in another document [4].
+
+
+
+
+
+
+
+
+
+
+Gilligan, et. al.            Informational                      [Page 1]
+
+RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
+
+
+Table of Contents
+
+   1. Introduction.................................................3
+   2. Design Considerations........................................3
+   2.1 What Needs to be Changed....................................4
+   2.2 Data Types..................................................5
+   2.3 Headers.....................................................5
+   2.4 Structures..................................................5
+   3. Socket Interface.............................................6
+   3.1 IPv6 Address Family and Protocol Family.....................6
+   3.2 IPv6 Address Structure......................................6
+   3.3 Socket Address Structure for 4.3BSD-Based Systems...........7
+   3.4 Socket Address Structure for 4.4BSD-Based Systems...........8
+   3.5 The Socket Functions........................................9
+   3.6 Compatibility with IPv4 Applications.......................10
+   3.7 Compatibility with IPv4 Nodes..............................10
+   3.8 IPv6 Wildcard Address......................................11
+   3.9 IPv6 Loopback Address......................................12
+   3.10 Portability Additions.....................................13
+   4. Interface Identification....................................16
+   4.1 Name-to-Index..............................................16
+   4.2 Index-to-Name..............................................17
+   4.3 Return All Interface Names and Indexes.....................17
+   4.4 Free Memory................................................18
+   5. Socket Options..............................................18
+   5.1 Unicast Hop Limit..........................................18
+   5.2 Sending and Receiving Multicast Packets....................19
+   6. Library Functions...........................................21
+   6.1 Nodename-to-Address Translation............................21
+   6.2 Address-To-Nodename Translation............................24
+   6.3 Freeing memory for getipnodebyname and getipnodebyaddr.....26
+   6.4 Protocol-Independent Nodename and Service Name Translation.26
+   6.5 Socket Address Structure to Nodename and Service Name......29
+   6.6 Address Conversion Functions...............................31
+   6.7 Address Testing Macros.....................................32
+   7. Summary of New Definitions..................................33
+   8. Security Considerations.....................................35
+   9. Year 2000 Considerations....................................35
+   Changes From RFC 2133..........................................35
+   Acknowledgments................................................38
+   References.....................................................39
+   Authors' Addresses.............................................40
+   Full Copyright Statement.......................................41
+
+
+
+
+
+
+
+
+Gilligan, et. al.            Informational                      [Page 2]
+
+RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
+
+
+1. Introduction
+
+   While IPv4 addresses are 32 bits long, IPv6 interfaces are identified
+   by 128-bit addresses.  The socket interface makes the size of an IP
+   address quite visible to an application; virtually all TCP/IP
+   applications for BSD-based systems have knowledge of the size of an
+   IP address.  Those parts of the API that expose the addresses must be
+   changed to accommodate the larger IPv6 address size.  IPv6 also
+   introduces new features (e.g., traffic class and flowlabel), some of
+   which must be made visible to applications via the API.  This memo
+   defines a set of extensions to the socket interface to support the
+   larger address size and new features of IPv6.
+
+2. Design Considerations
+
+   There are a number of important considerations in designing changes
+   to this well-worn API:
+
+      - The API changes should provide both source and binary
+        compatibility for programs written to the original API.  That
+        is, existing program binaries should continue to operate when
+        run on a system supporting the new API.  In addition, existing
+        applications that are re-compiled and run on a system supporting
+        the new API should continue to operate.  Simply put, the API
+        changes for IPv6 should not break existing programs.  An
+        additonal mechanism for implementations to verify this is to
+        verify the new symbols are protected by Feature Test Macros as
+        described in IEEE Std 1003.1.  (Such Feature Test Macros are not
+        defined by this RFC.)
+
+      - The changes to the API should be as small as possible in order
+        to simplify the task of converting existing IPv4 applications to
+        IPv6.
+
+      - Where possible, applications should be able to use this API to
+        interoperate with both IPv6 and IPv4 hosts.  Applications should
+        not need to know which type of host they are communicating with.
+
+      - IPv6 addresses carried in data structures should be 64-bit
+        aligned.  This is necessary in order to obtain optimum
+        performance on 64-bit machine architectures.
+
+   Because of the importance of providing IPv4 compatibility in the API,
+   these extensions are explicitly designed to operate on machines that
+   provide complete support for both IPv4 and IPv6.  A subset of this
+   API could probably be designed for operation on systems that support
+   only IPv6.  However, this is not addressed in this memo.
+
+
+
+
+Gilligan, et. al.            Informational                      [Page 3]
+
+RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
+
+
+2.1 What Needs to be Changed
+
+   The socket interface API consists of a few distinct components:
+
+      -  Core socket functions.
+
+      -  Address data structures.
+
+      -  Name-to-address translation functions.
+
+      -  Address conversion functions.
+
+   The core socket functions -- those functions that deal with such
+   things as setting up and tearing down TCP connections, and sending
+   and receiving UDP packets -- were designed to be transport
+   independent.  Where protocol addresses are passed as function
+   arguments, they are carried via opaque pointers.  A protocol-specific
+   address data structure is defined for each protocol that the socket
+   functions support.  Applications must cast pointers to these
+   protocol-specific address structures into pointers to the generic
+   "sockaddr" address structure when using the socket functions.  These
+   functions need not change for IPv6, but a new IPv6-specific address
+   data structure is needed.
+
+   The "sockaddr_in" structure is the protocol-specific data structure
+   for IPv4.  This data structure actually includes 8-octets of unused
+   space, and it is tempting to try to use this space to adapt the
+   sockaddr_in structure to IPv6.  Unfortunately, the sockaddr_in
+   structure is not large enough to hold the 16-octet IPv6 address as
+   well as the other information (address family and port number) that
+   is needed.  So a new address data structure must be defined for IPv6.
+
+   IPv6 addresses are scoped [2] so they could be link-local, site,
+   organization, global, or other scopes at this time undefined.  To
+   support applications that want to be able to identify a set of
+   interfaces for a specific scope, the IPv6 sockaddr_in structure must
+   support a field that can be used by an implementation to identify a
+   set of interfaces identifying the scope for an IPv6 address.
+
+   The name-to-address translation functions in the socket interface are
+   gethostbyname() and gethostbyaddr().  These are left as is and new
+   functions are defined to support IPv4 and IPv6.  Additionally, the
+   POSIX 1003.g draft [3] specifies a new nodename-to-address
+   translation function which is protocol independent.  This function
+   can also be used with IPv4 and IPv6.
+
+
+
+
+
+
+Gilligan, et. al.            Informational                      [Page 4]
+
+RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
+
+
+   The address conversion functions -- inet_ntoa() and inet_addr() --
+   convert IPv4 addresses between binary and printable form.  These
+   functions are quite specific to 32-bit IPv4 addresses.  We have
+   designed two analogous functions that convert both IPv4 and IPv6
+   addresses, and carry an address type parameter so that they can be
+   extended to other protocol families as well.
+
+   Finally, a few miscellaneous features are needed to support IPv6.
+   New interfaces are needed to support the IPv6 traffic class, flow
+   label, and hop limit header fields.  New socket options are needed to
+   control the sending and receiving of IPv6 multicast packets.
+
+   The socket interface will be enhanced in the future to provide access
+   to other IPv6 features.  These extensions are described in [4].
+
+2.2 Data Types
+
+   The data types of the structure elements given in this memo are
+   intended to be examples, not absolute requirements.  Whenever
+   possible, data types from Draft 6.6 (March 1997) of POSIX 1003.1g are
+   used: uintN_t means an unsigned integer of exactly N bits (e.g.,
+   uint16_t).  We also assume the argument data types from 1003.1g when
+   possible (e.g., the final argument to setsockopt() is a size_t
+   value).  Whenever buffer sizes are specified, the POSIX 1003.1 size_t
+   data type is used (e.g., the two length arguments to getnameinfo()).
+
+2.3 Headers
+
+   When function prototypes and structures are shown we show the headers
+   that must be #included to cause that item to be defined.
+
+2.4 Structures
+
+   When structures are described the members shown are the ones that
+   must appear in an implementation.  Additional, nonstandard members
+   may also be defined by an implementation.  As an additional
+   precaution nonstandard members could be verified by Feature Test
+   Macros as described in IEEE Std 1003.1.  (Such Feature Test Macros
+   are not defined by this RFC.)
+
+   The ordering shown for the members of a structure is the recommended
+   ordering, given alignment considerations of multibyte members, but an
+   implementation may order the members differently.
+
+
+
+
+
+
+
+
+Gilligan, et. al.            Informational                      [Page 5]
+
+RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
+
+
+3. Socket Interface
+
+   This section specifies the socket interface changes for IPv6.
+
+3.1 IPv6 Address Family and Protocol Family
+
+   A new address family name, AF_INET6, is defined in <sys/socket.h>.
+   The AF_INET6 definition distinguishes between the original
+   sockaddr_in address data structure, and the new sockaddr_in6 data
+   structure.
+
+   A new protocol family name, PF_INET6, is defined in <sys/socket.h>.
+   Like most of the other protocol family names, this will usually be
+   defined to have the same value as the corresponding address family
+   name:
+
+      #define PF_INET6        AF_INET6
+
+   The PF_INET6 is used in the first argument to the socket() function
+   to indicate that an IPv6 socket is being created.
+
+3.2 IPv6 Address Structure
+
+   A new in6_addr structure holds a single IPv6 address and is defined
+   as a result of including <netinet/in.h>:
+
+      struct in6_addr {
+          uint8_t  s6_addr[16];      /* IPv6 address */
+      };
+
+   This data structure contains an array of sixteen 8-bit elements,
+   which make up one 128-bit IPv6 address.  The IPv6 address is stored
+   in network byte order.
+
+   The structure in6_addr above is usually implemented with an embedded
+   union with extra fields that force the desired alignment level in a
+   manner similar to BSD implementations of "struct in_addr". Those
+   additional implementation details are omitted here for simplicity.
+
+   An example is as follows:
+
+
+
+
+
+
+
+
+
+
+
+Gilligan, et. al.            Informational                      [Page 6]
+
+RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
+
+
+   struct in6_addr {
+        union {
+            uint8_t  _S6_u8[16];
+            uint32_t _S6_u32[4];
+            uint64_t _S6_u64[2];
+        } _S6_un;
+   };
+   #define s6_addr _S6_un._S6_u8
+
+3.3 Socket Address Structure for 4.3BSD-Based Systems
+
+   In the socket interface, a different protocol-specific data structure
+   is defined to carry the addresses for each protocol suite.  Each
+   protocol- specific data structure is designed so it can be cast into a
+   protocol- independent data structure -- the "sockaddr" structure.
+   Each has a "family" field that overlays the "sa_family" of the
+   sockaddr data structure.  This field identifies the type of the data
+   structure.
+
+   The sockaddr_in structure is the protocol-specific address data
+   structure for IPv4.  It is used to pass addresses between applications
+   and the system in the socket functions.  The following sockaddr_in6
+   structure holds IPv6 addresses and is defined as a result of including
+   the <netinet/in.h> header:
+
+struct sockaddr_in6 {
+    sa_family_t     sin6_family;    /* AF_INET6 */
+    in_port_t       sin6_port;      /* transport layer port # */
+    uint32_t        sin6_flowinfo;  /* IPv6 traffic class & flow info */
+    struct in6_addr sin6_addr;      /* IPv6 address */
+    uint32_t        sin6_scope_id;  /* set of interfaces for a scope */
+};
+
+   This structure is designed to be compatible with the sockaddr data
+   structure used in the 4.3BSD release.
+
+   The sin6_family field identifies this as a sockaddr_in6 structure.
+   This field overlays the sa_family field when the buffer is cast to a
+   sockaddr data structure.  The value of this field must be AF_INET6.
+
+   The sin6_port field contains the 16-bit UDP or TCP port number.  This
+   field is used in the same way as the sin_port field of the
+   sockaddr_in structure.  The port number is stored in network byte
+   order.
+
+
+
+
+
+
+
+Gilligan, et. al.            Informational                      [Page 7]
+
+RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
+
+
+   The sin6_flowinfo field is a 32-bit field that contains two pieces of
+   information: the traffic class and the flow label.  The contents and
+   interpretation of this member is specified in [1].  The sin6_flowinfo
+   field SHOULD be set to zero by an implementation prior to using the
+   sockaddr_in6 structure by an application on receive operations.
+
+   The sin6_addr field is a single in6_addr structure (defined in the
+   previous section).  This field holds one 128-bit IPv6 address.  The
+   address is stored in network byte order.
+
+   The ordering of elements in this structure is specifically designed
+   so that when sin6_addr field is aligned on a 64-bit boundary, the
+   start of the structure will also be aligned on a 64-bit boundary.
+   This is done for optimum performance on 64-bit architectures.
+
+   The sin6_scope_id field is a 32-bit integer that identifies a set of
+   interfaces as appropriate for the scope of the address carried in the
+   sin6_addr field.  For a link scope sin6_addr sin6_scope_id would be
+   an interface index.  For a site scope sin6_addr, sin6_scope_id would
+   be a site identifier.  The mapping of sin6_scope_id to an interface
+   or set of interfaces is left to implementation and future
+   specifications on the subject of site identifiers.
+
+   Notice that the sockaddr_in6 structure will normally be larger than
+   the generic sockaddr structure.  On many existing implementations the
+   sizeof(struct sockaddr_in) equals sizeof(struct sockaddr), with both
+   being 16 bytes.  Any existing code that makes this assumption needs
+   to be examined carefully when converting to IPv6.
+
+3.4 Socket Address Structure for 4.4BSD-Based Systems
+
+   The 4.4BSD release includes a small, but incompatible change to the
+   socket interface.  The "sa_family" field of the sockaddr data
+   structure was changed from a 16-bit value to an 8-bit value, and the
+   space saved used to hold a length field, named "sa_len".  The
+   sockaddr_in6 data structure given in the previous section cannot be
+   correctly cast into the newer sockaddr data structure.  For this
+   reason, the following alternative IPv6 address data structure is
+   provided to be used on systems based on 4.4BSD.  It is defined as a
+   result of including the <netinet/in.h> header.
+
+
+
+
+
+
+
+
+
+
+
+Gilligan, et. al.            Informational                      [Page 8]
+
+RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
+
+
+struct sockaddr_in6 {
+    uint8_t         sin6_len;       /* length of this struct */
+    sa_family_t     sin6_family;    /* AF_INET6 */
+    in_port_t       sin6_port;      /* transport layer port # */
+    uint32_t        sin6_flowinfo;  /* IPv6 flow information */
+    struct in6_addr sin6_addr;      /* IPv6 address */
+    uint32_t        sin6_scope_id;  /* set of interfaces for a scope */
+};
+
+   The only differences between this data structure and the 4.3BSD
+   variant are the inclusion of the length field, and the change of the
+   family field to a 8-bit data type.  The definitions of all the other
+   fields are identical to the structure defined in the previous
+   section.
+
+   Systems that provide this version of the sockaddr_in6 data structure
+   must also declare SIN6_LEN as a result of including the
+   <netinet/in.h> header.  This macro allows applications to determine
+   whether they are being built on a system that supports the 4.3BSD or
+   4.4BSD variants of the data structure.
+
+3.5 The Socket Functions
+
+   Applications call the socket() function to create a socket descriptor
+   that represents a communication endpoint.  The arguments to the
+   socket() function tell the system which protocol to use, and what
+   format address structure will be used in subsequent functions.  For
+   example, to create an IPv4/TCP socket, applications make the call:
+
+      s = socket(PF_INET, SOCK_STREAM, 0);
+
+   To create an IPv4/UDP socket, applications make the call:
+
+      s = socket(PF_INET, SOCK_DGRAM, 0);
+
+   Applications may create IPv6/TCP and IPv6/UDP sockets by simply using
+   the constant PF_INET6 instead of PF_INET in the first argument.  For
+   example, to create an IPv6/TCP socket, applications make the call:
+
+      s = socket(PF_INET6, SOCK_STREAM, 0);
+
+   To create an IPv6/UDP socket, applications make the call:
+
+      s = socket(PF_INET6, SOCK_DGRAM, 0);
+
+
+
+
+
+
+
+Gilligan, et. al.            Informational                      [Page 9]
+
+RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
+
+
+   Once the application has created a PF_INET6 socket, it must use the
+   sockaddr_in6 address structure when passing addresses in to the
+   system.  The functions that the application uses to pass addresses
+   into the system are:
+
+      bind()
+      connect()
+      sendmsg()
+      sendto()
+
+   The system will use the sockaddr_in6 address structure to return
+   addresses to applications that are using PF_INET6 sockets.  The
+   functions that return an address from the system to an application
+   are:
+
+      accept()
+      recvfrom()
+      recvmsg()
+      getpeername()
+      getsockname()
+
+   No changes to the syntax of the socket functions are needed to
+   support IPv6, since all of the "address carrying" functions use an
+   opaque address pointer, and carry an address length as a function
+   argument.
+
+3.6 Compatibility with IPv4 Applications
+
+   In order to support the large base of applications using the original
+   API, system implementations must provide complete source and binary
+   compatibility with the original API.  This means that systems must
+   continue to support PF_INET sockets and the sockaddr_in address
+   structure.  Applications must be able to create IPv4/TCP and IPv4/UDP
+   sockets using the PF_INET constant in the socket() function, as
+   described in the previous section.  Applications should be able to
+   hold a combination of IPv4/TCP, IPv4/UDP, IPv6/TCP and IPv6/UDP
+   sockets simultaneously within the same process.
+
+   Applications using the original API should continue to operate as
+   they did on systems supporting only IPv4.  That is, they should
+   continue to interoperate with IPv4 nodes.
+
+3.7 Compatibility with IPv4 Nodes
+
+   The API also provides a different type of compatibility: the ability
+   for IPv6 applications to interoperate with IPv4 applications.  This
+   feature uses the IPv4-mapped IPv6 address format defined in the IPv6
+   addressing architecture specification [2].  This address format
+
+
+
+Gilligan, et. al.            Informational                     [Page 10]
+
+RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
+
+
+   allows the IPv4 address of an IPv4 node to be represented as an IPv6
+   address.  The IPv4 address is encoded into the low-order 32 bits of
+   the IPv6 address, and the high-order 96 bits hold the fixed prefix
+   0:0:0:0:0:FFFF.  IPv4- mapped addresses are written as follows:
+
+      ::FFFF:<IPv4-address>
+
+   These addresses can be generated automatically by the
+   getipnodebyname() function when the specified host has only IPv4
+   addresses (as described in Section 6.1).
+
+   Applications may use PF_INET6 sockets to open TCP connections to IPv4
+   nodes, or send UDP packets to IPv4 nodes, by simply encoding the
+   destination's IPv4 address as an IPv4-mapped IPv6 address, and
+   passing that address, within a sockaddr_in6 structure, in the
+   connect() or sendto() call.  When applications use PF_INET6 sockets
+   to accept TCP connections from IPv4 nodes, or receive UDP packets
+   from IPv4 nodes, the system returns the peer's address to the
+   application in the accept(), recvfrom(), or getpeername() call using
+   a sockaddr_in6 structure encoded this way.
+
+   Few applications will likely need to know which type of node they are
+   interoperating with.  However, for those applications that do need to
+   know, the IN6_IS_ADDR_V4MAPPED() macro, defined in Section 6.7, is
+   provided.
+
+3.8 IPv6 Wildcard Address
+
+   While the bind() function allows applications to select the source IP
+   address of UDP packets and TCP connections, applications often want
+   the system to select the source address for them.  With IPv4, one
+   specifies the address as the symbolic constant INADDR_ANY (called the
+   "wildcard" address) in the bind() call, or simply omits the bind()
+   entirely.
+
+   Since the IPv6 address type is a structure (struct in6_addr), a
+   symbolic constant can be used to initialize an IPv6 address variable,
+   but cannot be used in an assignment.  Therefore systems provide the
+   IPv6 wildcard address in two forms.
+
+   The first version is a global variable named "in6addr_any" that is an
+   in6_addr structure.  The extern declaration for this variable is
+   defined in <netinet/in.h>:
+
+      extern const struct in6_addr in6addr_any;
+
+
+
+
+
+
+Gilligan, et. al.            Informational                     [Page 11]
+
+RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
+
+
+   Applications use in6addr_any similarly to the way they use INADDR_ANY
+   in IPv4.  For example, to bind a socket to port number 23, but let
+   the system select the source address, an application could use the
+   following code:
+
+      struct sockaddr_in6 sin6;
+       . . .
+      sin6.sin6_family = AF_INET6;
+      sin6.sin6_flowinfo = 0;
+      sin6.sin6_port = htons(23);
+      sin6.sin6_addr = in6addr_any;  /* structure assignment */
+       . . .
+      if (bind(s, (struct sockaddr *) &sin6, sizeof(sin6)) == -1)
+              . . .
+
+   The other version is a symbolic constant named IN6ADDR_ANY_INIT and
+   is defined in <netinet/in.h>.  This constant can be used to
+   initialize an in6_addr structure:
+
+      struct in6_addr anyaddr = IN6ADDR_ANY_INIT;
+
+   Note that this constant can be used ONLY at declaration time.  It can
+   not be used to assign a previously declared in6_addr structure.  For
+   example, the following code will not work:
+
+      /* This is the WRONG way to assign an unspecified address */
+      struct sockaddr_in6 sin6;
+       . . .
+      sin6.sin6_addr = IN6ADDR_ANY_INIT; /* will NOT compile */
+
+   Be aware that the IPv4 INADDR_xxx constants are all defined in host
+   byte order but the IPv6 IN6ADDR_xxx constants and the IPv6
+   in6addr_xxx externals are defined in network byte order.
+
+3.9 IPv6 Loopback Address
+
+   Applications may need to send UDP packets to, or originate TCP
+   connections to, services residing on the local node.  In IPv4, they
+   can do this by using the constant IPv4 address INADDR_LOOPBACK in
+   their connect(), sendto(), or sendmsg() call.
+
+   IPv6 also provides a loopback address to contact local TCP and UDP
+   services.  Like the unspecified address, the IPv6 loopback address is
+   provided in two forms -- a global variable and a symbolic constant.
+
+
+
+
+
+
+
+Gilligan, et. al.            Informational                     [Page 12]
+
+RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
+
+
+   The global variable is an in6_addr structure named
+   "in6addr_loopback."  The extern declaration for this variable is
+   defined in <netinet/in.h>:
+
+      extern const struct in6_addr in6addr_loopback;
+
+   Applications use in6addr_loopback as they would use INADDR_LOOPBACK
+   in IPv4 applications (but beware of the byte ordering difference
+   mentioned at the end of the previous section).  For example, to open
+   a TCP connection to the local telnet server, an application could use
+   the following code:
+
+      struct sockaddr_in6 sin6;
+       . . .
+      sin6.sin6_family = AF_INET6;
+      sin6.sin6_flowinfo = 0;
+      sin6.sin6_port = htons(23);
+      sin6.sin6_addr = in6addr_loopback;  /* structure assignment */
+       . . .
+      if (connect(s, (struct sockaddr *) &sin6, sizeof(sin6)) == -1)
+              . . .
+
+   The symbolic constant is named IN6ADDR_LOOPBACK_INIT and is defined
+   in <netinet/in.h>.  It can be used at declaration time ONLY; for
+   example:
+
+      struct in6_addr loopbackaddr = IN6ADDR_LOOPBACK_INIT;
+
+   Like IN6ADDR_ANY_INIT, this constant cannot be used in an assignment
+   to a previously declared IPv6 address variable.
+
+3.10 Portability Additions
+
+   One simple addition to the sockets API that can help application
+   writers is the "struct sockaddr_storage". This data structure can
+   simplify writing code portable across multiple address families and
+   platforms.  This data structure is designed with the following goals.
+
+      - It has a large enough implementation specific maximum size to
+        store the desired set of protocol specific socket address data
+        structures. Specifically, it is at least large enough to
+        accommodate sockaddr_in and sockaddr_in6 and possibly other
+        protocol specific socket addresses too.
+      - It is aligned at an appropriate boundary so protocol specific
+        socket address data structure pointers can be cast to it and
+        access their fields without alignment problems. (e.g. pointers
+        to sockaddr_in6 and/or sockaddr_in can be cast to it and access
+        fields without alignment problems).
+
+
+
+Gilligan, et. al.            Informational                     [Page 13]
+
+RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
+
+
+      - It has the initial field(s) isomorphic to the fields of the
+        "struct sockaddr" data structure on that implementation which
+        can be used as a discriminants for deriving the protocol in use.
+        These initial field(s) would on most implementations either be a
+        single field of type "sa_family_t" (isomorphic to sa_family
+        field, 16 bits) or two fields of type uint8_t and sa_family_t
+        respectively, (isomorphic to sa_len and sa_family_t, 8 bits
+        each).
+
+   An example implementation design of such a data structure would be as
+   follows.
+
+/*
+ * Desired design of maximum size and alignment
+ */
+#define _SS_MAXSIZE    128  /* Implementation specific max size */
+#define _SS_ALIGNSIZE  (sizeof (int64_t))
+                         /* Implementation specific desired alignment */
+/*
+ * Definitions used for sockaddr_storage structure paddings design.
+ */
+#define _SS_PAD1SIZE   (_SS_ALIGNSIZE - sizeof (sa_family_t))
+#define _SS_PAD2SIZE   (_SS_MAXSIZE - (sizeof (sa_family_t)+
+                              _SS_PAD1SIZE + _SS_ALIGNSIZE))
+struct sockaddr_storage {
+    sa_family_t  __ss_family;     /* address family */
+    /* Following fields are implementation specific */
+    char      __ss_pad1[_SS_PAD1SIZE];
+              /* 6 byte pad, this is to make implementation
+              /* specific pad up to alignment field that */
+              /* follows explicit in the data structure */
+    int64_t   __ss_align;     /* field to force desired structure */
+               /* storage alignment */
+    char      __ss_pad2[_SS_PAD2SIZE];
+              /* 112 byte pad to achieve desired size, */
+              /* _SS_MAXSIZE value minus size of ss_family */
+              /* __ss_pad1, __ss_align fields is 112 */
+};
+
+   On implementations where sockaddr data structure includes a "sa_len",
+   field this data structure would look like this:
+
+/*
+ * Definitions used for sockaddr_storage structure paddings design.
+ */
+#define _SS_PAD1SIZE (_SS_ALIGNSIZE -
+                            (sizeof (uint8_t) + sizeof (sa_family_t))
+#define _SS_PAD2SIZE (_SS_MAXSIZE - (sizeof (sa_family_t)+
+
+
+
+Gilligan, et. al.            Informational                     [Page 14]
+
+RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
+
+
+                              _SS_PAD1SIZE + _SS_ALIGNSIZE))
+struct sockaddr_storage {
+    uint8_t      __ss_len;        /* address length */
+    sa_family_t  __ss_family;     /* address family */
+    /* Following fields are implementation specific */
+    char         __ss_pad1[_SS_PAD1SIZE];
+                  /* 6 byte pad, this is to make implementation
+                  /* specific pad up to alignment field that */
+                  /* follows explicit in the data structure */
+    int64_t      __ss_align;  /* field to force desired structure */
+                  /* storage alignment */
+    char         __ss_pad2[_SS_PAD2SIZE];
+                  /* 112 byte pad to achieve desired size, */
+                  /* _SS_MAXSIZE value minus size of ss_len, */
+                  /* __ss_family, __ss_pad1, __ss_align fields is 112 */
+};
+
+   The above example implementation illustrates a data structure which
+   will align on a 64 bit boundary. An implementation specific field
+   "__ss_align" along "__ss_pad1" is used to force a 64-bit alignment
+   which covers proper alignment good enough for needs of sockaddr_in6
+   (IPv6), sockaddr_in (IPv4) address data structures.  The size of
+   padding fields __ss_pad1 depends on the chosen alignment boundary.
+   The size of padding field __ss_pad2 depends on the value of overall
+   size chosen for the total size of the structure. This size and
+   alignment are represented in the above example by implementation
+   specific (not required) constants _SS_MAXSIZE (chosen value 128) and
+   _SS_ALIGNMENT (with chosen value 8).  Constants _SS_PAD1SIZE (derived
+   value 6) and _SS_PAD2SIZE (derived value 112) are also for
+   illustration and not required.  The implementation specific
+   definitions and structure field names above start with an underscore
+   to denote implementation private namespace.  Portable code is not
+   expected to access or reference those fields or constants.
+
+   The sockaddr_storage structure solves the problem of declaring
+   storage for automatic variables which is large enough and aligned
+   enough for storing socket address data structure of any family. For
+   example, code with a file descriptor and without the context of the
+   address family can pass a pointer to a variable of this type where a
+   pointer to a socket address structure is expected in calls such as
+   getpeername() and determine the address family by accessing the
+   received content after the call.
+
+   The sockaddr_storage structure may also be useful and applied to
+   certain other interfaces where a generic socket address large enough
+   and aligned for use with multiple address families may be needed. A
+   discussion of those interfaces is outside the scope of this document.
+
+
+
+
+Gilligan, et. al.            Informational                     [Page 15]
+
+RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
+
+
+   Also, much existing code assumes that any socket address structure
+   can fit in a generic sockaddr structure.  While this has been true
+   for IPv4 socket address structures, it has always been false for Unix
+   domain socket address structures (but in practice this has not been a
+   problem) and it is also false for IPv6 socket address structures
+   (which can be a problem).
+
+   So now an application can do the following:
+
+      struct sockaddr_storage __ss;
+      struct sockaddr_in6 *sin6;
+      sin6 = (struct sockaddr_in6 *) &__ss;
+
+4. Interface Identification
+
+   This API uses an interface index (a small positive integer) to
+   identify the local interface on which a multicast group is joined
+   (Section 5.3).  Additionally, the advanced API [4] uses these same
+   interface indexes to identify the interface on which a datagram is
+   received, or to specify the interface on which a datagram is to be
+   sent.
+
+   Interfaces are normally known by names such as "le0", "sl1", "ppp2",
+   and the like.  On Berkeley-derived implementations, when an interface
+   is made known to the system, the kernel assigns a unique positive
+   integer value (called the interface index) to that interface.  These
+   are small positive integers that start at 1.  (Note that 0 is never
+   used for an interface index.) There may be gaps so that there is no
+   current interface for a particular positive interface index.
+
+   This API defines two functions that map between an interface name and
+   index, a third function that returns all the interface names and
+   indexes, and a fourth function to return the dynamic memory allocated
+   by the previous function.  How these functions are implemented is
+   left up to the implementation.  4.4BSD implementations can implement
+   these functions using the existing sysctl() function with the
+   NET_RT_IFLIST command.  Other implementations may wish to use ioctl()
+   for this purpose.
+
+4.1 Name-to-Index
+
+   The first function maps an interface name into its corresponding
+   index.
+
+      #include <net/if.h>
+
+      unsigned int  if_nametoindex(const char *ifname);
+
+
+
+
+Gilligan, et. al.            Informational                     [Page 16]
+
+RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
+
+
+   If the specified interface name does not exist, the return value is
+   0, and errno is set to ENXIO.  If there was a system error (such as
+   running out of memory), the return value is 0 and errno is set to the
+   proper value (e.g., ENOMEM).
+
+4.2 Index-to-Name
+
+   The second function maps an interface index into its corresponding
+   name.
+
+      #include <net/if.h>
+
+      char  *if_indextoname(unsigned int ifindex, char *ifname);
+
+   The ifname argument must point to a buffer of at least IF_NAMESIZE
+   bytes into which the interface name corresponding to the specified
+   index is returned.  (IF_NAMESIZE is also defined in <net/if.h> and
+   its value includes a terminating null byte at the end of the
+   interface name.) This pointer is also the return value of the
+   function.  If there is no interface corresponding to the specified
+   index, NULL is returned, and errno is set to ENXIO, if there was a
+   system error (such as running out of memory), if_indextoname returns
+   NULL and errno would be set to the proper value (e.g., ENOMEM).
+
+4.3 Return All Interface Names and Indexes
+
+   The if_nameindex structure holds the information about a single
+   interface and is defined as a result of including the <net/if.h>
+   header.
+
+      struct if_nameindex {
+        unsigned int   if_index;  /* 1, 2, ... */
+        char          *if_name;   /* null terminated name: "le0", ... */
+      };
+
+   The final function returns an array of if_nameindex structures, one
+   structure per interface.
+
+      struct if_nameindex  *if_nameindex(void);
+
+   The end of the array of structures is indicated by a structure with
+   an if_index of 0 and an if_name of NULL.  The function returns a NULL
+   pointer upon an error, and would set errno to the appropriate value.
+
+   The memory used for this array of structures along with the interface
+   names pointed to by the if_name members is obtained dynamically.
+   This memory is freed by the next function.
+
+
+
+
+Gilligan, et. al.            Informational                     [Page 17]
+
+RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
+
+
+4.4 Free Memory
+
+   The following function frees the dynamic memory that was allocated by
+   if_nameindex().
+
+      #include <net/if.h>
+
+      void  if_freenameindex(struct if_nameindex *ptr);
+
+   The argument to this function must be a pointer that was returned by
+   if_nameindex().
+
+   Currently net/if.h doesn't have prototype definitions for functions
+   and it is recommended that these definitions be defined in net/if.h
+   as well and the struct if_nameindex{}.
+
+5. Socket Options
+
+   A number of new socket options are defined for IPv6.  All of these
+   new options are at the IPPROTO_IPV6 level.  That is, the "level"
+   parameter in the getsockopt() and setsockopt() calls is IPPROTO_IPV6
+   when using these options.  The constant name prefix IPV6_ is used in
+   all of the new socket options.  This serves to clearly identify these
+   options as applying to IPv6.
+
+   The declaration for IPPROTO_IPV6, the new IPv6 socket options, and
+   related constants defined in this section are obtained by including
+   the header <netinet/in.h>.
+
+5.1 Unicast Hop Limit
+
+   A new setsockopt() option controls the hop limit used in outgoing
+   unicast IPv6 packets.  The name of this option is IPV6_UNICAST_HOPS,
+   and it is used at the IPPROTO_IPV6 layer.  The following example
+   illustrates how it is used:
+
+      int  hoplimit = 10;
+
+      if (setsockopt(s, IPPROTO_IPV6, IPV6_UNICAST_HOPS,
+                     (char *) &hoplimit, sizeof(hoplimit)) == -1)
+          perror("setsockopt IPV6_UNICAST_HOPS");
+
+   When the IPV6_UNICAST_HOPS option is set with setsockopt(), the
+   option value given is used as the hop limit for all subsequent
+   unicast packets sent via that socket.  If the option is not set, the
+   system selects a default value.  The integer hop limit value (called
+   x) is interpreted as follows:
+
+
+
+
+Gilligan, et. al.            Informational                     [Page 18]
+
+RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
+
+
+      x < -1:        return an error of EINVAL
+      x == -1:       use kernel default
+      0 <= x <= 255: use x
+      x >= 256:      return an error of EINVAL
+
+   The IPV6_UNICAST_HOPS option may be used with getsockopt() to
+   determine the hop limit value that the system will use for subsequent
+   unicast packets sent via that socket.  For example:
+
+      int  hoplimit;
+      size_t  len = sizeof(hoplimit);
+
+      if (getsockopt(s, IPPROTO_IPV6, IPV6_UNICAST_HOPS,
+                     (char *) &hoplimit, &len) == -1)
+          perror("getsockopt IPV6_UNICAST_HOPS");
+      else
+          printf("Using %d for hop limit.\n", hoplimit);
+
+5.2 Sending and Receiving Multicast Packets
+
+   IPv6 applications may send UDP multicast packets by simply specifying
+   an IPv6 multicast address in the address argument of the sendto()
+   function.
+
+   Three socket options at the IPPROTO_IPV6 layer control some of the
+   parameters for sending multicast packets.  Setting these options is
+   not required: applications may send multicast packets without using
+   these options.  The setsockopt() options for controlling the sending
+   of multicast packets are summarized below.  These three options can
+   also be used with getsockopt().
+
+      IPV6_MULTICAST_IF
+
+         Set the interface to use for outgoing multicast packets.  The
+         argument is the index of the interface to use.
+
+         Argument type: unsigned int
+
+      IPV6_MULTICAST_HOPS
+
+         Set the hop limit to use for outgoing multicast packets.  (Note
+         a separate option - IPV6_UNICAST_HOPS - is provided to set the
+         hop limit to use for outgoing unicast packets.)
+
+         The interpretation of the argument is the same as for the
+         IPV6_UNICAST_HOPS option:
+
+
+
+
+
+Gilligan, et. al.            Informational                     [Page 19]
+
+RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
+
+
+           x < -1:        return an error of EINVAL
+           x == -1:       use kernel default
+           0 <= x <= 255: use x
+           x >= 256:      return an error of EINVAL
+
+           If IPV6_MULTICAST_HOPS is not set, the default is 1
+           (same as IPv4 today)
+
+         Argument type: int
+
+      IPV6_MULTICAST_LOOP
+
+         If a multicast datagram is sent to a group to which the sending
+         host itself belongs (on the outgoing interface), a copy of the
+         datagram is looped back by the IP layer for local delivery if
+         this option is set to 1.  If this option is set to 0 a copy
+         is not looped back.  Other option values return an error of
+         EINVAL.
+
+         If IPV6_MULTICAST_LOOP is not set, the default is 1 (loopback;
+         same as IPv4 today).
+
+         Argument type: unsigned int
+
+   The reception of multicast packets is controlled by the two
+   setsockopt() options summarized below.  An error of EOPNOTSUPP is
+   returned if these two options are used with getsockopt().
+
+      IPV6_JOIN_GROUP
+
+         Join a multicast group on a specified local interface.  If the
+         interface index is specified as 0, the kernel chooses the local
+         interface.  For example, some kernels look up the multicast
+         group in the normal IPv6 routing table and using the resulting
+         interface.
+
+         Argument type: struct ipv6_mreq
+
+      IPV6_LEAVE_GROUP
+
+         Leave a multicast group on a specified interface.
+
+         Argument type: struct ipv6_mreq
+
+   The argument type of both of these options is the ipv6_mreq structure,
+   defined as a result of including the <netinet/in.h> header;
+
+
+
+
+
+Gilligan, et. al.            Informational                     [Page 20]
+
+RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
+
+
+   struct ipv6_mreq {
+       struct in6_addr ipv6mr_multiaddr; /* IPv6 multicast addr */
+       unsigned int    ipv6mr_interface; /* interface index */
+   };
+
+   Note that to receive multicast datagrams a process must join the
+   multicast group and bind the UDP port to which datagrams will be
+   sent.  Some processes also bind the multicast group address to the
+   socket, in addition to the port, to prevent other datagrams destined
+   to that same port from being delivered to the socket.
+
+6. Library Functions
+
+   New library functions are needed to perform a variety of operations
+   with IPv6 addresses.  Functions are needed to lookup IPv6 addresses
+   in the Domain Name System (DNS).  Both forward lookup (nodename-to-
+   address translation) and reverse lookup (address-to-nodename
+   translation) need to be supported.  Functions are also needed to
+   convert IPv6 addresses between their binary and textual form.
+
+   We note that the two existing functions, gethostbyname() and
+   gethostbyaddr(), are left as-is.  New functions are defined to handle
+   both IPv4 and IPv6 addresses.
+
+6.1 Nodename-to-Address Translation
+
+   The commonly used function gethostbyname() is inadequate for many
+   applications, first because it provides no way for the caller to
+   specify anything about the types of addresses desired (IPv4 only,
+   IPv6 only, IPv4-mapped IPv6 are OK, etc.), and second because many
+   implementations of this function are not thread safe.  RFC 2133
+   defined a function named gethostbyname2() but this function was also
+   inadequate, first because its use required setting a global option
+   (RES_USE_INET6) when IPv6 addresses were required, and second because
+   a flag argument is needed to provide the caller with additional
+   control over the types of addresses required.
+
+   The following function is new and must be thread safe:
+
+   #include <sys/socket.h>
+   #include <netdb.h>
+
+   struct hostent *getipnodebyname(const char *name, int af, int flags
+                                       int *error_num);
+
+   The name argument can be either a node name or a numeric address
+   string (i.e., a dotted-decimal IPv4 address or an IPv6 hex address).
+   The af argument specifies the address family, either AF_INET or
+
+
+
+Gilligan, et. al.            Informational                     [Page 21]
+
+RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
+
+
+   AF_INET6. The error_num value is returned to the caller, via a
+   pointer, with the appropriate error code in error_num, to support
+   thread safe error code returns.  error_num will be set to one of the
+   following values:
+
+      HOST_NOT_FOUND
+
+         No such host is known.
+
+      NO_ADDRESS
+
+         The server recognised the request and the name but no address is
+         available.  Another type of request to the name server for the
+         domain might return an answer.
+
+      NO_RECOVERY
+
+         An unexpected server failure occurred which cannot be recovered.
+
+      TRY_AGAIN
+
+         A temporary and possibly transient error occurred, such as a
+         failure of a server to respond.
+
+   The flags argument specifies the types of addresses that are searched
+   for, and the types of addresses that are returned.  We note that a
+   special flags value of AI_DEFAULT (defined below) should handle most
+   applications.
+
+   That is, porting simple applications to use IPv6 replaces the call
+
+      hptr = gethostbyname(name);
+
+   with
+
+      hptr = getipnodebyname(name, AF_INET6, AI_DEFAULT, &error_num);
+
+   and changes any subsequent error diagnosis code to use error_num
+   instead of externally declared variables, such as h_errno.
+
+   Applications desiring finer control over the types of addresses
+   searched for and returned, can specify other combinations of the
+   flags argument.
+
+
+
+
+
+
+
+
+Gilligan, et. al.            Informational                     [Page 22]
+
+RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
+
+
+   A flags of 0 implies a strict interpretation of the af argument:
+
+      - If flags is 0 and af is AF_INET, then the caller wants only
+        IPv4 addresses.  A query is made for A records.  If successful,
+        the IPv4 addresses are returned and the h_length member of the
+        hostent structure will be 4, else the function returns a NULL
+        pointer.
+
+      -  If flags is 0 and if af is AF_INET6, then the caller wants only
+        IPv6 addresses.  A query is made for AAAA records.  If
+        successful, the IPv6 addresses are returned and the h_length
+        member of the hostent structure will be 16, else the function
+        returns a NULL pointer.
+
+   Other constants can be logically-ORed into the flags argument, to
+   modify the behavior of the function.
+
+      - If the AI_V4MAPPED flag is specified along with an af of
+        AF_INET6, then the caller will accept IPv4-mapped IPv6
+        addresses.  That is, if no AAAA records are found then a query
+        is made for A records and any found are returned as IPv4-mapped
+        IPv6 addresses (h_length will be 16).  The AI_V4MAPPED flag is
+        ignored unless af equals AF_INET6.
+
+      - The AI_ALL flag is used in conjunction with the AI_V4MAPPED
+        flag, and is only used with the IPv6 address family.  When AI_ALL
+        is logically or'd with AI_V4MAPPED flag then the caller wants
+        all addresses: IPv6 and IPv4-mapped IPv6.  A query is first made
+        for AAAA records and if successful, the IPv6 addresses are
+        returned. Another query is then made for A records and any found
+        are returned as IPv4-mapped IPv6 addresses. h_length will be 16.
+        Only if both queries fail does the function return a NULL pointer.
+        This flag is ignored unless af equals AF_INET6.
+
+      - The AI_ADDRCONFIG flag specifies that a query for AAAA records
+        should occur only if the node has at least one IPv6 source
+        address configured and a query for A records should occur only
+        if the node has at least one IPv4 source address configured.
+
+        For example, if the node has no IPv6 source addresses
+        configured, and af equals AF_INET6, and the node name being
+        looked up has both AAAA and A records, then:
+
+            (a) if only AI_ADDRCONFIG is specified, the function
+                returns a NULL pointer;
+            (b) if AI_ADDRCONFIG | AI_V4MAPPED is specified, the A
+                records are returned as IPv4-mapped IPv6 addresses;
+
+
+
+
+Gilligan, et. al.            Informational                     [Page 23]
+
+RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
+
+
+   The special flags value of AI_DEFAULT is defined as
+
+      #define  AI_DEFAULT  (AI_V4MAPPED | AI_ADDRCONFIG)
+
+   We noted that the getipnodebyname() function must allow the name
+   argument to be either a node name or a literal address string (i.e.,
+   a dotted-decimal IPv4 address or an IPv6 hex address).  This saves
+   applications from having to call inet_pton() to handle literal
+   address strings.
+
+   There are four scenarios based on the type of literal address string
+   and the value of the af argument.
+
+   The two simple cases are:
+
+   When name is a dotted-decimal IPv4 address and af equals AF_INET, or
+   when name is an IPv6 hex address and af equals AF_INET6.  The members
+   of the returned hostent structure are: h_name points to a copy of the
+   name argument, h_aliases is a NULL pointer, h_addrtype is a copy of
+   the af argument, h_length is either 4 (for AF_INET) or 16 (for
+   AF_INET6), h_addr_list[0] is a pointer to the 4-byte or 16-byte
+   binary address, and h_addr_list[1] is a NULL pointer.
+
+   When name is a dotted-decimal IPv4 address and af equals AF_INET6,
+   and flags equals AI_V4MAPPED, an IPv4-mapped IPv6 address is
+   returned:  h_name points to an IPv6 hex address containing the IPv4-
+   mapped IPv6 address, h_aliases is a NULL pointer, h_addrtype is
+   AF_INET6, h_length is 16, h_addr_list[0] is a pointer to the 16-byte
+   binary address, and h_addr_list[1] is a NULL pointer.  If AI_V4MAPPED
+   is set (with or without AI_ALL) return IPv4-mapped otherwise return
+   NULL.
+
+   It is an error when name is an IPv6 hex address and af equals
+   AF_INET.  The function's return value is a NULL pointer and error_num
+   equals HOST_NOT_FOUND.
+
+6.2 Address-To-Nodename Translation
+
+   The following function has the same arguments as the existing
+   gethostbyaddr() function, but adds an error number.
+
+      #include <sys/socket.h> #include <netdb.h>
+
+      struct hostent *getipnodebyaddr(const void *src, size_t len,
+                                          int af, int *error_num);
+
+
+
+
+
+
+Gilligan, et. al.            Informational                     [Page 24]
+
+RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
+
+
+   As with getipnodebyname(), getipnodebyaddr() must be thread safe.
+   The error_num value is returned to the caller with the appropriate
+   error code, to support thread safe error code returns.  The following
+   error conditions may be returned for error_num:
+
+      HOST_NOT_FOUND
+
+         No such host is known.
+
+      NO_ADDRESS
+
+         The server recognized the request and the name but no address
+         is available.  Another type of request to the name server for
+         the domain might return an answer.
+
+      NO_RECOVERY
+
+         An unexpected server failure occurred which cannot be
+         recovered.
+
+      TRY_AGAIN
+
+         A temporary and possibly transient error occurred, such as a
+         failure of a server to respond.
+
+   One possible source of confusion is the handling of IPv4-mapped IPv6
+   addresses and IPv4-compatible IPv6 addresses, but the following logic
+   should apply.
+
+      1.  If af is AF_INET6, and if len equals 16, and if the IPv6
+          address is an IPv4-mapped IPv6 address or an IPv4-compatible
+          IPv6 address, then skip over the first 12 bytes of the IPv6
+          address, set af to AF_INET, and set len to 4.
+
+      2.  If af is AF_INET, lookup the name for the given IPv4 address
+          (e.g., query for a PTR record in the in-addr.arpa domain).
+
+      3.  If af is AF_INET6, lookup the name for the given IPv6 address
+          (e.g., query for a PTR record in the ip6.int domain).
+
+      4.  If the function is returning success, then the single address
+          that is returned in the hostent structure is a copy of the
+          first argument to the function with the same address family
+          that was passed as an argument to this function.
+
+
+
+
+
+
+
+Gilligan, et. al.            Informational                     [Page 25]
+
+RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
+
+
+   All four steps listed are performed, in order.  Also note that the
+   IPv6 hex addresses "::" and "::1" MUST NOT be treated as IPv4-
+   compatible addresses, and if the address is "::", HOST_NOT_FOUND MUST
+   be returned and a query of the address not performed.
+
+   Also for the macro in section 6.7 IN6_IS_ADDR_V4COMPAT MUST return
+   false for "::" and "::1".
+
+6.3 Freeing memory for getipnodebyname and getipnodebyaddr
+
+   The hostent structure does not change from its existing definition.
+   This structure, and the information pointed to by this structure, are
+   dynamically allocated by getipnodebyname and getipnodebyaddr.  The
+   following function frees this memory:
+
+      #include <netdb.h>
+
+      void freehostent(struct hostent *ptr);
+
+6.4 Protocol-Independent Nodename and Service Name Translation
+
+   Nodename-to-address translation is done in a protocol-independent
+   fashion using the getaddrinfo() function that is taken from the
+   Institute of Electrical and Electronic Engineers (IEEE) POSIX 1003.1g
+   (Protocol Independent Interfaces) draft specification [3].
+
+   The official specification for this function will be the final POSIX
+   standard, with the following additional requirements:
+
+      -  getaddrinfo() (along with the getnameinfo() function described
+         in the next section) must be thread safe.
+
+      -  The AI_NUMERICHOST is new with this document.
+
+      -  All fields in socket address structures returned by
+         getaddrinfo() that are not filled in through an explicit
+         argument (e.g., sin6_flowinfo and sin_zero) must be set to 0.
+         (This makes it easier to compare socket address structures.)
+
+      -  getaddrinfo() must fill in the length field of a socket address
+         structure (e.g., sin6_len) on systems that support this field.
+
+   We are providing this independent description of the function because
+   POSIX standards are not freely available (as are IETF documents).
+
+      #include <sys/socket.h>
+      #include <netdb.h>
+
+
+
+
+Gilligan, et. al.            Informational                     [Page 26]
+
+RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
+
+
+      int getaddrinfo(const char *nodename, const char *servname,
+                      const struct addrinfo *hints,
+                      struct addrinfo **res);
+
+   The addrinfo structure is defined as a result of including the
+   <netdb.h> header.
+
+  struct addrinfo {
+    int     ai_flags;     /* AI_PASSIVE, AI_CANONNAME, AI_NUMERICHOST */
+    int     ai_family;    /* PF_xxx */
+    int     ai_socktype;  /* SOCK_xxx */
+    int     ai_protocol;  /* 0 or IPPROTO_xxx for IPv4 and IPv6 */
+    size_t  ai_addrlen;   /* length of ai_addr */
+    char   *ai_canonname; /* canonical name for nodename */
+    struct sockaddr  *ai_addr; /* binary address */
+    struct addrinfo  *ai_next; /* next structure in linked list */
+  };
+
+   The return value from the function is 0 upon success or a nonzero
+   error code.  The following names are the nonzero error codes from
+   getaddrinfo(), and are defined in <netdb.h>:
+
+      EAI_ADDRFAMILY  address family for nodename not supported
+      EAI_AGAIN       temporary failure in name resolution
+      EAI_BADFLAGS    invalid value for ai_flags
+      EAI_FAIL        non-recoverable failure in name resolution
+      EAI_FAMILY      ai_family not supported
+      EAI_MEMORY      memory allocation failure
+      EAI_NODATA      no address associated with nodename
+      EAI_NONAME      nodename nor servname provided, or not known
+      EAI_SERVICE     servname not supported for ai_socktype
+      EAI_SOCKTYPE    ai_socktype not supported
+      EAI_SYSTEM      system error returned in errno
+
+   The nodename and servname arguments are pointers to null-terminated
+   strings or NULL.  One or both of these two arguments must be a non-
+   NULL pointer.  In the normal client scenario, both the nodename and
+   servname are specified.  In the normal server scenario, only the
+   servname is specified.  A non-NULL nodename string can be either a
+   node name or a numeric host address string (i.e., a dotted-decimal
+   IPv4 address or an IPv6 hex address).  A non-NULL servname string can
+   be either a service name or a decimal port number.
+
+   The caller can optionally pass an addrinfo structure, pointed to by
+   the third argument, to provide hints concerning the type of socket
+   that the caller supports.  In this hints structure all members other
+   than ai_flags, ai_family, ai_socktype, and ai_protocol must be zero
+   or a NULL pointer.  A value of PF_UNSPEC for ai_family means the
+
+
+
+Gilligan, et. al.            Informational                     [Page 27]
+
+RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
+
+
+   caller will accept any protocol family.  A value of 0 for ai_socktype
+   means the caller will accept any socket type.  A value of 0 for
+   ai_protocol means the caller will accept any protocol.  For example,
+   if the caller handles only TCP and not UDP, then the ai_socktype
+   member of the hints structure should be set to SOCK_STREAM when
+   getaddrinfo() is called.  If the caller handles only IPv4 and not
+   IPv6, then the ai_family member of the hints structure should be set
+   to PF_INET when getaddrinfo() is called.  If the third argument to
+   getaddrinfo() is a NULL pointer, this is the same as if the caller
+   had filled in an addrinfo structure initialized to zero with
+   ai_family set to PF_UNSPEC.
+
+   Upon successful return a pointer to a linked list of one or more
+   addrinfo structures is returned through the final argument.  The
+   caller can process each addrinfo structure in this list by following
+   the ai_next pointer, until a NULL pointer is encountered.  In each
+   returned addrinfo structure the three members ai_family, ai_socktype,
+   and ai_protocol are the corresponding arguments for a call to the
+   socket() function.  In each addrinfo structure the ai_addr member
+   points to a filled-in socket address structure whose length is
+   specified by the ai_addrlen member.
+
+   If the AI_PASSIVE bit is set in the ai_flags member of the hints
+   structure, then the caller plans to use the returned socket address
+   structure in a call to bind().  In this case, if the nodename
+   argument is a NULL pointer, then the IP address portion of the socket
+   address structure will be set to INADDR_ANY for an IPv4 address or
+   IN6ADDR_ANY_INIT for an IPv6 address.
+
+   If the AI_PASSIVE bit is not set in the ai_flags member of the hints
+   structure, then the returned socket address structure will be ready
+   for a call to connect() (for a connection-oriented protocol) or
+   either connect(), sendto(), or sendmsg() (for a connectionless
+   protocol).  In this case, if the nodename argument is a NULL pointer,
+   then the IP address portion of the socket address structure will be
+   set to the loopback address.
+
+   If the AI_CANONNAME bit is set in the ai_flags member of the hints
+   structure, then upon successful return the ai_canonname member of the
+   first addrinfo structure in the linked list will point to a null-
+   terminated string containing the canonical name of the specified
+   nodename.
+
+   If the AI_NUMERICHOST bit is set in the ai_flags member of the hints
+   structure, then a non-NULL nodename string must be a numeric host
+   address string.  Otherwise an error of EAI_NONAME is returned.  This
+   flag prevents any type of name resolution service (e.g., the DNS)
+   from being called.
+
+
+
+Gilligan, et. al.            Informational                     [Page 28]
+
+RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
+
+
+   All of the information returned by getaddrinfo() is dynamically
+   allocated: the addrinfo structures, and the socket address structures
+   and canonical node name strings pointed to by the addrinfo
+   structures.  To return this information to the system the function
+   freeaddrinfo() is called:
+
+      #include <sys/socket.h> #include <netdb.h>
+
+      void freeaddrinfo(struct addrinfo *ai);
+
+   The addrinfo structure pointed to by the ai argument is freed, along
+   with any dynamic storage pointed to by the structure.  This operation
+   is repeated until a NULL ai_next pointer is encountered.
+
+   To aid applications in printing error messages based on the EAI_xxx
+   codes returned by getaddrinfo(), the following function is defined.
+
+      #include <sys/socket.h> #include <netdb.h>
+
+      char *gai_strerror(int ecode);
+
+   The argument is one of the EAI_xxx values defined earlier and the
+   return value points to a string describing the error.  If the
+   argument is not one of the EAI_xxx values, the function still returns
+   a pointer to a string whose contents indicate an unknown error.
+
+6.5 Socket Address Structure to Nodename and Service Name
+
+   The POSIX 1003.1g specification includes no function to perform the
+   reverse conversion from getaddrinfo(): to look up a nodename and
+   service name, given the binary address and port.  Therefore, we
+   define the following function:
+
+      #include <sys/socket.h>
+      #include <netdb.h>
+
+      int getnameinfo(const struct sockaddr *sa, socklen_t salen,
+                      char *host, size_t hostlen,
+                      char *serv, size_t servlen,
+                      int flags);
+
+   This function looks up an IP address and port number provided by the
+   caller in the DNS and system-specific database, and returns text
+   strings for both in buffers provided by the caller.  The function
+   indicates successful completion by a zero return value; a non-zero
+   return value indicates failure.
+
+
+
+
+
+Gilligan, et. al.            Informational                     [Page 29]
+
+RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
+
+
+   The first argument, sa, points to either a sockaddr_in structure (for
+   IPv4) or a sockaddr_in6 structure (for IPv6) that holds the IP
+   address and port number.  The salen argument gives the length of the
+   sockaddr_in or sockaddr_in6 structure.
+
+   The function returns the nodename associated with the IP address in
+   the buffer pointed to by the host argument.  The caller provides the
+   size of this buffer via the hostlen argument.  The service name
+   associated with the port number is returned in the buffer pointed to
+   by serv, and the servlen argument gives the length of this buffer.
+   The caller specifies not to return either string by providing a zero
+   value for the hostlen or servlen arguments.  Otherwise, the caller
+   must provide buffers large enough to hold the nodename and the
+   service name, including the terminating null characters.
+
+   Unfortunately most systems do not provide constants that specify the
+   maximum size of either a fully-qualified domain name or a service
+   name.  Therefore to aid the application in allocating buffers for
+   these two returned strings the following constants are defined in
+   <netdb.h>:
+
+      #define NI_MAXHOST  1025
+      #define NI_MAXSERV    32
+
+   The first value is actually defined as the constant MAXDNAME in recent
+   versions of BIND's <arpa/nameser.h> header (older versions of BIND
+   define this constant to be 256) and the second is a guess based on the
+   services listed in the current Assigned Numbers RFC.
+
+   The final argument is a flag that changes the default actions of this
+   function.  By default the fully-qualified domain name (FQDN) for the
+   host is looked up in the DNS and returned.  If the flag bit NI_NOFQDN
+   is set, only the nodename portion of the FQDN is returned for local
+   hosts.
+
+   If the flag bit NI_NUMERICHOST is set, or if the host's name cannot be
+   located in the DNS, the numeric form of the host's address is returned
+   instead of its name (e.g., by calling inet_ntop() instead of
+   getipnodebyaddr()).  If the flag bit NI_NAMEREQD is set, an error is
+   returned if the host's name cannot be located in the DNS.
+
+   If the flag bit NI_NUMERICSERV is set, the numeric form of the service
+   address is returned (e.g., its port number) instead of its name.  The
+   two NI_NUMERICxxx flags are required to support the "-n" flag that
+   many commands provide.
+
+
+
+
+
+
+Gilligan, et. al.            Informational                     [Page 30]
+
+RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
+
+
+   A fifth flag bit, NI_DGRAM, specifies that the service is a datagram
+   service, and causes getservbyport() to be called with a second
+   argument of "udp" instead of its default of "tcp".  This is required
+   for the few ports (e.g. 512-514) that have different services for UDP
+   and TCP.
+
+   These NI_xxx flags are defined in <netdb.h> along with the AI_xxx
+   flags already defined for getaddrinfo().
+
+6.6 Address Conversion Functions
+
+   The two functions inet_addr() and inet_ntoa() convert an IPv4 address
+   between binary and text form.  IPv6 applications need similar
+   functions.  The following two functions convert both IPv6 and IPv4
+   addresses:
+
+      #include <sys/socket.h>
+      #include <arpa/inet.h>
+
+      int inet_pton(int af, const char *src, void *dst);
+
+      const char *inet_ntop(int af, const void *src,
+                            char *dst, size_t size);
+
+   The inet_pton() function converts an address in its standard text
+   presentation form into its numeric binary form.  The af argument
+   specifies the family of the address.  Currently the AF_INET and
+   AF_INET6 address families are supported.  The src argument points to
+   the string being passed in.  The dst argument points to a buffer into
+   which the function stores the numeric address.  The address is
+   returned in network byte order.  Inet_pton() returns 1 if the
+   conversion succeeds, 0 if the input is not a valid IPv4 dotted-
+   decimal string or a valid IPv6 address string, or -1 with errno set
+   to EAFNOSUPPORT if the af argument is unknown.  The calling
+   application must ensure that the buffer referred to by dst is large
+   enough to hold the numeric address (e.g., 4 bytes for AF_INET or 16
+   bytes for AF_INET6).
+
+   If the af argument is AF_INET, the function accepts a string in the
+   standard IPv4 dotted-decimal form:
+
+      ddd.ddd.ddd.ddd
+
+   where ddd is a one to three digit decimal number between 0 and 255.
+   Note that many implementations of the existing inet_addr() and
+   inet_aton() functions accept nonstandard input: octal numbers,
+   hexadecimal numbers, and fewer than four numbers.  inet_pton() does
+   not accept these formats.
+
+
+
+Gilligan, et. al.            Informational                     [Page 31]
+
+RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
+
+
+   If the af argument is AF_INET6, then the function accepts a string in
+   one of the standard IPv6 text forms defined in Section 2.2 of the
+   addressing architecture specification [2].
+
+   The inet_ntop() function converts a numeric address into a text
+   string suitable for presentation.  The af argument specifies the
+   family of the address.  This can be AF_INET or AF_INET6.  The src
+   argument points to a buffer holding an IPv4 address if the af
+   argument is AF_INET, or an IPv6 address if the af argument is
+   AF_INET6, the address must be in network byte order.  The dst
+   argument points to a buffer where the function will store the
+   resulting text string.  The size argument specifies the size of this
+   buffer.  The application must specify a non-NULL dst argument.  For
+   IPv6 addresses, the buffer must be at least 46-octets.  For IPv4
+   addresses, the buffer must be at least 16-octets.  In order to allow
+   applications to easily declare buffers of the proper size to store
+   IPv4 and IPv6 addresses in string form, the following two constants
+   are defined in <netinet/in.h>:
+
+      #define INET_ADDRSTRLEN    16
+      #define INET6_ADDRSTRLEN   46
+
+   The inet_ntop() function returns a pointer to the buffer containing
+   the text string if the conversion succeeds, and NULL otherwise.  Upon
+   failure, errno is set to EAFNOSUPPORT if the af argument is invalid or
+   ENOSPC if the size of the result buffer is inadequate.
+
+6.7 Address Testing Macros
+
+   The following macros can be used to test for special IPv6 addresses.
+
+      #include <netinet/in.h>
+
+      int  IN6_IS_ADDR_UNSPECIFIED (const struct in6_addr *);
+      int  IN6_IS_ADDR_LOOPBACK    (const struct in6_addr *);
+      int  IN6_IS_ADDR_MULTICAST   (const struct in6_addr *);
+      int  IN6_IS_ADDR_LINKLOCAL   (const struct in6_addr *);
+      int  IN6_IS_ADDR_SITELOCAL   (const struct in6_addr *);
+      int  IN6_IS_ADDR_V4MAPPED    (const struct in6_addr *);
+      int  IN6_IS_ADDR_V4COMPAT    (const struct in6_addr *);
+
+      int  IN6_IS_ADDR_MC_NODELOCAL(const struct in6_addr *);
+      int  IN6_IS_ADDR_MC_LINKLOCAL(const struct in6_addr *);
+      int  IN6_IS_ADDR_MC_SITELOCAL(const struct in6_addr *);
+      int  IN6_IS_ADDR_MC_ORGLOCAL (const struct in6_addr *);
+      int  IN6_IS_ADDR_MC_GLOBAL   (const struct in6_addr *);
+
+
+
+
+
+Gilligan, et. al.            Informational                     [Page 32]
+
+RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
+
+
+   The first seven macros return true if the address is of the specified
+   type, or false otherwise.  The last five test the scope of a
+   multicast address and return true if the address is a multicast
+   address of the specified scope or false if the address is either not
+   a multicast address or not of the specified scope.  Note that
+   IN6_IS_ADDR_LINKLOCAL and IN6_IS_ADDR_SITELOCAL return true only for
+   the two local-use IPv6 unicast addresses.  These two macros do not
+   return true for IPv6 multicast addresses of either link-local scope
+   or site-local scope.
+
+7. Summary of New Definitions
+
+   The following list summarizes the constants, structure, and extern
+   definitions discussed in this memo, sorted by header.
+
+      <net/if.h>      IF_NAMESIZE
+      <net/if.h>      struct if_nameindex{};
+
+      <netdb.h>       AI_ADDRCONFIG
+      <netdb.h>       AI_DEFAULT
+      <netdb.h>       AI_ALL
+      <netdb.h>       AI_CANONNAME
+      <netdb.h>       AI_NUMERICHOST
+      <netdb.h>       AI_PASSIVE
+      <netdb.h>       AI_V4MAPPED
+      <netdb.h>       EAI_ADDRFAMILY
+      <netdb.h>       EAI_AGAIN
+      <netdb.h>       EAI_BADFLAGS
+      <netdb.h>       EAI_FAIL
+      <netdb.h>       EAI_FAMILY
+      <netdb.h>       EAI_MEMORY
+      <netdb.h>       EAI_NODATA
+      <netdb.h>       EAI_NONAME
+      <netdb.h>       EAI_SERVICE
+      <netdb.h>       EAI_SOCKTYPE
+      <netdb.h>       EAI_SYSTEM
+      <netdb.h>       NI_DGRAM
+      <netdb.h>       NI_MAXHOST
+      <netdb.h>       NI_MAXSERV
+      <netdb.h>       NI_NAMEREQD
+      <netdb.h>       NI_NOFQDN
+      <netdb.h>       NI_NUMERICHOST
+      <netdb.h>       NI_NUMERICSERV
+      <netdb.h>       struct addrinfo{};
+
+      <netinet/in.h>  IN6ADDR_ANY_INIT
+      <netinet/in.h>  IN6ADDR_LOOPBACK_INIT
+      <netinet/in.h>  INET6_ADDRSTRLEN
+
+
+
+Gilligan, et. al.            Informational                     [Page 33]
+
+RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
+
+
+      <netinet/in.h>  INET_ADDRSTRLEN
+      <netinet/in.h>  IPPROTO_IPV6
+      <netinet/in.h>  IPV6_JOIN_GROUP
+      <netinet/in.h>  IPV6_LEAVE_GROUP
+      <netinet/in.h>  IPV6_MULTICAST_HOPS
+      <netinet/in.h>  IPV6_MULTICAST_IF
+      <netinet/in.h>  IPV6_MULTICAST_LOOP
+      <netinet/in.h>  IPV6_UNICAST_HOPS
+      <netinet/in.h>  SIN6_LEN
+      <netinet/in.h>  extern const struct in6_addr in6addr_any;
+      <netinet/in.h>  extern const struct in6_addr in6addr_loopback;
+      <netinet/in.h>  struct in6_addr{};
+      <netinet/in.h>  struct ipv6_mreq{};
+      <netinet/in.h>  struct sockaddr_in6{};
+
+      <sys/socket.h>  AF_INET6
+      <sys/socket.h>  PF_INET6
+      <sys/socket.h>  struct sockaddr_storage;
+
+   The following list summarizes the function and macro prototypes
+   discussed in this memo, sorted by header.
+
+<arpa/inet.h>   int inet_pton(int, const char *, void *);
+<arpa/inet.h>   const char *inet_ntop(int, const void *,
+                                      char *, size_t);
+
+<net/if.h>      char *if_indextoname(unsigned int, char *);
+<net/if.h>      unsigned int if_nametoindex(const char *);
+<net/if.h>      void if_freenameindex(struct if_nameindex *);
+<net/if.h>      struct if_nameindex *if_nameindex(void);
+
+<netdb.h>       int getaddrinfo(const char *, const char *,
+                                const struct addrinfo *,
+                                struct addrinfo **);
+<netdb.h>       int getnameinfo(const struct sockaddr *, socklen_t,
+                                char *, size_t, char *, size_t, int);
+<netdb.h>       void freeaddrinfo(struct addrinfo *);
+<netdb.h>       char *gai_strerror(int);
+<netdb.h>       struct hostent *getipnodebyname(const char *, int, int,
+                                       int *);
+<netdb.h>       struct hostent *getipnodebyaddr(const void *, size_t,
+                                       int, int *);
+<netdb.h>       void freehostent(struct hostent *);
+
+<netinet/in.h>  int IN6_IS_ADDR_LINKLOCAL(const struct in6_addr *);
+<netinet/in.h>  int IN6_IS_ADDR_LOOPBACK(const struct in6_addr *);
+<netinet/in.h>  int IN6_IS_ADDR_MC_GLOBAL(const struct in6_addr *);
+<netinet/in.h>  int IN6_IS_ADDR_MC_LINKLOCAL(const struct in6_addr *);
+
+
+
+Gilligan, et. al.            Informational                     [Page 34]
+
+RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
+
+
+<netinet/in.h>  int IN6_IS_ADDR_MC_NODELOCAL(const struct in6_addr *);
+<netinet/in.h>  int IN6_IS_ADDR_MC_ORGLOCAL(const struct in6_addr *);
+<netinet/in.h>  int IN6_IS_ADDR_MC_SITELOCAL(const struct in6_addr *);
+<netinet/in.h>  int IN6_IS_ADDR_MULTICAST(const struct in6_addr *);
+<netinet/in.h>  int IN6_IS_ADDR_SITELOCAL(const struct in6_addr *);
+<netinet/in.h>  int IN6_IS_ADDR_UNSPECIFIED(const struct in6_addr *);
+<netinet/in.h>  int IN6_IS_ADDR_V4COMPAT(const struct in6_addr *);
+<netinet/in.h>  int IN6_IS_ADDR_V4MAPPED(const struct in6_addr *);
+
+8. Security Considerations
+
+   IPv6 provides a number of new security mechanisms, many of which need
+   to be accessible to applications.  Companion memos detailing the
+   extensions to the socket interfaces to support IPv6 security are
+   being written.
+
+9. Year 2000 Considerations
+
+   There are no issues for this memo concerning the Year 2000 issue
+   regarding the use of dates.
+
+Changes From RFC 2133
+
+   Changes made in the March 1998 Edition (-01 draft):
+
+      Changed all "hostname" to "nodename" for consistency with other
+      IPv6 documents.
+
+      Section 3.3: changed comment for sin6_flowinfo to be "traffic
+      class & flow info" and updated corresponding text description to
+      current definition of these two fields.
+
+      Section 3.10 ("Portability Additions") is new.
+
+      Section 6: a new paragraph was added reiterating that the existing
+      gethostbyname() and gethostbyaddr() are not changed.
+
+      Section 6.1: change gethostbyname3() to getnodebyname().  Add
+      AI_DEFAULT to handle majority of applications.  Renamed
+      AI_V6ADDRCONFIG to AI_ADDRCONFIG and define it for A records and
+      IPv4 addresses too.  Defined exactly what getnodebyname() must
+      return if the name argument is a numeric address string.
+
+      Section 6.2: change gethostbyaddr() to getnodebyaddr().  Reword
+      items 2 and 3 in the description of how to handle IPv4-mapped and
+      IPv4- compatible addresses to "lookup a name" for a given address,
+      instead of specifying what type of DNS query to issue.
+
+
+
+
+Gilligan, et. al.            Informational                     [Page 35]
+
+RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
+
+
+      Section 6.3: added two more requirements to getaddrinfo().
+
+      Section 7: added the following constants to the list for
+      <netdb.h>:  AI_ADDRCONFIG, AI_ALL, and AI_V4MAPPED.  Add union
+      sockaddr_union and SA_LEN to the lists for <sys/socket.h>.
+
+      Updated references.
+
+   Changes made in the November 1997 Edition (-00 draft):
+
+      The data types have been changed to conform with Draft 6.6 of the
+      Posix 1003.1g standard.
+
+      Section 3.2: data type of s6_addr changed to "uint8_t".
+
+      Section 3.3: data type of sin6_family changed to "sa_family_t".
+      data type of sin6_port changed to "in_port_t", data type of
+      sin6_flowinfo changed to "uint32_t".
+
+      Section 3.4: same as Section 3.3, plus data type of sin6_len
+      changed to "uint8_t".
+
+      Section 6.2: first argument of gethostbyaddr() changed from "const
+      char *" to "const void *" and second argument changed from "int"
+      to "size_t".
+
+      Section 6.4: second argument of getnameinfo() changed from
+      "size_t" to "socklen_t".
+
+      The wording was changed when new structures were defined, to be
+      more explicit as to which header must be included to define the
+      structure:
+
+      Section 3.2 (in6_addr{}), Section 3.3 (sockaddr_in6{}), Section
+      3.4 (sockaddr_in6{}), Section 4.3 (if_nameindex{}), Section 5.3
+      (ipv6_mreq{}), and Section 6.3 (addrinfo{}).
+
+      Section 4: NET_RT_LIST changed to NET_RT_IFLIST.
+
+      Section 5.1: The IPV6_ADDRFORM socket option was removed.
+
+      Section 5.3: Added a note that an option value other than 0 or 1
+      for IPV6_MULTICAST_LOOP returns an error.  Added a note that
+      IPV6_MULTICAST_IF, IPV6_MULTICAST_HOPS, and IPV6_MULTICAST_LOOP
+      can also be used with getsockopt(), but IPV6_ADD_MEMBERSHIP and
+      IPV6_DROP_MEMBERSHIP cannot be used with getsockopt().
+
+
+
+
+
+Gilligan, et. al.            Informational                     [Page 36]
+
+RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
+
+
+      Section 6.1: Removed the description of gethostbyname2() and its
+      associated RES_USE_INET6 option, replacing it with
+      gethostbyname3().
+
+      Section 6.2: Added requirement that gethostbyaddr() be thread
+      safe.  Reworded step 4 to avoid using the RES_USE_INET6 option.
+
+      Section 6.3: Added the requirement that getaddrinfo() and
+      getnameinfo() be thread safe.  Added the AI_NUMERICHOST flag.
+
+      Section 6.6: Added clarification about IN6_IS_ADDR_LINKLOCAL and
+      IN6_IS_ADDR_SITELOCAL macros.
+
+   Changes made to the draft -01 specification Sept 98
+
+      Changed priority to traffic class in the spec.
+
+      Added the need for scope identification in section 2.1.
+
+      Added sin6_scope_id to struct sockaddr_in6 in sections 3.3 and
+      3.4.
+
+      Changed 3.10 to use generic storage structure to support holding
+      IPv6 addresses and removed the SA_LEN macro.
+
+      Distinguished between invalid input parameters and system failures
+      for Interface Identification in Section 4.1 and 4.2.
+
+      Added defaults for multicast operations in section 5.2 and changed
+      the names from ADD to JOIN and DROP to LEAVE to be consistent with
+      IPv6 multicast terminology.
+
+      Changed getnodebyname to getipnodebyname, getnodebyaddr to
+      getipnodebyaddr, and added MT safe error code to function
+      parameters in section 6.
+
+      Moved freehostent to its own sub-section after getipnodebyaddr now
+      6.3 (so this bumps all remaining sections in section 6.
+
+      Clarified the use of AI_ALL and AI_V4MAPPED that these are
+      dependent on the AF parameter and must be used as a conjunction in
+      section 6.1.
+
+      Removed the restriction that literal addresses cannot be used with
+      a flags argument in section 6.1.
+
+      Added Year 2000 Section to the draft
+
+
+
+
+Gilligan, et. al.            Informational                     [Page 37]
+
+RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
+
+
+      Deleted Reference to the following because the attached is deleted
+      from the ID directory and has expired.  But the logic from the
+      aforementioned draft still applies, so that was kept in Section
+      6.2 bullets after 3rd paragraph.
+
+      [7]  P. Vixie, "Reverse Name Lookups of Encapsulated IPv4
+           Addresses in IPv6", Internet-Draft, <draft-vixie-ipng-
+           ipv4ptr-00.txt>, May 1996.
+
+      Deleted the following reference as it is no longer referenced.
+      And the draft has expired.
+
+      [3]  D. McDonald, "A Simple IP Security API Extension to BSD
+           Sockets", Internet-Draft, <draft-mcdonald-simple-ipsec-api-
+           01.txt>, March 1997.
+
+      Deleted the following reference as it is no longer referenced.
+
+      [4]  C. Metz, "Network Security API for Sockets",
+           Internet-Draft, <draft-metz-net-security-api-01.txt>, January
+           1998.
+
+      Update current references to current status.
+
+      Added alignment notes for in6_addr and sin6_addr.
+
+      Clarified further that AI_V4MAPPED must be used with a dotted IPv4
+      literal address for getipnodebyname(), when address family is
+      AF_INET6.
+
+      Added text to clarify "::" and "::1" when used by
+      getipnodebyaddr().
+
+Acknowledgments
+
+   Thanks to the many people who made suggestions and provided feedback
+   to this document, including: Werner Almesberger, Ran Atkinson, Fred
+   Baker, Dave Borman, Andrew Cherenson, Alex Conta, Alan Cox, Steve
+   Deering, Richard Draves, Francis Dupont, Robert Elz, Marc Hasson, Tom
+   Herbert, Bob Hinden, Wan-Yen Hsu, Christian Huitema, Koji Imada,
+   Markus Jork, Ron Lee, Alan Lloyd, Charles Lynn, Dan McDonald, Dave
+   Mitton, Thomas Narten, Josh Osborne, Craig Partridge, Jean-Luc
+   Richier, Erik Scoredos, Keith Sklower, Matt Thomas, Harvey Thompson,
+   Dean D. Throop, Karen Tracey, Glenn Trewitt, Paul Vixie, David
+   Waitzman, Carl Williams, and Kazu Yamamoto,
+
+
+
+
+
+
+Gilligan, et. al.            Informational                     [Page 38]
+
+RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
+
+
+   The getaddrinfo() and getnameinfo() functions are taken from an
+   earlier Internet Draft by Keith Sklower.  As noted in that draft,
+   William Durst, Steven Wise, Michael Karels, and Eric Allman provided
+   many useful discussions on the subject of protocol-independent name-
+   to-address translation, and reviewed early versions of Keith
+   Sklower's original proposal.  Eric Allman implemented the first
+   prototype of getaddrinfo().  The observation that specifying the pair
+   of name and service would suffice for connecting to a service
+   independent of protocol details was made by Marshall Rose in a
+   proposal to X/Open for a "Uniform Network Interface".
+
+   Craig Metz, Jack McCann, Erik Nordmark, Tim Hartrick, and Mukesh
+   Kacker made many contributions to this document.  Ramesh Govindan
+   made a number of contributions and co-authored an earlier version of
+   this memo.
+
+References
+
+   [1]  Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
+        Specification", RFC 2460, December 1998.
+
+   [2]  Hinden, R. and S. Deering, "IP Version 6 Addressing
+        Architecture", RFC 2373, July 1998.
+
+   [3]  IEEE, "Protocol Independent Interfaces", IEEE Std 1003.1g, DRAFT
+        6.6, March 1997.
+
+   [4]  Stevens, W. and M. Thomas, "Advanced Sockets API for IPv6", RFC
+        2292, February 1998.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gilligan, et. al.            Informational                     [Page 39]
+
+RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
+
+
+Authors' Addresses
+
+   Robert E. Gilligan
+   FreeGate Corporation
+   1208 E. Arques Ave.
+   Sunnyvale, CA 94086
+
+   Phone: +1 408 617 1004
+   EMail: gilligan@freegate.com
+
+
+   Susan Thomson
+   Bell Communications Research
+   MRE 2P-343, 445 South Street
+   Morristown, NJ 07960
+
+   Phone: +1 201 829 4514
+   EMail: set@thumper.bellcore.com
+
+
+   Jim Bound
+   Compaq Computer Corporation
+   110 Spitbrook Road ZK3-3/U14
+   Nashua, NH 03062-2698
+
+   Phone: +1 603 884 0400
+   EMail: bound@zk3.dec.com
+
+
+   W. Richard Stevens
+   1202 E. Paseo del Zorro
+   Tucson, AZ 85718-2826
+
+   Phone: +1 520 297 9416
+   EMail: rstevens@kohala.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gilligan, et. al.            Informational                     [Page 40]
+
+RFC 2553       Basic Socket Interface Extensions for IPv6     March 1999
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (1999).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gilligan, et. al.            Informational                     [Page 41]
+
diff --git a/doc/rfc/rfc2671.txt b/doc/rfc/rfc2671.txt
new file mode 100644
index 0000000..ec05f80
--- /dev/null
+++ b/doc/rfc/rfc2671.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Network Working Group                                            P. Vixie
+Request for Comments: 2671                                            ISC
+Category: Standards Track                                     August 1999
+
+
+                  Extension Mechanisms for DNS (EDNS0)
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1999).  All Rights Reserved.
+
+Abstract
+
+   The Domain Name System's wire protocol includes a number of fixed
+   fields whose range has been or soon will be exhausted and does not
+   allow clients to advertise their capabilities to servers.  This
+   document describes backward compatible mechanisms for allowing the
+   protocol to grow.
+
+1 - Rationale and Scope
+
+1.1. DNS (see [RFC1035]) specifies a Message Format and within such
+     messages there are standard formats for encoding options, errors,
+     and name compression.  The maximum allowable size of a DNS Message
+     is fixed.  Many of DNS's protocol limits are too small for uses
+     which are or which are desired to become common.  There is no way
+     for implementations to advertise their capabilities.
+
+1.2. Existing clients will not know how to interpret the protocol
+     extensions detailed here.  In practice, these clients will be
+     upgraded when they have need of a new feature, and only new
+     features will make use of the extensions.  We must however take
+     account of client behaviour in the face of extra fields, and design
+     a fallback scheme for interoperability with these clients.
+
+
+
+
+
+
+
+
+
+Vixie                       Standards Track                     [Page 1]
+
+RFC 2671          Extension Mechanisms for DNS (EDNS0)       August 1999
+
+
+2 - Affected Protocol Elements
+
+2.1. The DNS Message Header's (see [RFC1035 4.1.1]) second full 16-bit
+     word is divided into a 4-bit OPCODE, a 4-bit RCODE, and a number of
+     1-bit flags.  The original reserved Z bits have been allocated to
+     various purposes, and most of the RCODE values are now in use.
+     More flags and more possible RCODEs are needed.
+
+2.2. The first two bits of a wire format domain label are used to denote
+     the type of the label.  [RFC1035 4.1.4] allocates two of the four
+     possible types and reserves the other two.  Proposals for use of
+     the remaining types far outnumber those available.  More label
+     types are needed.
+
+2.3. DNS Messages are limited to 512 octets in size when sent over UDP.
+     While the minimum maximum reassembly buffer size still allows a
+     limit of 512 octets of UDP payload, most of the hosts now connected
+     to the Internet are able to reassemble larger datagrams.  Some
+     mechanism must be created to allow requestors to advertise larger
+     buffer sizes to responders.
+
+3 - Extended Label Types
+
+3.1. The "0 1" label type will now indicate an extended label type,
+     whose value is encoded in the lower six bits of the first octet of
+     a label.  All subsequently developed label types should be encoded
+     using an extended label type.
+
+3.2. The "1 1 1 1 1 1" extended label type will be reserved for future
+     expansion of the extended label type code space.
+
+4 - OPT pseudo-RR
+
+4.1. One OPT pseudo-RR can be added to the additional data section of
+     either a request or a response.  An OPT is called a pseudo-RR
+     because it pertains to a particular transport level message and not
+     to any actual DNS data.  OPT RRs shall never be cached, forwarded,
+     or stored in or loaded from master files.  The quantity of OPT
+     pseudo-RRs per message shall be either zero or one, but not
+     greater.
+
+4.2. An OPT RR has a fixed part and a variable set of options expressed
+     as {attribute, value} pairs.  The fixed part holds some DNS meta
+     data and also a small collection of new protocol elements which we
+     expect to be so popular that it would be a waste of wire space to
+     encode them as {attribute, value} pairs.
+
+
+
+
+
+Vixie                       Standards Track                     [Page 2]
+
+RFC 2671          Extension Mechanisms for DNS (EDNS0)       August 1999
+
+
+4.3. The fixed part of an OPT RR is structured as follows:
+
+     Field Name   Field Type     Description
+     ------------------------------------------------------
+     NAME         domain name    empty (root domain)
+     TYPE         u_int16_t      OPT
+     CLASS        u_int16_t      sender's UDP payload size
+     TTL          u_int32_t      extended RCODE and flags
+     RDLEN        u_int16_t      describes RDATA
+     RDATA        octet stream   {attribute,value} pairs
+
+4.4. The variable part of an OPT RR is encoded in its RDATA and is
+     structured as zero or more of the following:
+
+                +0 (MSB)                            +1 (LSB)
+     +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+  0: |                          OPTION-CODE                          |
+     +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+  2: |                         OPTION-LENGTH                         |
+     +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+  4: |                                                               |
+     /                          OPTION-DATA                          /
+     /                                                               /
+     +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+
+   OPTION-CODE    (Assigned by IANA.)
+
+   OPTION-LENGTH  Size (in octets) of OPTION-DATA.
+
+   OPTION-DATA    Varies per OPTION-CODE.
+
+4.5. The sender's UDP payload size (which OPT stores in the RR CLASS
+     field) is the number of octets of the largest UDP payload that can
+     be reassembled and delivered in the sender's network stack.  Note
+     that path MTU, with or without fragmentation, may be smaller than
+     this.
+
+4.5.1. Note that a 512-octet UDP payload requires a 576-octet IP
+       reassembly buffer.  Choosing 1280 on an Ethernet connected
+       requestor would be reasonable.  The consequence of choosing too
+       large a value may be an ICMP message from an intermediate
+       gateway, or even a silent drop of the response message.
+
+4.5.2. Both requestors and responders are advised to take account of the
+       path's discovered MTU (if already known) when considering message
+       sizes.
+
+
+
+
+
+Vixie                       Standards Track                     [Page 3]
+
+RFC 2671          Extension Mechanisms for DNS (EDNS0)       August 1999
+
+
+4.5.3. The requestor's maximum payload size can change over time, and
+       should therefore not be cached for use beyond the transaction in
+       which it is advertised.
+
+4.5.4. The responder's maximum payload size can change over time, but
+       can be reasonably expected to remain constant between two
+       sequential transactions; for example, a meaningless QUERY to
+       discover a responder's maximum UDP payload size, followed
+       immediately by an UPDATE which takes advantage of this size.
+       (This is considered preferrable to the outright use of TCP for
+       oversized requests, if there is any reason to suspect that the
+       responder implements EDNS, and if a request will not fit in the
+       default 512 payload size limit.)
+
+4.5.5. Due to transaction overhead, it is unwise to advertise an
+       architectural limit as a maximum UDP payload size.  Just because
+       your stack can reassemble 64KB datagrams, don't assume that you
+       want to spend more than about 4KB of state memory per ongoing
+       transaction.
+
+4.6. The extended RCODE and flags (which OPT stores in the RR TTL field)
+     are structured as follows:
+
+                 +0 (MSB)                            +1 (LSB)
+      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+   0: |         EXTENDED-RCODE        |            VERSION            |
+      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+   2: |                               Z                               |
+      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+
+   EXTENDED-RCODE  Forms upper 8 bits of extended 12-bit RCODE.  Note
+                   that EXTENDED-RCODE value "0" indicates that an
+                   unextended RCODE is in use (values "0" through "15").
+
+   VERSION         Indicates the implementation level of whoever sets
+                   it.  Full conformance with this specification is
+                   indicated by version "0."  Requestors are encouraged
+                   to set this to the lowest implemented level capable
+                   of expressing a transaction, to minimize the
+                   responder and network load of discovering the
+                   greatest common implementation level between
+                   requestor and responder.  A requestor's version
+                   numbering strategy should ideally be a run time
+                   configuration option.
+
+                   If a responder does not implement the VERSION level
+                   of the request, then it answers with RCODE=BADVERS.
+                   All responses will be limited in format to the
+
+
+
+Vixie                       Standards Track                     [Page 4]
+
+RFC 2671          Extension Mechanisms for DNS (EDNS0)       August 1999
+
+
+                   VERSION level of the request, but the VERSION of each
+                   response will be the highest implementation level of
+                   the responder.  In this way a requestor will learn
+                   the implementation level of a responder as a side
+                   effect of every response, including error responses,
+                   including RCODE=BADVERS.
+
+   Z               Set to zero by senders and ignored by receivers,
+                   unless modified in a subsequent specification.
+
+5 - Transport Considerations
+
+5.1. The presence of an OPT pseudo-RR in a request should be taken as an
+     indication that the requestor fully implements the given version of
+     EDNS, and can correctly understand any response that conforms to
+     that feature's specification.
+
+5.2. Lack of use of these features in a request must be taken as an
+     indication that the requestor does not implement any part of this
+     specification and that the responder may make no use of any
+     protocol extension described here in its response.
+
+5.3. Responders who do not understand these protocol extensions are
+     expected to send a response with RCODE NOTIMPL, FORMERR, or
+     SERVFAIL.  Therefore use of extensions should be "probed" such that
+     a responder who isn't known to support them be allowed a retry with
+     no extensions if it responds with such an RCODE.  If a responder's
+     capability level is cached by a requestor, a new probe should be
+     sent periodically to test for changes to responder capability.
+
+6 - Security Considerations
+
+     Requestor-side specification of the maximum buffer size may open a
+     new DNS denial of service attack if responders can be made to send
+     messages which are too large for intermediate gateways to forward,
+     thus leading to potential ICMP storms between gateways and
+     responders.
+
+7 - IANA Considerations
+
+     The IANA has assigned RR type code 41 for OPT.
+
+     It is the recommendation of this document and its working group
+     that IANA create a registry for EDNS Extended Label Types, for EDNS
+     Option Codes, and for EDNS Version Numbers.
+
+     This document assigns label type 0b01xxxxxx as "EDNS Extended Label
+     Type."  We request that IANA record this assignment.
+
+
+
+Vixie                       Standards Track                     [Page 5]
+
+RFC 2671          Extension Mechanisms for DNS (EDNS0)       August 1999
+
+
+     This document assigns extended label type 0bxx111111 as "Reserved
+     for future extended label types."  We request that IANA record this
+     assignment.
+
+     This document assigns option code 65535 to "Reserved for future
+     expansion."
+
+     This document expands the RCODE space from 4 bits to 12 bits.  This
+     will allow IANA to assign more than the 16 distinct RCODE values
+     allowed in [RFC1035].
+
+     This document assigns EDNS Extended RCODE "16" to "BADVERS".
+
+     IESG approval should be required to create new entries in the EDNS
+     Extended Label Type or EDNS Version Number registries, while any
+     published RFC (including Informational, Experimental, or BCP)
+     should be grounds for allocation of an EDNS Option Code.
+
+8 - Acknowledgements
+
+     Paul Mockapetris, Mark Andrews, Robert Elz, Don Lewis, Bob Halley,
+     Donald Eastlake, Rob Austein, Matt Crawford, Randy Bush, and Thomas
+     Narten were each instrumental in creating and refining this
+     specification.
+
+9 - References
+
+    [RFC1035]  Mockapetris, P., "Domain Names - Implementation and
+               Specification", STD 13, RFC 1035, November 1987.
+
+10 - Author's Address
+
+   Paul Vixie
+   Internet Software Consortium
+   950 Charter Street
+   Redwood City, CA 94063
+
+   Phone: +1 650 779 7001
+   EMail: vixie@isc.org
+
+
+
+
+
+
+
+
+
+
+
+
+Vixie                       Standards Track                     [Page 6]
+
+RFC 2671          Extension Mechanisms for DNS (EDNS0)       August 1999
+
+
+11 - Full Copyright Statement
+
+   Copyright (C) The Internet Society (1999).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Vixie                       Standards Track                     [Page 7]
+
diff --git a/doc/rfc/rfc2672.txt b/doc/rfc/rfc2672.txt
new file mode 100644
index 0000000..1103016
--- /dev/null
+++ b/doc/rfc/rfc2672.txt
@@ -0,0 +1,507 @@
+
+
+
+
+
+
+Network Working Group                                        M. Crawford
+Request for Comments: 2672                                      Fermilab
+Category: Standards Track                                    August 1999
+
+
+                   Non-Terminal DNS Name Redirection
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1999).  All Rights Reserved.
+
+1.  Introduction
+
+   This document defines a new DNS Resource Record called "DNAME", which
+   provides the capability to map an entire subtree of the DNS name
+   space to another domain.  It differs from the CNAME record which maps
+   a single node of the name space.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [KWORD].
+
+2.  Motivation
+
+   This Resource Record and its processing rules were conceived as a
+   solution to the problem of maintaining address-to-name mappings in a
+   context of network renumbering.  Without the DNAME mechanism, an
+   authoritative DNS server for the address-to-name mappings of some
+   network must be reconfigured when that network is renumbered.  With
+   DNAME, the zone can be constructed so that it needs no modification
+   when renumbered.  DNAME can also be useful in other situations, such
+   as when an organizational unit is renamed.
+
+3. The DNAME Resource Record
+
+   The DNAME RR has mnemonic DNAME and type code 39 (decimal).
+
+
+
+
+
+
+
+Crawford                    Standards Track                     [Page 1]
+
+RFC 2672           Non-Terminal DNS Name Redirection         August 1999
+
+
+   DNAME has the following format:
+
+      <owner> <ttl> <class> DNAME <target>
+
+   The format is not class-sensitive.  All fields are required.  The
+   RDATA field <target> is a <domain-name> [DNSIS].
+
+   The DNAME RR causes type NS additional section processing.
+
+   The effect of the DNAME record is the substitution of the record's
+   <target> for its <owner> as a suffix of a domain name.  A "no-
+   descendants" limitation governs the use of DNAMEs in a zone file:
+
+      If a DNAME RR is present at a node N, there may be other data at N
+      (except a CNAME or another DNAME), but there MUST be no data at
+      any descendant of N.  This restriction applies only to records of
+      the same class as the DNAME record.
+
+   This rule assures predictable results when a DNAME record is cached
+   by a server which is not authoritative for the record's zone.  It
+   MUST be enforced when authoritative zone data is loaded.  Together
+   with the rules for DNS zone authority [DNSCLR] it implies that DNAME
+   and NS records can only coexist at the top of a zone which has only
+   one node.
+
+   The compression scheme of [DNSIS] MUST NOT be applied to the RDATA
+   portion of a DNAME record unless the sending server has some way of
+   knowing that the receiver understands the DNAME record format.
+   Signalling such understanding is expected to be the subject of future
+   DNS Extensions.
+
+   Naming loops can be created with DNAME records or a combination of
+   DNAME and CNAME records, just as they can with CNAME records alone.
+   Resolvers, including resolvers embedded in DNS servers, MUST limit
+   the resources they devote to any query.  Implementors should note,
+   however, that fairly lengthy chains of DNAME records may be valid.
+
+4.  Query Processing
+
+   To exploit the DNAME mechanism the name resolution algorithms [DNSCF]
+   must be modified slightly for both servers and resolvers.
+
+   Both modified algorithms incorporate the operation of making a
+   substitution on a name (either QNAME or SNAME) under control of a
+   DNAME record.  This operation will be referred to as "the DNAME
+   substitution".
+
+
+
+
+
+Crawford                    Standards Track                     [Page 2]
+
+RFC 2672           Non-Terminal DNS Name Redirection         August 1999
+
+
+4.1.  Processing by Servers
+
+   For a server performing non-recursive service steps 3.c and 4 of
+   section 4.3.2 [DNSCF] are changed to check for a DNAME record before
+   checking for a wildcard ("*") label, and to return certain DNAME
+   records from zone data and the cache.
+
+   DNS clients sending Extended DNS [EDNS0] queries with Version 0 or
+   non-extended queries are presumed not to understand the semantics of
+   the DNAME record, so a server which implements this specification,
+   when answering a non-extended query, SHOULD synthesize a CNAME record
+   for each DNAME record encountered during query processing to help the
+   client reach the correct DNS data.  The behavior of clients and
+   servers under Extended DNS versions greater than 0 will be specified
+   when those versions are defined.
+
+   The synthesized CNAME RR, if provided, MUST have
+
+      The same CLASS as the QCLASS of the query,
+
+      TTL equal to zero,
+
+      An <owner> equal to the QNAME in effect at the moment the DNAME RR
+      was encountered, and
+
+      An RDATA field containing the new QNAME formed by the action of
+      the DNAME substitution.
+
+   If the server has the appropriate key on-line [DNSSEC, SECDYN], it
+   MAY generate and return a SIG RR for the synthesized CNAME RR.
+
+   The revised server algorithm is:
+
+   1. Set or clear the value of recursion available in the response
+      depending on whether the name server is willing to provide
+      recursive service.  If recursive service is available and
+      requested via the RD bit in the query, go to step 5, otherwise
+      step 2.
+
+   2. Search the available zones for the zone which is the nearest
+      ancestor to QNAME.  If such a zone is found, go to step 3,
+      otherwise step 4.
+
+   3. Start matching down, label by label, in the zone.  The matching
+      process can terminate several ways:
+
+
+
+
+
+
+Crawford                    Standards Track                     [Page 3]
+
+RFC 2672           Non-Terminal DNS Name Redirection         August 1999
+
+
+      a. If the whole of QNAME is matched, we have found the node.
+
+         If the data at the node is a CNAME, and QTYPE doesn't match
+         CNAME, copy the CNAME RR into the answer section of the
+         response, change QNAME to the canonical name in the CNAME RR,
+         and go back to step 1.
+
+         Otherwise, copy all RRs which match QTYPE into the answer
+         section and go to step 6.
+
+      b. If a match would take us out of the authoritative data, we have
+         a referral.  This happens when we encounter a node with NS RRs
+         marking cuts along the bottom of a zone.
+
+         Copy the NS RRs for the subzone into the authority section of
+         the reply.  Put whatever addresses are available into the
+         additional section, using glue RRs if the addresses are not
+         available from authoritative data or the cache.  Go to step 4.
+
+      c. If at some label, a match is impossible (i.e., the
+         corresponding label does not exist), look to see whether the
+         last label matched has a DNAME record.
+
+         If a DNAME record exists at that point, copy that record into
+         the answer section.  If substitution of its <target> for its
+         <owner> in QNAME would overflow the legal size for a <domain-
+         name>, set RCODE to YXDOMAIN [DNSUPD] and exit; otherwise
+         perform the substitution and continue.  If the query was not
+         extended [EDNS0] with a Version indicating understanding of the
+         DNAME record, the server SHOULD synthesize a CNAME record as
+         described above and include it in the answer section.  Go back
+         to step 1.
+
+         If there was no DNAME record, look to see if the "*" label
+         exists.
+
+         If the "*" label does not exist, check whether the name we are
+         looking for is the original QNAME in the query or a name we
+         have followed due to a CNAME.  If the name is original, set an
+         authoritative name error in the response and exit.  Otherwise
+         just exit.
+
+         If the "*" label does exist, match RRs at that node against
+         QTYPE.  If any match, copy them into the answer section, but
+         set the owner of the RR to be QNAME, and not the node with the
+         "*" label.  Go to step 6.
+
+
+
+
+
+Crawford                    Standards Track                     [Page 4]
+
+RFC 2672           Non-Terminal DNS Name Redirection         August 1999
+
+
+   4. Start matching down in the cache.  If QNAME is found in the cache,
+      copy all RRs attached to it that match QTYPE into the answer
+      section.  If QNAME is not found in the cache but a DNAME record is
+      present at an ancestor of QNAME, copy that DNAME record into the
+      answer section.  If there was no delegation from authoritative
+      data, look for the best one from the cache, and put it in the
+      authority section.  Go to step 6.
+
+   5. Use the local resolver or a copy of its algorithm (see resolver
+      section of this memo) to answer the query.  Store the results,
+      including any intermediate CNAMEs and DNAMEs, in the answer
+      section of the response.
+
+   6. Using local data only, attempt to add other RRs which may be
+      useful to the additional section of the query.  Exit.
+
+   Note that there will be at most one ancestor with a DNAME as
+   described in step 4 unless some zone's data is in violation of the
+   no-descendants limitation in section 3.  An implementation might take
+   advantage of this limitation by stopping the search of step 3c or
+   step 4 when a DNAME record is encountered.
+
+4.2.  Processing by Resolvers
+
+   A resolver or a server providing recursive service must be modified
+   to treat a DNAME as somewhat analogous to a CNAME.  The resolver
+   algorithm of [DNSCF] section 5.3.3 is modified to renumber step 4.d
+   as 4.e and insert a new 4.d.  The complete algorithm becomes:
+
+   1. See if the answer is in local information, and if so return it to
+      the client.
+
+   2. Find the best servers to ask.
+
+   3. Send them queries until one returns a response.
+
+   4. Analyze the response, either:
+
+      a. if the response answers the question or contains a name error,
+         cache the data as well as returning it back to the client.
+
+      b. if the response contains a better delegation to other servers,
+         cache the delegation information, and go to step 2.
+
+      c. if the response shows a CNAME and that is not the answer
+         itself, cache the CNAME, change the SNAME to the canonical name
+         in the CNAME RR and go to step 1.
+
+
+
+
+Crawford                    Standards Track                     [Page 5]
+
+RFC 2672           Non-Terminal DNS Name Redirection         August 1999
+
+
+      d. if the response shows a DNAME and that is not the answer
+         itself, cache the DNAME.  If substitution of the DNAME's
+         <target> for its <owner> in the SNAME would overflow the legal
+         size for a <domain-name>, return an implementation-dependent
+         error to the application; otherwise perform the substitution
+         and go to step 1.
+
+      e. if the response shows a server failure or other bizarre
+         contents, delete the server from the SLIST and go back to step
+         3.
+
+   A resolver or recursive server which understands DNAME records but
+   sends non-extended queries MUST augment step 4.c by deleting from the
+   reply any CNAME records which have an <owner> which is a subdomain of
+   the <owner> of any DNAME record in the response.
+
+5.  Examples of Use
+
+5.1.  Organizational Renaming
+
+   If an organization with domain name FROBOZZ.EXAMPLE became part of an
+   organization with domain name ACME.EXAMPLE, it might ease transition
+   by placing information such as this in its old zone.
+
+       frobozz.example.  DNAME    frobozz-division.acme.example.
+                         MX       10       mailhub.acme.example.
+
+   The response to an extended recursive query for www.frobozz.example
+   would contain, in the answer section, the DNAME record shown above
+   and the relevant RRs for www.frobozz-division.acme.example.
+
+5.2.  Classless Delegation of Shorter Prefixes
+
+   The classless scheme for in-addr.arpa delegation [INADDR] can be
+   extended to prefixes shorter than 24 bits by use of the DNAME record.
+   For example, the prefix 192.0.8.0/22 can be delegated by the
+   following records.
+
+       $ORIGIN 0.192.in-addr.arpa.
+       8/22    NS       ns.slash-22-holder.example.
+       8       DNAME    8.8/22
+       9       DNAME    9.8/22
+       10      DNAME    10.8/22
+       11      DNAME    11.8/22
+
+
+
+
+
+
+
+Crawford                    Standards Track                     [Page 6]
+
+RFC 2672           Non-Terminal DNS Name Redirection         August 1999
+
+
+   A typical entry in the resulting reverse zone for some host with
+   address 192.0.9.33 might be
+
+       $ORIGIN 8/22.0.192.in-addr.arpa.
+       33.9    PTR     somehost.slash-22-holder.example.
+
+   The same advisory remarks concerning the choice of the "/" character
+   apply here as in [INADDR].
+
+5.3.  Network Renumbering Support
+
+   If IPv4 network renumbering were common, maintenance of address space
+   delegation could be simplified by using DNAME records instead of NS
+   records to delegate.
+
+      $ORIGIN new-style.in-addr.arpa.
+      189.190           DNAME    in-addr.example.net.
+
+      $ORIGIN in-addr.example.net.
+      188               DNAME    in-addr.customer.example.
+
+      $ORIGIN in-addr.customer.example.
+      1                 PTR      www.customer.example.
+      2                 PTR      mailhub.customer.example.
+      ; etc ...
+
+   This would allow the address space 190.189.0.0/16 assigned to the ISP
+   "example.net" to be changed without the necessity of altering the
+   zone files describing the use of that space by the ISP and its
+   customers.
+
+   Renumbering IPv4 networks is currently so arduous a task that
+   updating the DNS is only a small part of the labor, so this scheme
+   may have a low value.  But it is hoped that in IPv6 the renumbering
+   task will be quite different and the DNAME mechanism may play a
+   useful part.
+
+6.  IANA Considerations
+
+   This document defines a new DNS Resource Record type with the
+   mnemonic DNAME and type code 39 (decimal).  The naming/numbering
+   space is defined in [DNSIS].  This name and number have already been
+   registered with the IANA.
+
+
+
+
+
+
+
+
+Crawford                    Standards Track                     [Page 7]
+
+RFC 2672           Non-Terminal DNS Name Redirection         August 1999
+
+
+7.  Security Considerations
+
+   The DNAME record is similar to the CNAME record with regard to the
+   consequences of insertion of a spoofed record into a DNS server or
+   resolver, differing in that the DNAME's effect covers a whole subtree
+   of the name space.  The facilities of [DNSSEC] are available to
+   authenticate this record type.
+
+8.  References
+
+   [DNSCF]  Mockapetris, P., "Domain names - concepts and facilities",
+            STD 13, RFC 1034, November 1987.
+
+   [DNSCLR] Elz, R. and R. Bush, "Clarifications to the DNS
+            Specification", RFC 2181, July 1997.
+
+   [DNSIS]  Mockapetris, P., "Domain names - implementation and
+            specification", STD 13, RFC 1035, November 1987.
+
+   [DNSSEC] Eastlake, 3rd, D. and C. Kaufman, "Domain Name System
+            Security Extensions", RFC 2065, January 1997.
+
+   [DNSUPD] Vixie, P., Ed., Thomson, S., Rekhter, Y. and J. Bound,
+            "Dynamic Updates in the Domain Name System", RFC 2136, April
+            1997.
+
+   [EDNS0]  Vixie, P., "Extensions mechanisms for DNS (EDNS0)", RFC
+            2671, August 1999.
+
+   [INADDR] Eidnes, H., de Groot, G. and P. Vixie, "Classless IN-
+            ADDR.ARPA delegation", RFC 2317, March 1998.
+
+   [KWORD]  Bradner, S., "Key words for use in RFCs to Indicate
+            Requirement Levels," BCP 14, RFC 2119, March 1997.
+
+   [SECDYN] D. Eastlake, 3rd, "Secure Domain Name System Dynamic
+            Update", RFC 2137, April 1997.
+
+9.  Author's Address
+
+   Matt Crawford
+   Fermilab MS 368
+   PO Box 500
+   Batavia, IL 60510
+   USA
+
+   Phone: +1 630 840-3461
+   EMail: crawdad@fnal.gov
+
+
+
+Crawford                    Standards Track                     [Page 8]
+
+RFC 2672           Non-Terminal DNS Name Redirection         August 1999
+
+
+10.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (1999).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crawford                    Standards Track                     [Page 9]
+
diff --git a/doc/rfc/rfc2673.txt b/doc/rfc/rfc2673.txt
new file mode 100644
index 0000000..19d272e
--- /dev/null
+++ b/doc/rfc/rfc2673.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Network Working Group                                        M. Crawford
+Request for Comments: 2673                                      Fermilab
+Category: Standards Track                                    August 1999
+
+
+                Binary Labels in the Domain Name System
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1999).  All Rights Reserved.
+
+1.  Introduction and Terminology
+
+   This document defines a "Bit-String Label" which may appear within
+   domain names.  This new label type compactly represents a sequence of
+   "One-Bit Labels" and enables resource records to be stored at any
+   bit-boundary in a binary-named section of the domain name tree.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [KWORD].
+
+2.  Motivation
+
+   Binary labels are intended to efficiently solve the problem of
+   storing data and delegating authority on arbitrary boundaries when
+   the structure of underlying name space is most naturally represented
+   in binary.
+
+3.  Label Format
+
+   Up to 256 One-Bit Labels can be grouped into a single Bit-String
+   Label.  Within a Bit-String Label the most significant or "highest
+   level" bit appears first.  This is unlike the ordering of DNS labels
+   themselves, which has the least significant or "lowest level" label
+   first.  Nonetheless, this ordering seems to be the most natural and
+   efficient for representing binary labels.
+
+
+
+
+
+
+Crawford                    Standards Track                     [Page 1]
+
+RFC 2673        Binary Labels in the Domain Name System      August 1999
+
+
+   Among consecutive Bit-String Labels, the bits in the first-appearing
+   label are less significant or "at a lower level" than the bits in
+   subsequent Bit-String Labels, just as ASCII labels are ordered.
+
+3.1.  Encoding
+
+      0                   1                   2
+      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2     . . .
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-//+-+-+-+-+-+-+
+     |0 1|    ELT    |     Count     |           Label ...         |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+//-+-+-+-+-+-+-+
+
+   (Each tic mark represents one bit.)
+
+
+   ELT       000001 binary, the six-bit extended label type [EDNS0]
+             assigned to the Bit-String Label.
+
+   Count     The number of significant bits in the Label field.  A Count
+             value of zero indicates that 256 bits are significant.
+             (Thus the null label representing the DNS root cannot be
+             represented as a Bit String Label.)
+
+   Label     The bit string representing a sequence of One-Bit Labels,
+             with the most significant bit first.  That is, the One-Bit
+             Label in position 17 in the diagram above represents a
+             subdomain of the domain represented by the One-Bit Label in
+             position 16, and so on.
+
+             The Label field is padded on the right with zero to seven
+             pad bits to make the entire field occupy an integral number
+             of octets.  These pad bits MUST be zero on transmission and
+             ignored on reception.
+
+   A sequence of bits may be split into two or more Bit-String Labels,
+   but the division points have no significance and need not be
+   preserved.  An excessively clever server implementation might split
+   Bit-String Labels so as to maximize the effectiveness of message
+   compression [DNSIS].  A simpler server might divide Bit-String Labels
+   at zone boundaries, if any zone boundaries happen to fall between
+   One-Bit Labels.
+
+3.2.  Textual Representation
+
+   A Bit-String Label is represented in text -- in a zone file, for
+   example -- as a <bit-spec> surrounded by the delimiters "\[" and "]".
+   The <bit-spec> is either a dotted quad or a base indicator and a
+   sequence of digits appropriate to that base, optionally followed by a
+
+
+
+Crawford                    Standards Track                     [Page 2]
+
+RFC 2673        Binary Labels in the Domain Name System      August 1999
+
+
+   slash and a length.  The base indicators are "b", "o" and "x",
+   denoting base 2, 8 and 16 respectively.  The length counts the
+   significant bits and MUST be between 1 and 32, inclusive, after a
+   dotted quad, or between 1 and 256, inclusive, after one of the other
+   forms.  If the length is omitted, the implicit length is 32 for a
+   dotted quad or 1, 3 or 4 times the number of binary, octal or
+   hexadecimal digits supplied, respectively, for the other forms.
+
+   In augmented Backus-Naur form [ABNF],
+
+     bit-string-label =  "\[" bit-spec "]"
+
+     bit-spec         =  bit-data [ "/" length ]
+                       / dotted-quad [ "/" slength ]
+
+     bit-data         =  "x" 1*64HEXDIG
+                       / "o" 1*86OCTDIG
+                       / "b" 1*256BIT
+
+     dotted-quad      =  decbyte "." decbyte "." decbyte "." decbyte
+
+     decbyte          =  1*3DIGIT
+
+     length           =  NZDIGIT *2DIGIT
+
+     slength          =  NZDIGIT [ DIGIT ]
+
+     OCTDIG           =  %x30-37
+
+     NZDIGIT          =  %x31-39
+
+   If a <length> is present, the number of digits in the <bit-data> MUST
+   be just sufficient to contain the number of bits specified by the
+   <length>.  If there are insignificant bits in a final hexadecimal or
+   octal digit, they MUST be zero.  A <dotted-quad> always has all four
+   parts even if the associated <slength> is less than 24, but, like the
+   other forms, insignificant bits MUST be zero.
+
+   Each number represented by a <decbyte> must be between 0 and 255,
+   inclusive.
+
+   The number represented by <length> must be between 1 and 256
+   inclusive.
+
+   The number represented by <slength> must be between 1 and 32
+   inclusive.
+
+
+
+
+
+Crawford                    Standards Track                     [Page 3]
+
+RFC 2673        Binary Labels in the Domain Name System      August 1999
+
+
+   When the textual form of a Bit-String Label is generated by machine,
+   the length SHOULD be explicit, not implicit.
+
+3.2.1.  Examples
+
+   The following four textual forms represent the same Bit-String Label.
+
+                             \[b11010000011101]
+                             \[o64072/14]
+                             \[xd074/14]
+                             \[208.116.0.0/14]
+
+   The following represents two consecutive Bit-String Labels which
+   denote the same relative point in the DNS tree as any of the above
+   single Bit-String Labels.
+
+                             \[b11101].\[o640]
+
+3.3.  Canonical Representation and Sort Order
+
+   Both the wire form and the text form of binary labels have a degree
+   of flexibility in their grouping into multiple consecutive Bit-String
+   Labels.  For generating and checking DNS signature records [DNSSEC]
+   binary labels must be in a predictable form.  This canonical form is
+   defined as the form which has the fewest possible Bit-String Labels
+   and in which all except possibly the first (least significant) label
+   in any sequence of consecutive Bit-String Labels is of maximum
+   length.
+
+   For example, the canonical form of any sequence of up to 256 One-Bit
+   Labels has a single Bit-String Label, and the canonical form of a
+   sequence of 513 to 768 One-Bit Labels has three Bit-String Labels of
+   which the second and third contain 256 label bits.
+
+   The canonical sort order of domain names [DNSSEC] is extended to
+   encompass binary labels as follows.  Sorting is still label-by-label,
+   from most to least significant, where a label may now be a One-Bit
+   Label or a standard (code 00) label.  Any One-Bit Label sorts before
+   any standard label, and a 0 bit sorts before a 1 bit.  The absence of
+   a label sorts before any label, as specified in [DNSSEC].
+
+
+
+
+
+
+
+
+
+
+
+Crawford                    Standards Track                     [Page 4]
+
+RFC 2673        Binary Labels in the Domain Name System      August 1999
+
+
+   For example, the following domain names are correctly sorted.
+
+                         foo.example
+                         \[b1].foo.example
+                         \[b100].foo.example
+                         \[b101].foo.example
+                         bravo.\[b10].foo.example
+                         alpha.foo.example
+
+4.  Processing Rules
+
+   A One-Bit Label never matches any other kind of label.  In
+   particular, the DNS labels represented by the single ASCII characters
+   "0" and "1" do not match One-Bit Labels represented by the bit values
+   0 and 1.
+
+5.  Discussion
+
+   A Count of zero in the wire-form represents a 256-bit sequence, not
+   to optimize that particular case, but to make it completely
+   impossible to have a zero-bit label.
+
+6.  IANA Considerations
+
+   This document defines one Extended Label Type, termed the Bit-String
+   Label, and requests registration of the code point 000001 binary in
+   the space defined by [EDNS0].
+
+7.  Security Considerations
+
+   All security considerations which apply to traditional ASCII DNS
+   labels apply equally to binary labels.  he canonicalization and
+   sorting rules of section 3.3 allow these to be addressed by DNS
+   Security [DNSSEC].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crawford                    Standards Track                     [Page 5]
+
+RFC 2673        Binary Labels in the Domain Name System      August 1999
+
+
+8.  References
+
+   [ABNF]   Crocker, D. and P. Overell, "Augmented BNF for Syntax
+            Specifications: ABNF", RFC 2234, November 1997.
+
+   [DNSIS]  Mockapetris, P., "Domain names - implementation and
+            specification", STD 13, RFC 1035, November 1987.
+
+   [DNSSEC] Eastlake, D., 3rd, C. Kaufman, "Domain Name System Security
+            Extensions", RFC 2065, January 1997
+
+   [EDNS0]  Vixie, P., "Extension mechanisms for DNS (EDNS0)", RFC 2671,
+            August 1999.
+
+   [KWORD]  Bradner, S., "Key words for use in RFCs to Indicate
+            Requirement Levels," BCP 14, RFC 2119, March 1997.
+
+9.  Author's Address
+
+   Matt Crawford
+   Fermilab MS 368
+   PO Box 500
+   Batavia, IL 60510
+   USA
+
+   Phone: +1 630 840-3461
+   EMail: crawdad@fnal.gov
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crawford                    Standards Track                     [Page 6]
+
+RFC 2673        Binary Labels in the Domain Name System      August 1999
+
+
+10.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (1999).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crawford                    Standards Track                     [Page 7]
+
diff --git a/doc/rfc/rfc2782.txt b/doc/rfc/rfc2782.txt
new file mode 100644
index 0000000..1827f10
--- /dev/null
+++ b/doc/rfc/rfc2782.txt
@@ -0,0 +1,675 @@
+
+
+
+
+
+
+Network Working Group                                     A. Gulbrandsen
+Request for Comments: 2782                            Troll Technologies
+Obsoletes: 2052                                                 P. Vixie
+Category: Standards Track                   Internet Software Consortium
+                                                               L. Esibov
+                                                         Microsoft Corp.
+                                                           February 2000
+
+
+       A DNS RR for specifying the location of services (DNS SRV)
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2000).  All Rights Reserved.
+
+Abstract
+
+   This document describes a DNS RR which specifies the location of the
+   server(s) for a specific protocol and domain.
+
+Overview and rationale
+
+   Currently, one must either know the exact address of a server to
+   contact it, or broadcast a question.
+
+   The SRV RR allows administrators to use several servers for a single
+   domain, to move services from host to host with little fuss, and to
+   designate some hosts as primary servers for a service and others as
+   backups.
+
+   Clients ask for a specific service/protocol for a specific domain
+   (the word domain is used here in the strict RFC 1034 sense), and get
+   back the names of any available servers.
+
+   Note that where this document refers to "address records", it means A
+   RR's, AAAA RR's, or their most modern equivalent.
+
+
+
+
+
+
+
+Gulbrandsen, et al.         Standards Track                     [Page 1]
+
+RFC 2782                       DNS SRV RR                  February 2000
+
+
+Definitions
+
+   The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT" and "MAY"
+   used in this document are to be interpreted as specified in [BCP 14].
+   Other terms used in this document are defined in the DNS
+   specification, RFC 1034.
+
+Applicability Statement
+
+   In general, it is expected that SRV records will be used by clients
+   for applications where the relevant protocol specification indicates
+   that clients should use the SRV record. Such specification MUST
+   define the symbolic name to be used in the Service field of the SRV
+   record as described below. It also MUST include security
+   considerations. Service SRV records SHOULD NOT be used in the absence
+   of such specification.
+
+Introductory example
+
+   If a SRV-cognizant LDAP client wants to discover a LDAP server that
+   supports TCP protocol and provides LDAP service for the domain
+   example.com., it does a lookup of
+
+      _ldap._tcp.example.com
+
+   as described in [ARM].  The example zone file near the end of this
+   memo contains answering RRs for an SRV query.
+
+   Note: LDAP is chosen as an example for illustrative purposes only,
+   and the LDAP examples used in this document should not be considered
+   a definitive statement on the recommended way for LDAP to use SRV
+   records. As described in the earlier applicability section, consult
+   the appropriate LDAP documents for the recommended procedures.
+
+The format of the SRV RR
+
+   Here is the format of the SRV RR, whose DNS type code is 33:
+
+        _Service._Proto.Name TTL Class SRV Priority Weight Port Target
+
+        (There is an example near the end of this document.)
+
+   Service
+        The symbolic name of the desired service, as defined in Assigned
+        Numbers [STD 2] or locally.  An underscore (_) is prepended to
+        the service identifier to avoid collisions with DNS labels that
+        occur in nature.
+
+
+
+
+Gulbrandsen, et al.         Standards Track                     [Page 2]
+
+RFC 2782                       DNS SRV RR                  February 2000
+
+
+        Some widely used services, notably POP, don't have a single
+        universal name.  If Assigned Numbers names the service
+        indicated, that name is the only name which is legal for SRV
+        lookups.  The Service is case insensitive.
+
+   Proto
+        The symbolic name of the desired protocol, with an underscore
+        (_) prepended to prevent collisions with DNS labels that occur
+        in nature.  _TCP and _UDP are at present the most useful values
+        for this field, though any name defined by Assigned Numbers or
+        locally may be used (as for Service).  The Proto is case
+        insensitive.
+
+   Name
+        The domain this RR refers to.  The SRV RR is unique in that the
+        name one searches for is not this name; the example near the end
+        shows this clearly.
+
+   TTL
+        Standard DNS meaning [RFC 1035].
+
+   Class
+        Standard DNS meaning [RFC 1035].   SRV records occur in the IN
+        Class.
+
+   Priority
+        The priority of this target host.  A client MUST attempt to
+        contact the target host with the lowest-numbered priority it can
+        reach; target hosts with the same priority SHOULD be tried in an
+        order defined by the weight field.  The range is 0-65535.  This
+        is a 16 bit unsigned integer in network byte order.
+
+   Weight
+        A server selection mechanism.  The weight field specifies a
+        relative weight for entries with the same priority. Larger
+        weights SHOULD be given a proportionately higher probability of
+        being selected. The range of this number is 0-65535.  This is a
+        16 bit unsigned integer in network byte order.  Domain
+        administrators SHOULD use Weight 0 when there isn't any server
+        selection to do, to make the RR easier to read for humans (less
+        noisy).  In the presence of records containing weights greater
+        than 0, records with weight 0 should have a very small chance of
+        being selected.
+
+        In the absence of a protocol whose specification calls for the
+        use of other weighting information, a client arranges the SRV
+        RRs of the same Priority in the order in which target hosts,
+
+
+
+
+Gulbrandsen, et al.         Standards Track                     [Page 3]
+
+RFC 2782                       DNS SRV RR                  February 2000
+
+
+        specified by the SRV RRs, will be contacted. The following
+        algorithm SHOULD be used to order the SRV RRs of the same
+        priority:
+
+        To select a target to be contacted next, arrange all SRV RRs
+        (that have not been ordered yet) in any order, except that all
+        those with weight 0 are placed at the beginning of the list.
+
+        Compute the sum of the weights of those RRs, and with each RR
+        associate the running sum in the selected order. Then choose a
+        uniform random number between 0 and the sum computed
+        (inclusive), and select the RR whose running sum value is the
+        first in the selected order which is greater than or equal to
+        the random number selected. The target host specified in the
+        selected SRV RR is the next one to be contacted by the client.
+        Remove this SRV RR from the set of the unordered SRV RRs and
+        apply the described algorithm to the unordered SRV RRs to select
+        the next target host.  Continue the ordering process until there
+        are no unordered SRV RRs.  This process is repeated for each
+        Priority.
+
+   Port
+        The port on this target host of this service.  The range is 0-
+        65535.  This is a 16 bit unsigned integer in network byte order.
+        This is often as specified in Assigned Numbers but need not be.
+
+   Target
+        The domain name of the target host.  There MUST be one or more
+        address records for this name, the name MUST NOT be an alias (in
+        the sense of RFC 1034 or RFC 2181).  Implementors are urged, but
+        not required, to return the address record(s) in the Additional
+        Data section.  Unless and until permitted by future standards
+        action, name compression is not to be used for this field.
+
+        A Target of "." means that the service is decidedly not
+        available at this domain.
+
+Domain administrator advice
+
+   Expecting everyone to update their client applications when the first
+   server publishes a SRV RR is futile (even if desirable).  Therefore
+   SRV would have to coexist with address record lookups for existing
+   protocols, and DNS administrators should try to provide address
+   records to support old clients:
+
+      - Where the services for a single domain are spread over several
+        hosts, it seems advisable to have a list of address records at
+        the same DNS node as the SRV RR, listing reasonable (if perhaps
+
+
+
+Gulbrandsen, et al.         Standards Track                     [Page 4]
+
+RFC 2782                       DNS SRV RR                  February 2000
+
+
+        suboptimal) fallback hosts for Telnet, NNTP and other protocols
+        likely to be used with this name.  Note that some programs only
+        try the first address they get back from e.g. gethostbyname(),
+        and we don't know how widespread this behavior is.
+
+      - Where one service is provided by several hosts, one can either
+        provide address records for all the hosts (in which case the
+        round-robin mechanism, where available, will share the load
+        equally) or just for one (presumably the fastest).
+
+      - If a host is intended to provide a service only when the main
+        server(s) is/are down, it probably shouldn't be listed in
+        address records.
+
+      - Hosts that are referenced by backup address records must use the
+        port number specified in Assigned Numbers for the service.
+
+      - Designers of future protocols for which "secondary servers" is
+        not useful (or meaningful) may choose to not use SRV's support
+        for secondary servers.  Clients for such protocols may use or
+        ignore SRV RRs with Priority higher than the RR with the lowest
+        Priority for a domain.
+
+   Currently there's a practical limit of 512 bytes for DNS replies.
+   Until all resolvers can handle larger responses, domain
+   administrators are strongly advised to keep their SRV replies below
+   512 bytes.
+
+   All round numbers, wrote Dr. Johnson, are false, and these numbers
+   are very round: A reply packet has a 30-byte overhead plus the name
+   of the service ("_ldap._tcp.example.com" for instance); each SRV RR
+   adds 20 bytes plus the name of the target host; each NS RR in the NS
+   section is 15 bytes plus the name of the name server host; and
+   finally each A RR in the additional data section is 20 bytes or so,
+   and there are A's for each SRV and NS RR mentioned in the answer.
+   This size estimate is extremely crude, but shouldn't underestimate
+   the actual answer size by much.  If an answer may be close to the
+   limit, using a DNS query tool (e.g. "dig") to look at the actual
+   answer is a good idea.
+
+The "Weight" field
+
+   Weight, the server selection field, is not quite satisfactory, but
+   the actual load on typical servers changes much too quickly to be
+   kept around in DNS caches.  It seems to the authors that offering
+   administrators a way to say "this machine is three times as fast as
+   that one" is the best that can practically be done.
+
+
+
+
+Gulbrandsen, et al.         Standards Track                     [Page 5]
+
+RFC 2782                       DNS SRV RR                  February 2000
+
+
+   The only way the authors can see of getting a "better" load figure is
+   asking a separate server when the client selects a server and
+   contacts it.  For short-lived services an extra step in the
+   connection establishment seems too expensive, and for long-lived
+   services, the load figure may well be thrown off a minute after the
+   connection is established when someone else starts or finishes a
+   heavy job.
+
+   Note: There are currently various experiments at providing relative
+   network proximity estimation, available bandwidth estimation, and
+   similar services.  Use of the SRV record with such facilities, and in
+   particular the interpretation of the Weight field when these
+   facilities are used, is for further study.  Weight is only intended
+   for static, not dynamic, server selection.  Using SRV weight for
+   dynamic server selection would require assigning unreasonably short
+   TTLs to the SRV RRs, which would limit the usefulness of the DNS
+   caching mechanism, thus increasing overall network load and
+   decreasing overall reliability.  Server selection via SRV is only
+   intended to express static information such as "this server has a
+   faster CPU than that one" or "this server has a much better network
+   connection than that one".
+
+The Port number
+
+   Currently, the translation from service name to port number happens
+   at the client, often using a file such as /etc/services.
+
+   Moving this information to the DNS makes it less necessary to update
+   these files on every single computer of the net every time a new
+   service is added, and makes it possible to move standard services out
+   of the "root-only" port range on unix.
+
+Usage rules
+
+   A SRV-cognizant client SHOULD use this procedure to locate a list of
+   servers and connect to the preferred one:
+
+        Do a lookup for QNAME=_service._protocol.target, QCLASS=IN,
+        QTYPE=SRV.
+
+        If the reply is NOERROR, ANCOUNT>0 and there is at least one
+        SRV RR which specifies the requested Service and Protocol in
+        the reply:
+
+            If there is precisely one SRV RR, and its Target is "."
+            (the root domain), abort.
+
+
+
+
+
+Gulbrandsen, et al.         Standards Track                     [Page 6]
+
+RFC 2782                       DNS SRV RR                  February 2000
+
+
+            Else, for all such RR's, build a list of (Priority, Weight,
+            Target) tuples
+
+            Sort the list by priority (lowest number first)
+
+            Create a new empty list
+
+            For each distinct priority level
+                While there are still elements left at this priority
+                level
+
+                    Select an element as specified above, in the
+                    description of Weight in "The format of the SRV
+                    RR" Section, and move it to the tail of the new
+                    list
+
+            For each element in the new list
+
+                query the DNS for address records for the Target or
+                use any such records found in the Additional Data
+                section of the earlier SRV response.
+
+                for each address record found, try to connect to the
+               (protocol, address, service).
+
+        else
+
+            Do a lookup for QNAME=target, QCLASS=IN, QTYPE=A
+
+            for each address record found, try to connect to the
+           (protocol, address, service)
+
+Notes:
+
+   - Port numbers SHOULD NOT be used in place of the symbolic service
+     or protocol names (for the same reason why variant names cannot
+     be allowed: Applications would have to do two or more lookups).
+
+   - If a truncated response comes back from an SRV query, the rules
+     described in [RFC 2181] shall apply.
+
+   - A client MUST parse all of the RR's in the reply.
+
+   - If the Additional Data section doesn't contain address records
+     for all the SRV RR's and the client may want to connect to the
+     target host(s) involved, the client MUST look up the address
+     record(s).  (This happens quite often when the address record
+     has shorter TTL than the SRV or NS RR's.)
+
+
+
+Gulbrandsen, et al.         Standards Track                     [Page 7]
+
+RFC 2782                       DNS SRV RR                  February 2000
+
+
+   - Future protocols could be designed to use SRV RR lookups as the
+     means by which clients locate their servers.
+
+Fictional example
+
+   This example uses fictional service "foobar" as an aid in
+   understanding SRV records. If ever service "foobar" is implemented,
+   it is not intended that it will necessarily use SRV records.  This is
+   (part of) the zone file for example.com, a still-unused domain:
+
+      $ORIGIN example.com.
+      @               SOA server.example.com. root.example.com. (
+                          1995032001 3600 3600 604800 86400 )
+                      NS  server.example.com.
+                      NS  ns1.ip-provider.net.
+                      NS  ns2.ip-provider.net.
+      ; foobar - use old-slow-box or new-fast-box if either is
+      ; available, make three quarters of the logins go to
+      ; new-fast-box.
+      _foobar._tcp    SRV 0 1 9 old-slow-box.example.com.
+                       SRV 0 3 9 new-fast-box.example.com.
+      ; if neither old-slow-box or new-fast-box is up, switch to
+      ; using the sysdmin's box and the server
+                       SRV 1 0 9 sysadmins-box.example.com.
+                       SRV 1 0 9 server.example.com.
+      server           A   172.30.79.10
+      old-slow-box     A   172.30.79.11
+      sysadmins-box    A   172.30.79.12
+      new-fast-box     A   172.30.79.13
+      ; NO other services are supported
+      *._tcp          SRV  0 0 0 .
+      *._udp          SRV  0 0 0 .
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gulbrandsen, et al.         Standards Track                     [Page 8]
+
+RFC 2782                       DNS SRV RR                  February 2000
+
+
+   In this example, a client of the "foobar" service in the
+   "example.com." domain needs an SRV lookup of
+   "_foobar._tcp.example.com." and possibly A lookups of "new-fast-
+   box.example.com." and/or the other hosts named.  The size of the SRV
+   reply is approximately 365 bytes:
+
+      30 bytes general overhead
+      20 bytes for the query string, "_foobar._tcp.example.com."
+      130 bytes for 4 SRV RR's, 20 bytes each plus the lengths of "new-
+        fast-box", "old-slow-box", "server" and "sysadmins-box" -
+        "example.com" in the query section is quoted here and doesn't
+        need to be counted again.
+      75 bytes for 3 NS RRs, 15 bytes each plus the lengths of "server",
+        "ns1.ip-provider.net." and "ns2" - again, "ip-provider.net." is
+        quoted and only needs to be counted once.
+      120 bytes for the 6 address records (assuming IPv4 only) mentioned
+        by the SRV and NS RR's.
+
+IANA Considerations
+
+   The IANA has assigned RR type value 33 to the SRV RR.  No other IANA
+   services are required by this document.
+
+Changes from RFC 2052
+
+   This document obsoletes RFC 2052.   The major change from that
+   previous, experimental, version of this specification is that now the
+   protocol and service labels are prepended with an underscore, to
+   lower the probability of an accidental clash with a similar name used
+   for unrelated purposes.  Aside from that, changes are only intended
+   to increase the clarity and completeness of the document. This
+   document especially clarifies the use of the Weight field of the SRV
+   records.
+
+Security Considerations
+
+   The authors believe this RR to not cause any new security problems.
+   Some problems become more visible, though.
+
+   - The ability to specify ports on a fine-grained basis obviously
+     changes how a router can filter packets.  It becomes impossible
+     to block internal clients from accessing specific external
+     services, slightly harder to block internal users from running
+     unauthorized services, and more important for the router
+     operations and DNS operations personnel to cooperate.
+
+   - There is no way a site can keep its hosts from being referenced
+     as servers.  This could lead to denial of service.
+
+
+
+Gulbrandsen, et al.         Standards Track                     [Page 9]
+
+RFC 2782                       DNS SRV RR                  February 2000
+
+
+   - With SRV, DNS spoofers can supply false port numbers, as well as
+     host names and addresses.   Because this vulnerability exists
+     already, with names and addresses, this is not a new
+     vulnerability, merely a slightly extended one, with little
+     practical effect.
+
+References
+
+   STD 2:    Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC
+             1700, October 1994.
+
+   RFC 1034: Mockapetris, P., "Domain names - concepts and facilities",
+             STD 13, RFC 1034, November 1987.
+
+   RFC 1035: Mockapetris, P., "Domain names - Implementation and
+             Specification", STD 13, RFC 1035, November 1987.
+
+   RFC 974:  Partridge, C., "Mail routing and the domain system", STD
+             14, RFC 974, January 1986.
+
+   BCP 14:   Bradner, S., "Key words for use in RFCs to Indicate
+             Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   RFC 2181: Elz, R. and R. Bush, "Clarifications to the DNS
+             Specification", RFC 2181, July 1997.
+
+   RFC 2219: Hamilton, M. and R. Wright, "Use of DNS Aliases for Network
+             Services", BCP 17, RFC 2219, October 1997.
+
+   BCP 14:   Bradner, S., "Key words for use in RFCs to Indicate
+             Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   ARM:      Armijo, M., Esibov, L. and P. Leach, "Discovering LDAP
+             Services with DNS", Work in Progress.
+
+   KDC-DNS:  Hornstein, K. and J. Altman, "Distributing Kerberos KDC and
+             Realm Information with DNS", Work in Progress.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gulbrandsen, et al.         Standards Track                    [Page 10]
+
+RFC 2782                       DNS SRV RR                  February 2000
+
+
+Acknowledgements
+
+   The algorithm used to select from the weighted SRV RRs of equal
+   priority is adapted from one supplied by Dan Bernstein.
+
+Authors' Addresses
+
+   Arnt Gulbrandsen
+   Troll Tech
+   Waldemar Thranes gate 98B
+   N-0175 Oslo, Norway
+
+   Fax:   +47 22806380
+   Phone: +47 22806390
+   EMail: arnt@troll.no
+
+
+   Paul Vixie
+   Internet Software Consortium
+   950 Charter Street
+   Redwood City, CA 94063
+
+   Phone: +1 650 779 7001
+
+
+   Levon Esibov
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA 98052
+
+   EMail: levone@microsoft.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gulbrandsen, et al.         Standards Track                    [Page 11]
+
+RFC 2782                       DNS SRV RR                  February 2000
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2000).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gulbrandsen, et al.         Standards Track                    [Page 12]
+
diff --git a/doc/rfc/rfc2825.txt b/doc/rfc/rfc2825.txt
new file mode 100644
index 0000000..fd8ef7c
--- /dev/null
+++ b/doc/rfc/rfc2825.txt
@@ -0,0 +1,395 @@
+

+

+

+

+

+

+Network Working Group                  Internet Architecture Board (IAB)

+Request for Comments: 2825                             L. Daigle, Editor

+Category: Informational                                         May 2000

+

+

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

+                        Other Internet protocols

+

+Status of this Memo

+

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

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

+   memo is unlimited.

+

+Copyright Notice

+

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

+

+Abstract

+

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

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

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

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

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

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

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

+   national boundaries. These services must interoperate worldwide, or

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

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

+   communications among people, but opportunities of the areas involved

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

+   other activities at an international scale, thereby retarding

+   economic development.

+

+   There are several proposals for internationalizing domain names,

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

+   ensure this interoperability and global reach while addressing

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

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

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

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

+   the continued global network interoperation that is the deserved

+   expectation of all Internet users.

+

+

+

+

+

+

+

+IAB                          Informational                      [Page 1]

+

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

+

+

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

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

+   of architectural issues that the internationalization of domain names

+   faces.

+

+1. A Definition of Success

+

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

+   component of the IETF's continuing comprehensive effort to

+   internationalize language representation facilities in the protocols

+   that support the global functioning of the Internet.

+

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

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

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

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

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

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

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

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

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

+   limitations on allowable characters, and in other cases

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

+   individual organizations) have in practice not implemented all the

+   requisite options of the standards.

+

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

+

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

+   other effort to enable multiple character set representations in

+   textual elements that were traditionally restricted to English

+   language characters.

+

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

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

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

+   proposals have been suggested to address these issues.

+

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

+   evolving draft requirements document; further discussion is deferred

+   to the WG and its documents.

+

+3. Integrating with Current Realities

+

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

+   intricately intertwined with other operational components of the

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

+   analysis of the impact on existing critical operational standards

+

+

+

+IAB                          Informational                      [Page 2]

+

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

+

+

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

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

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

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

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

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

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

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

+

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

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

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

+

+3.1 Domain Names and E-mail

+

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

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

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

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

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

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

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

+   characters allowed in the DNS specification. Certain characters are

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

+   specifications.  Some mailers, built to adhere to these

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

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

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

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

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

+

+3.2 Domain Names and Routing

+

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

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

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

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

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

+   possible to enter or retrieve network descriptions utilizing

+   internationalized domain names.

+

+3.3 Domain Names and Network Management

+

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

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

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

+   implementations of software libraries being used to build SNMP-

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

+

+

+

+IAB                          Informational                      [Page 3]

+

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

+

+

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

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

+

+3.4 Domain Names and Security

+

+   Critical components of Internet public key technologies (PKIX,

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

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

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

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

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

+   two.

+

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

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

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

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

+   service.

+

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

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

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

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

+   are now impossible or at least far more difficult.

+

+4. Conclusion

+

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

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

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

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

+   tools.  When designing a solution for internationalization of domain

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

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

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

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

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

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

+   Internet.

+

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

+   identifying and discussing solutions for such potential

+   interoperability issues.

+

+   Experience with deployment of other protocols has indicated that it

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

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

+   solutions from all quarters, including organizations hoping to

+

+

+

+IAB                          Informational                      [Page 4]

+

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

+

+

+   provide services that address visible-name representation and

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

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

+   way to ensure the continued global interoperation that is the

+   deserved expectation of all Internet users.

+

+5. Security Considerations

+

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

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

+   mechanisms are reliant on the current specification of domain names

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

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

+   response to current pressures to address national or regional

+   characterset representation) might result in name strings that are

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

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

+

+6. Acknowledgements

+

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

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

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

+

+7. References

+

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

+             821, August 1982.

+

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

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

+

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

+             STD 13, RFC 1034, November 1987.

+

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

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

+

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

+             Internet Protocol", RFC 2401, November 1998.

+

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

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

+

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

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

+             Bodies", RFC 2045, November 1996.

+

+

+

+

+IAB                          Informational                      [Page 5]

+

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

+

+

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

+             RFC 2246, January 1999.

+

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

+             X.509 Public Key Infrastructure Certificate and CRL

+             Profile", RFC 2459, January 1999.

+

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

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

+             April 1999.

+

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

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

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

+             June 1999.

+

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

+             2826, May 2000.

+

+8. Author's Address

+

+   Internet Architecture Board

+

+   EMail:  iab@iab.org

+

+

+   Membership at time this document was completed:

+

+      Harald Alvestrand

+      Ran Atkinson

+      Rob Austein

+      Brian Carpenter

+      Steve Bellovin

+      Jon Crowcroft

+      Leslie Daigle

+      Steve Deering

+      Tony Hain

+      Geoff Huston

+      John Klensin

+      Henning Schulzrinne

+

+

+

+

+

+

+

+

+

+

+

+IAB                          Informational                      [Page 6]

+

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

+

+

+9. Full Copyright Statement

+

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

+

+   This document and translations of it may be copied and furnished to

+   others, and derivative works that comment on or otherwise explain it

+   or assist in its implementation may be prepared, copied, published

+   and distributed, in whole or in part, without restriction of any

+   kind, provided that the above copyright notice and this paragraph are

+   included on all such copies and derivative works.  However, this

+   document itself may not be modified in any way, such as by removing

+   the copyright notice or references to the Internet Society or other

+   Internet organizations, except as needed for the purpose of

+   developing Internet standards in which case the procedures for

+   copyrights defined in the Internet Standards process must be

+   followed, or as required to translate it into languages other than

+   English.

+

+   The limited permissions granted above are perpetual and will not be

+   revoked by the Internet Society or its successors or assigns.

+

+   This document and the information contained herein is provided on an

+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING

+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING

+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION

+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF

+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

+

+Acknowledgement

+

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

+   Internet Society.

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+IAB                          Informational                      [Page 7]

+

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

+

+

+

+

+

+Network Working Group                        Internet Architecture Board

+Request for Comments: 2826                                      May 2000

+Category: Informational

+

+

+              IAB Technical Comment on the Unique DNS Root

+

+Status of this Memo

+

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

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

+   memo is unlimited.

+

+Copyright Notice

+

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

+

+Summary

+

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

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

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

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

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

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

+   of coordinated root servers administered by a unique naming

+   authority.

+

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

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

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

+   the will of the web page designers.

+

+   This does not preclude private networks from operating their own

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

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

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

+   coordinated root servers of the global DNS naming hierarchy.

+

+1.  Detailed Explanation

+

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

+   in order to operate properly.

+

+1.1.  Maintenance of a Common Symbol Set

+

+   Effective communications between two parties requires two essential

+   preconditions:

+

+

+

+IAB                          Informational                      [Page 1]

+

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

+

+

+   -  The existence of a common symbol set, and

+

+   -  The existence of a common semantic interpretation of these

+      symbols.

+

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

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

+   the communication is lost.

+

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

+   common symbol set with a common semantic interpretation must be

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

+   semantic interpretation.  This condition of uniqueness allows any

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

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

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

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

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

+

+   Within public digital communications networks such as the Internet

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

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

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

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

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

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

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

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

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

+   meaning of the original use.

+

+   The DNS fulfills an essential role within the Internet protocol

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

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

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

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

+   records uniquely describing protocol addresses, network resources and

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

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

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

+   symbols, whose interpretation does not specifically require knowledge

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

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

+   name.

+

+   Since the DNS is hierarchically structured into domains, the

+   uniqueness requirement for DNS names in their entirety implies that

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

+

+

+

+IAB                          Informational                      [Page 2]

+

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

+

+

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

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

+   requirement for uniqueness within a domain further implies that there

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

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

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

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

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

+   choice.

+

+1.2.  Coordination of Updates

+

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

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

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

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

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

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

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

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

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

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

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

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

+   to support a shared domain scenario.

+

+   Moreover, even supposing that some other means of resolving

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

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

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

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

+   that naming authority Z had been delegated authority to define

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

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

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

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

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

+   within a single domain.

+

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

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

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

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

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

+

+

+

+

+

+

+

+IAB                          Informational                      [Page 3]

+

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

+

+

+1.3.  Difficulty of Relocating the Root Zone

+

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

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

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

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

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

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

+   years out of date at many sites.

+

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

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

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

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

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

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

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

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

+   route around a buggy root server.

+

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

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

+

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

+   specify the public root zone is significantly more difficult than

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

+   stability of the system calls for extremely conservative and cautious

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

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

+   closely coordinated.

+

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

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

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

+   root zone still requires tight coupling and coordinated management

+   even in the presence of DNSSEC.

+

+2.  Conclusion

+

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

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

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

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

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

+   vague or ambiguous references.  To preserve the many important

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

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

+   expect the result of directory lookups and identification of the

+

+

+

+IAB                          Informational                      [Page 4]

+

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

+

+

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

+   are then resolved normally, rather than having directory systems

+   "replace" the DNS.

+

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

+

+3.  Security Considerations

+

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

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

+   recurring technically naive proposals.

+

+4.  IANA Considerations

+

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

+

+5.  References

+

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

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

+

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

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

+                         1987.

+

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

+                         Extensions", RFC 2535, March 1999.

+

+6.  Author's Address

+

+   Internet Architecture Board

+

+   EMail: iab@iab.org

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+IAB                          Informational                      [Page 5]

+

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

+

+

+7.  Full Copyright Statement

+

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

+

+   This document and translations of it may be copied and furnished to

+   others, and derivative works that comment on or otherwise explain it

+   or assist in its implementation may be prepared, copied, published

+   and distributed, in whole or in part, without restriction of any

+   kind, provided that the above copyright notice and this paragraph are

+   included on all such copies and derivative works.  However, this

+   document itself may not be modified in any way, such as by removing

+   the copyright notice or references to the Internet Society or other

+   Internet organizations, except as needed for the purpose of

+   developing Internet standards in which case the procedures for

+   copyrights defined in the Internet Standards process must be

+   followed, or as required to translate it into languages other than

+   English.

+

+   The limited permissions granted above are perpetual and will not be

+   revoked by the Internet Society or its successors or assigns.

+

+   This document and the information contained herein is provided on an

+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING

+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING

+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION

+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF

+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

+

+Acknowledgement

+

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

+   Internet Society.

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+

+IAB                          Informational                      [Page 6]

+

diff --git a/doc/rfc/rfc2845.txt b/doc/rfc/rfc2845.txt
new file mode 100644
index 0000000..aa9f385
--- /dev/null
+++ b/doc/rfc/rfc2845.txt
@@ -0,0 +1,843 @@
+
+
+
+
+
+
+Network Working Group                                             P. Vixie
+Request for Comments: 2845                                             ISC
+Category: Standards Track                                   O. Gudmundsson
+Updates: 1035                                                     NAI Labs
+                                                           D. Eastlake 3rd
+                                                                  Motorola
+                                                             B. Wellington
+                                                                   Nominum
+                                                                  May 2000
+
+
+          Secret Key Transaction Authentication for DNS (TSIG)
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2000).  All Rights Reserved.
+
+Abstract
+
+   This protocol allows for transaction level authentication using
+   shared secrets and one way hashing.  It can be used to authenticate
+   dynamic updates as coming from an approved client, or to authenticate
+   responses as coming from an approved recursive name server.
+
+   No provision has been made here for distributing the shared secrets;
+   it is expected that a network administrator will statically configure
+   name servers and clients using some out of band mechanism such as
+   sneaker-net until a secure automated mechanism for key distribution
+   is available.
+
+1 - Introduction
+
+   1.1. The Domain Name System (DNS) [RFC1034, RFC1035] is a replicated
+   hierarchical distributed database system that provides information
+   fundamental to Internet operations, such as name <=> address
+   translation and mail handling information.  DNS has recently been
+   extended [RFC2535] to provide for data origin authentication, and
+   public key distribution, all based on public key cryptography and
+   public key based digital signatures.  To be practical, this form of
+
+
+
+
+Vixie, et al.               Standards Track                     [Page 1]
+
+RFC 2845                        DNS TSIG                        May 2000
+
+
+   security generally requires extensive local caching of keys and
+   tracing of authentication through multiple keys and signatures to a
+   pre-trusted locally configured key.
+
+   1.2. One difficulty with the [RFC2535] scheme is that common DNS
+   implementations include simple "stub" resolvers which do not have
+   caches.  Such resolvers typically rely on a caching DNS server on
+   another host.  It is impractical for these stub resolvers to perform
+   general [RFC2535] authentication and they would naturally depend on
+   their caching DNS server to perform such services for them.  To do so
+   securely requires secure communication of queries and responses.
+   [RFC2535] provides public key transaction signatures to support this,
+   but such signatures are very expensive computationally to generate.
+   In general, these require the same complex public key logic that is
+   impractical for stubs.  This document specifies use of a message
+   authentication code (MAC), specifically HMAC-MD5 (a keyed hash
+   function), to provide an efficient means of point-to-point
+   authentication and integrity checking for transactions.
+
+   1.3. A second area where use of straight [RFC2535] public key based
+   mechanisms may be impractical is authenticating dynamic update
+   [RFC2136] requests.  [RFC2535] provides for request signatures but
+   with [RFC2535] they, like transaction signatures, require
+   computationally expensive public key cryptography and complex
+   authentication logic.  Secure Domain Name System Dynamic Update
+   ([RFC2137]) describes how different keys are used in dynamically
+   updated zones.  This document's secret key based MACs can be used to
+   authenticate DNS update requests as well as transaction responses,
+   providing a lightweight alternative to the protocol described by
+   [RFC2137].
+
+   1.4. A further use of this mechanism is to protect zone transfers.
+   In this case the data covered would be the whole zone transfer
+   including any glue records sent.  The protocol described by [RFC2535]
+   does not protect glue records and unsigned records unless SIG(0)
+   (transaction signature) is used.
+
+   1.5. The authentication mechanism proposed in this document uses
+   shared secret keys to establish a trust relationship between two
+   entities.  Such keys must be protected in a fashion similar to
+   private keys, lest a third party masquerade as one of the intended
+   parties (forge MACs).  There is an urgent need to provide simple and
+   efficient authentication between clients and local servers and this
+   proposal addresses that need.  This proposal is unsuitable for
+   general server to server authentication for servers which speak with
+   many other servers, since key management would become unwieldy with
+
+
+
+
+
+Vixie, et al.               Standards Track                     [Page 2]
+
+RFC 2845                        DNS TSIG                        May 2000
+
+
+   the number of shared keys going up quadratically.  But it is suitable
+   for many resolvers on hosts that only talk to a few recursive
+   servers.
+
+   1.6. A server acting as an indirect caching resolver -- a "forwarder"
+   in common usage -- might use transaction-based authentication when
+   communicating with its small number of preconfigured "upstream"
+   servers.  Other uses of DNS secret key authentication and possible
+   systems for automatic secret key distribution may be proposed in
+   separate future documents.
+
+   1.7. New Assigned Numbers
+
+      RRTYPE = TSIG (250)
+      ERROR = 0..15 (a DNS RCODE)
+      ERROR = 16 (BADSIG)
+      ERROR = 17 (BADKEY)
+      ERROR = 18 (BADTIME)
+
+   1.8. The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED",  and
+   "MAY" in this document are to be interpreted as described in [RFC
+   2119].
+
+2 - TSIG RR Format
+
+   2.1 TSIG RR Type
+
+   To provide secret key authentication, we use a new RR type whose
+   mnemonic is TSIG and whose type code is 250.  TSIG is a meta-RR and
+   MUST not be cached.  TSIG RRs are used for authentication between DNS
+   entities that have established a shared secret key.  TSIG RRs are
+   dynamically computed to cover a particular DNS transaction and are
+   not DNS RRs in the usual sense.
+
+   2.2 TSIG Calculation
+
+   As the TSIG RRs are related to one DNS request/response, there is no
+   value in storing or retransmitting them, thus the TSIG RR is
+   discarded once it has been used to authenticate a DNS message.  The
+   only message digest algorithm specified in this document is "HMAC-
+   MD5" (see [RFC1321], [RFC2104]).  The "HMAC-MD5" algorithm is
+   mandatory to implement for interoperability.  Other algorithms can be
+   specified at a later date.  Names and definitions of new algorithms
+   MUST be registered with IANA.  All multi-octet integers in the TSIG
+   record are sent in network byte order (see [RFC1035 2.3.2]).
+
+
+
+
+
+
+Vixie, et al.               Standards Track                     [Page 3]
+
+RFC 2845                        DNS TSIG                        May 2000
+
+
+   2.3. Record Format
+
+    NAME The name of the key used in domain name syntax.  The name
+         should reflect the names of the hosts and uniquely identify
+         the key among a set of keys these two hosts may share at any
+         given time.  If hosts A.site.example and B.example.net share a
+         key, possibilities for the key name include
+         <id>.A.site.example, <id>.B.example.net, and
+         <id>.A.site.example.B.example.net.  It should be possible for
+         more than one key to be in simultaneous use among a set of
+         interacting hosts.  The name only needs to be meaningful to
+         the communicating hosts but a meaningful mnemonic name as
+         above is strongly recommended.
+
+         The name may be used as a local index to the key involved and
+         it is recommended that it be globally unique.  Where a key is
+         just shared between two hosts, its name actually only need
+         only be meaningful to them but it is recommended that the key
+         name be mnemonic and incorporate the resolver and server host
+         names in that order.
+
+    TYPE TSIG (250: Transaction SIGnature)
+
+    CLASS ANY
+
+    TTL  0
+
+    RdLen (variable)
+
+    RDATA
+
+      Field Name       Data Type      Notes
+      --------------------------------------------------------------
+      Algorithm Name   domain-name    Name of the algorithm
+                                      in domain name syntax.
+      Time Signed      u_int48_t      seconds since 1-Jan-70 UTC.
+      Fudge            u_int16_t      seconds of error permitted
+                                      in Time Signed.
+      MAC Size         u_int16_t      number of octets in MAC.
+      MAC              octet stream   defined by Algorithm Name.
+      Original ID      u_int16_t      original message ID
+      Error            u_int16_t      expanded RCODE covering
+                                      TSIG processing.
+      Other Len        u_int16_t      length, in octets, of
+                                      Other Data.
+      Other Data       octet stream   empty unless Error == BADTIME
+
+
+
+
+
+Vixie, et al.               Standards Track                     [Page 4]
+
+RFC 2845                        DNS TSIG                        May 2000
+
+
+   2.4. Example
+
+      NAME   HOST.EXAMPLE.
+
+      TYPE   TSIG
+
+      CLASS  ANY
+
+      TTL    0
+
+      RdLen  as appropriate
+
+      RDATA
+
+         Field Name       Contents
+         -------------------------------------
+         Algorithm Name   SAMPLE-ALG.EXAMPLE.
+         Time Signed      853804800
+         Fudge            300
+         MAC Size         as appropriate
+         MAC              as appropriate
+         Original ID      as appropriate
+         Error            0 (NOERROR)
+         Other Len        0
+         Other Data       empty
+
+3 - Protocol Operation
+
+   3.1. Effects of adding TSIG to outgoing message
+
+   Once the outgoing message has been constructed, the keyed message
+   digest operation can be performed.  The resulting message digest will
+   then be stored in a TSIG which is appended to the additional data
+   section (the ARCOUNT is incremented to reflect this).  If the TSIG
+   record cannot be added without causing the message to be truncated,
+   the server MUST alter the response so that a TSIG can be included.
+   This response consists of only the question and a TSIG record, and
+   has the TC bit set and RCODE 0 (NOERROR).  The client SHOULD at this
+   point retry the request using TCP (per [RFC1035 4.2.2]).
+
+   3.2. TSIG processing on incoming messages
+
+   If an incoming message contains a TSIG record, it MUST be the last
+   record in the additional section.  Multiple TSIG records are not
+   allowed.  If a TSIG record is present in any other position, the
+   packet is dropped and a response with RCODE 1 (FORMERR) MUST be
+   returned.  Upon receipt of a message with a correctly placed TSIG RR,
+   the TSIG RR is copied to a safe location, removed from the DNS
+
+
+
+Vixie, et al.               Standards Track                     [Page 5]
+
+RFC 2845                        DNS TSIG                        May 2000
+
+
+   Message, and decremented out of the DNS message header's ARCOUNT.  At
+   this point the keyed message digest operation is performed.  If the
+   algorithm name or key name is unknown to the recipient, or if the
+   message digests do not match, the whole DNS message MUST be
+   discarded.  If the message is a query, a response with RCODE 9
+   (NOTAUTH) MUST be sent back to the originator with TSIG ERROR 17
+   (BADKEY) or TSIG ERROR 16 (BADSIG).  If no key is available to sign
+   this message it MUST be sent unsigned (MAC size == 0 and empty MAC).
+   A message to the system operations log SHOULD be generated, to warn
+   the operations staff of a possible security incident in progress.
+   Care should be taken to ensure that logging of this type of event
+   does not open the system to a denial of service attack.
+
+   3.3. Time values used in TSIG calculations
+
+   The data digested includes the two timer values in the TSIG header in
+   order to defend against replay attacks.  If this were not done, an
+   attacker could replay old messages but update the "Time Signed" and
+   "Fudge" fields to make the message look new.  This data is named
+   "TSIG Timers", and for the purpose of digest calculation they are
+   invoked in their "on the wire" format, in the following order: first
+   Time Signed, then Fudge.  For example:
+
+Field Name    Value       Wire Format         Meaning
+----------------------------------------------------------------------
+Time Signed   853804800   00 00 32 e4 07 00   Tue Jan 21 00:00:00 1997
+Fudge         300         01 2C               5 minutes
+
+   3.4. TSIG Variables and Coverage
+
+   When generating or verifying the contents of a TSIG record, the
+   following data are digested, in network byte order or wire format, as
+   appropriate:
+
+   3.4.1. DNS Message
+
+   A whole and complete DNS message in wire format, before the TSIG RR
+   has been added to the additional data section and before the DNS
+   Message Header's ARCOUNT field has been incremented to contain the
+   TSIG RR.  If the message ID differs from the original message ID, the
+   original message ID is substituted for the message ID.  This could
+   happen when forwarding a dynamic update request, for example.
+
+
+
+
+
+
+
+
+
+Vixie, et al.               Standards Track                     [Page 6]
+
+RFC 2845                        DNS TSIG                        May 2000
+
+
+   3.4.2. TSIG Variables
+
+Source       Field Name       Notes
+-----------------------------------------------------------------------
+TSIG RR      NAME             Key name, in canonical wire format
+TSIG RR      CLASS            (Always ANY in the current specification)
+TSIG RR      TTL              (Always 0 in the current specification)
+TSIG RDATA   Algorithm Name   in canonical wire format
+TSIG RDATA   Time Signed      in network byte order
+TSIG RDATA   Fudge            in network byte order
+TSIG RDATA   Error            in network byte order
+TSIG RDATA   Other Len        in network byte order
+TSIG RDATA   Other Data       exactly as transmitted
+
+   The RR RDLEN and RDATA MAC Length are not included in the hash since
+   they are not guaranteed to be knowable before the MAC is generated.
+
+   The Original ID field is not included in this section, as it has
+   already been substituted for the message ID in the DNS header and
+   hashed.
+
+   For each label type, there must be a defined "Canonical wire format"
+   that specifies how to express a label in an unambiguous way.  For
+   label type 00, this is defined in [RFC2535], for label type 01, this
+   is defined in [RFC2673].  The use of label types other than 00 and 01
+   is not defined for this specification.
+
+   3.4.3. Request MAC
+
+   When generating the MAC to be included in a response, the request MAC
+   must be included in the digest.  The request's MAC is digested in
+   wire format, including the following fields:
+
+   Field        Type           Description
+   ---------------------------------------------------
+   MAC Length   u_int16_t      in network byte order
+   MAC Data     octet stream   exactly as transmitted
+
+   3.5. Padding
+
+   Digested components are fed into the hashing function as a continuous
+   octet stream with no interfield padding.
+
+
+
+
+
+
+
+
+
+Vixie, et al.               Standards Track                     [Page 7]
+
+RFC 2845                        DNS TSIG                        May 2000
+
+
+4 - Protocol Details
+
+   4.1. TSIG generation on requests
+
+   Client performs the message digest operation and appends a TSIG
+   record to the additional data section and transmits the request to
+   the server.  The client MUST store the message digest from the
+   request while awaiting an answer.  The digest components for a
+   request are:
+
+      DNS Message (request)
+      TSIG Variables (request)
+
+   Note that some older name servers will not accept requests with a
+   nonempty additional data section.  Clients SHOULD only attempt signed
+   transactions with servers who are known to support TSIG and share
+   some secret key with the client -- so, this is not a problem in
+   practice.
+
+   4.2. TSIG on Answers
+
+   When a server has generated a response to a signed request, it signs
+   the response using the same algorithm and key.  The server MUST not
+   generate a signed response to an unsigned request.  The digest
+   components are:
+
+      Request MAC
+      DNS Message (response)
+      TSIG Variables (response)
+
+   4.3. TSIG on TSIG Error returns
+
+   When a server detects an error relating to the key or MAC, the server
+   SHOULD send back an unsigned error message (MAC size == 0 and empty
+   MAC).  If an error is detected relating to the TSIG validity period,
+   the server SHOULD send back a signed error message.  The digest
+   components are:
+
+      Request MAC (if the request MAC validated)
+      DNS Message (response)
+      TSIG Variables (response)
+
+   The reason that the request is not included in this digest in some
+   cases is to make it possible for the client to verify the error.  If
+   the error is not a TSIG error the response MUST be generated as
+   specified in [4.2].
+
+
+
+
+
+Vixie, et al.               Standards Track                     [Page 8]
+
+RFC 2845                        DNS TSIG                        May 2000
+
+
+   4.4. TSIG on TCP connection
+
+   A DNS TCP session can include multiple DNS envelopes.  This is, for
+   example, commonly used by zone transfer.  Using TSIG on such a
+   connection can protect the connection from hijacking and provide data
+   integrity.  The TSIG MUST be included on the first and last DNS
+   envelopes.  It can be optionally placed on any intermediary
+   envelopes.  It is expensive to include it on every envelopes, but it
+   MUST be placed on at least every 100'th envelope.  The first envelope
+   is processed as a standard answer, and subsequent messages have the
+   following digest components:
+
+      Prior Digest (running)
+      DNS Messages (any unsigned messages since the last TSIG)
+      TSIG Timers (current message)
+
+   This allows the client to rapidly detect when the session has been
+   altered; at which point it can close the connection and retry.  If a
+   client TSIG verification fails, the client MUST close the connection.
+   If the client does not receive TSIG records frequently enough (as
+   specified above) it SHOULD assume the connection has been hijacked
+   and it SHOULD close the connection.  The client SHOULD treat this the
+   same way as they would any other interrupted transfer (although the
+   exact behavior is not specified).
+
+   4.5. Server TSIG checks
+
+   Upon receipt of a message, server will check if there is a TSIG RR.
+   If one exists, the server is REQUIRED to return a TSIG RR in the
+   response.  The server MUST perform the following checks in the
+   following order, check KEY, check TIME values, check MAC.
+
+   4.5.1. KEY check and error handling
+
+   If a non-forwarding server does not recognize the key used by the
+   client, the server MUST generate an error response with RCODE 9
+   (NOTAUTH) and TSIG ERROR 17 (BADKEY).  This response MUST be unsigned
+   as specified in [4.3].  The server SHOULD log the error.
+
+   4.5.2. TIME check and error handling
+
+   If the server time is outside the time interval specified by the
+   request (which is: Time Signed, plus/minus Fudge), the server MUST
+   generate an error response with RCODE 9 (NOTAUTH) and TSIG ERROR 18
+   (BADTIME).  The server SHOULD also cache the most recent time signed
+   value in a message generated by a key, and SHOULD return BADTIME if a
+   message received later has an earlier time signed value.  A response
+   indicating a BADTIME error MUST be signed by the same key as the
+
+
+
+Vixie, et al.               Standards Track                     [Page 9]
+
+RFC 2845                        DNS TSIG                        May 2000
+
+
+   request.  It MUST include the client's current time in the time
+   signed field, the server's current time (a u_int48_t) in the other
+   data field, and 6 in the other data length field.  This is done so
+   that the client can verify a message with a BADTIME error without the
+   verification failing due to another BADTIME error.  The data signed
+   is specified in [4.3].  The server SHOULD log the error.
+
+   4.5.3. MAC check and error handling
+
+   If a TSIG fails to verify, the server MUST generate an error response
+   as specified in [4.3] with RCODE 9 (NOTAUTH) and TSIG ERROR 16
+   (BADSIG).  This response MUST be unsigned as specified in [4.3].  The
+   server SHOULD log the error.
+
+   4.6. Client processing of answer
+
+   When a client receives a response from a server and expects to see a
+   TSIG, it first checks if the TSIG RR is present in the response.
+   Otherwise, the response is treated as having a format error and
+   discarded.  The client then extracts the TSIG, adjusts the ARCOUNT,
+   and calculates the keyed digest in the same way as the server.  If
+   the TSIG does not validate, that response MUST be discarded, unless
+   the RCODE is 9 (NOTAUTH), in which case the client SHOULD attempt to
+   verify the response as if it were a TSIG Error response, as specified
+   in [4.3].  A message containing an unsigned TSIG record or a TSIG
+   record which fails verification SHOULD not be considered an
+   acceptable response; the client SHOULD log an error and continue to
+   wait for a signed response until the request times out.
+
+   4.6.1. Key error handling
+
+   If an RCODE on a response is 9 (NOTAUTH), and the response TSIG
+   validates, and the TSIG key is different from the key used on the
+   request, then this is a KEY error.  The client MAY retry the request
+   using the key specified by the server.  This should never occur, as a
+   server MUST NOT sign a response with a different key than signed the
+   request.
+
+   4.6.2. Time error handling
+
+   If the response RCODE is 9 (NOTAUTH) and the TSIG ERROR is 18
+   (BADTIME), or the current time does not fall in the range specified
+   in the TSIG record, then this is a TIME error.  This is an indication
+   that the client and server clocks are not synchronized.  In this case
+   the client SHOULD log the event.  DNS resolvers MUST NOT adjust any
+   clocks in the client based on BADTIME errors, but the server's time
+   in the other data field SHOULD be logged.
+
+
+
+
+Vixie, et al.               Standards Track                    [Page 10]
+
+RFC 2845                        DNS TSIG                        May 2000
+
+
+   4.6.3. MAC error handling
+
+   If the response RCODE is 9 (NOTAUTH) and TSIG ERROR is 16 (BADSIG),
+   this is a MAC error, and client MAY retry the request with a new
+   request ID but it would be better to try a different shared key if
+   one is available.  Client SHOULD keep track of how many MAC errors
+   are associated with each key.  Clients SHOULD log this event.
+
+   4.7. Special considerations for forwarding servers
+
+   A server acting as a forwarding server of a DNS message SHOULD check
+   for the existence of a TSIG record.  If the name on the TSIG is not
+   of a secret that the server shares with the originator the server
+   MUST forward the message unchanged including the TSIG.  If the name
+   of the TSIG is of a key this server shares with the originator, it
+   MUST process the TSIG.  If the TSIG passes all checks, the forwarding
+   server MUST, if possible, include a TSIG of his own, to the
+   destination or the next forwarder.  If no transaction security is
+   available to the destination and the response has the AD flag (see
+   [RFC2535]), the forwarder MUST unset the AD flag before adding the
+   TSIG to the answer.
+
+5 - Shared Secrets
+
+   5.1. Secret keys are very sensitive information and all available
+   steps should be taken to protect them on every host on which they are
+   stored.  Generally such hosts need to be physically protected.  If
+   they are multi-user machines, great care should be taken that
+   unprivileged users have no access to keying material.  Resolvers
+   often run unprivileged, which means all users of a host would be able
+   to see whatever configuration data is used by the resolver.
+
+   5.2. A name server usually runs privileged, which means its
+   configuration data need not be visible to all users of the host.  For
+   this reason, a host that implements transaction-based authentication
+   should probably be configured with a "stub resolver" and a local
+   caching and forwarding name server.  This presents a special problem
+   for [RFC2136] which otherwise depends on clients to communicate only
+   with a zone's authoritative name servers.
+
+   5.3. Use of strong random shared secrets is essential to the security
+   of TSIG.  See [RFC1750] for a discussion of this issue.  The secret
+   should be at least as long as the keyed message digest, i.e. 16 bytes
+   for HMAC-MD5 or 20 bytes for HMAC-SHA1.
+
+
+
+
+
+
+
+Vixie, et al.               Standards Track                    [Page 11]
+
+RFC 2845                        DNS TSIG                        May 2000
+
+
+6 - Security Considerations
+
+   6.1. The approach specified here is computationally much less
+   expensive than the signatures specified in [RFC2535].  As long as the
+   shared secret key is not compromised, strong authentication is
+   provided for the last hop from a local name server to the user
+   resolver.
+
+   6.2. Secret keys should be changed periodically.  If the client host
+   has been compromised, the server should suspend the use of all
+   secrets known to that client.  If possible, secrets should be stored
+   in encrypted form.  Secrets should never be transmitted in the clear
+   over any network.  This document does not address the issue on how to
+   distribute secrets. Secrets should never be shared by more than two
+   entities.
+
+   6.3. This mechanism does not authenticate source data, only its
+   transmission between two parties who share some secret.  The original
+   source data can come from a compromised zone master or can be
+   corrupted during transit from an authentic zone master to some
+   "caching forwarder."  However, if the server is faithfully performing
+   the full [RFC2535] security checks, then only security checked data
+   will be available to the client.
+
+   6.4. A fudge value that is too large may leave the server open to
+   replay attacks.  A fudge value that is too small may cause failures
+   if machines are not time synchronized or there are unexpected network
+   delays.  The recommended value in most situation is 300 seconds.
+
+7 - IANA Considerations
+
+   IANA is expected to create and maintain a registry of algorithm names
+   to be used as "Algorithm Names" as defined in Section 2.3.  The
+   initial value should be "HMAC-MD5.SIG-ALG.REG.INT".  Algorithm names
+   are text strings encoded using the syntax of a domain name.  There is
+   no structure required other than names for different algorithms must
+   be unique when compared as DNS names, i.e., comparison is case
+   insensitive.  Note that the initial value mentioned above is not a
+   domain name, and therefore need not be a registered name within the
+   DNS.  New algorithms are assigned using the IETF Consensus policy
+   defined in RFC 2434. The algorithm name HMAC-MD5.SIG-ALG.REG.INT
+   looks like a FQDN for historical reasons; future algorithm names are
+   expected to be simple (i.e., single-component) names.
+
+
+
+
+
+
+
+
+Vixie, et al.               Standards Track                    [Page 12]
+
+RFC 2845                        DNS TSIG                        May 2000
+
+
+   IANA is expected to create and maintain a registry of "TSIG Error
+   values" to be used for "Error" values as defined in section 2.3.
+   Initial values should be those defined in section 1.7.  New TSIG
+   error codes for the TSIG error field are assigned using the IETF
+   Consensus policy defined in RFC 2434.
+
+8 - References
+
+   [RFC1034]  Mockapetris, P., "Domain Names - Concepts and Facilities",
+              STD 13, RFC 1034, November 1987.
+
+   [RFC1035]  Mockapetris, P., "Domain Names - Implementation and
+              Specification", STD 13, RFC 1034, November 1987.
+
+   [RFC1321]  Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
+              April 1992.
+
+   [RFC1750]  Eastlake, D., Crocker, S. and J. Schiller, "Randomness
+              Recommendations for Security", RFC 1750, December 1995.
+
+   [RFC2104]  Krawczyk, H., Bellare, M. and R. Canetti, "HMAC-MD5:
+              Keyed-MD5 for Message Authentication", RFC 2104, February
+              1997.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2136]  Vixie, P., Thomson, S., Rekhter, Y. and J. Bound "Dynamic
+              Updates in the Domain Name System", RFC 2136, April 1997.
+
+   [RFC2137]  Eastlake 3rd, D., "Secure Domain Name System Dynamic
+              Update", RFC 2137, April 1997.
+
+   [RFC2535]  Eastlake, D., "Domain Name System Security Extensions",
+              RFC 2535, March 1999.
+
+   [RFC2673]  Crawford, M., "Binary Labels in the Domain Name System",
+              RFC 2673, August 1999.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Vixie, et al.               Standards Track                    [Page 13]
+
+RFC 2845                        DNS TSIG                        May 2000
+
+
+9 - Authors' Addresses
+
+   Paul Vixie
+   Internet Software Consortium
+   950 Charter Street
+   Redwood City, CA 94063
+
+   Phone: +1 650 779 7001
+   EMail: vixie@isc.org
+
+
+   Olafur Gudmundsson
+   NAI Labs
+   3060 Washington Road, Route 97
+   Glenwood, MD 21738
+
+   Phone: +1 443 259 2389
+   EMail: ogud@tislabs.com
+
+
+   Donald E. Eastlake 3rd
+   Motorola
+   140 Forest Avenue
+   Hudson, MA 01749 USA
+
+   Phone: +1 508 261 5434
+   EMail: dee3@torque.pothole.com
+
+
+   Brian Wellington
+   Nominum, Inc.
+   950 Charter Street
+   Redwood City, CA 94063
+
+   Phone: +1 650 779 6022
+   EMail: Brian.Wellington@nominum.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Vixie, et al.               Standards Track                    [Page 14]
+
+RFC 2845                        DNS TSIG                        May 2000
+
+
+10  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2000).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Vixie, et al.               Standards Track                    [Page 15]
+
diff --git a/doc/rfc/rfc2874.txt b/doc/rfc/rfc2874.txt
new file mode 100644
index 0000000..915c104
--- /dev/null
+++ b/doc/rfc/rfc2874.txt
@@ -0,0 +1,1123 @@
+
+
+
+
+
+
+Network Working Group                                        M. Crawford
+Request for Comments: 2874                                      Fermilab
+Category: Standards Track                                     C. Huitema
+                                                   Microsoft Corporation
+                                                               July 2000
+
+
+   DNS Extensions to Support IPv6 Address Aggregation and Renumbering
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2000).  All Rights Reserved.
+
+Abstract
+
+   This document defines changes to the Domain Name System to support
+   renumberable and aggregatable IPv6 addressing.  The changes include a
+   new resource record type to store an IPv6 address in a manner which
+   expedites network renumbering and updated definitions of existing
+   query types that return Internet addresses as part of additional
+   section processing.
+
+   For lookups keyed on IPv6 addresses (often called reverse lookups),
+   this document defines a new zone structure which allows a zone to be
+   used without modification for parallel copies of an address space (as
+   for a multihomed provider or site) and across network renumbering
+   events.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crawford, et al.            Standards Track                     [Page 1]
+
+RFC 2874                        IPv6 DNS                       July 2000
+
+
+Table of Contents
+
+   1.  Introduction ...............................................  2
+   2.  Overview ...................................................  3
+       2.1.  Name-to-Address Lookup ...............................  4
+       2.2.  Underlying Mechanisms for Reverse Lookups ............  4
+           2.2.1.  Delegation on Arbitrary Boundaries .............  4
+           2.2.2.  Reusable Zones .................................  5
+   3.  Specifications .............................................  5
+       3.1.  The A6 Record Type ...................................  5
+           3.1.1.  Format .........................................  6
+           3.1.2.  Processing .....................................  6
+           3.1.3.  Textual Representation .........................  7
+           3.1.4.  Name Resolution Procedure ......................  7
+       3.2.  Zone Structure for Reverse Lookups ...................  7
+   4.  Modifications to Existing Query Types ......................  8
+   5.  Usage Illustrations ........................................  8
+       5.1.  A6 Record Chains .....................................  9
+           5.1.1.  Authoritative Data .............................  9
+           5.1.2.  Glue ........................................... 10
+           5.1.3.  Variations ..................................... 12
+       5.2.  Reverse Mapping Zones ................................ 13
+           5.2.1.  The TLA level .................................. 13
+           5.2.2.  The ISP level .................................. 13
+           5.2.3.  The Site Level ................................. 13
+       5.3.  Lookups .............................................. 14
+       5.4.  Operational Note ..................................... 15
+   6.  Transition from RFC 1886 and Deployment Notes .............. 15
+       6.1.  Transition from AAAA and Coexistence with A Records .. 16
+       6.2.  Transition from Nibble Labels to Binary Labels ....... 17
+   7.  Security Considerations .................................... 17
+   8.  IANA Considerations ........................................ 17
+   9.  Acknowledgments ............................................ 18
+   10.  References ................................................ 18
+   11.  Authors' Addresses ........................................ 19
+   12.  Full Copyright Statement .................................. 20
+
+1.  Introduction
+
+   Maintenance of address information in the DNS is one of several
+   obstacles which have prevented site and provider renumbering from
+   being feasible in IP version 4.  Arguments about the importance of
+   network renumbering for the preservation of a stable routing system
+   and for other purposes may be read in [RENUM1, RENUM2, RENUM3].  To
+   support the storage of IPv6 addresses without impeding renumbering we
+   define the following extensions.
+
+
+
+
+
+Crawford, et al.            Standards Track                     [Page 2]
+
+RFC 2874                        IPv6 DNS                       July 2000
+
+
+   o  A new resource record type, "A6", is defined to map a domain name
+      to an IPv6 address, with a provision for indirection for leading
+      "prefix" bits.
+
+   o  Existing queries that perform additional section processing to
+      locate IPv4 addresses are redefined to do that processing for both
+      IPv4 and IPv6 addresses.
+
+   o  A new domain, IP6.ARPA, is defined to support lookups based on
+      IPv6 address.
+
+   o  A new prefix-delegation method is defined, relying on new DNS
+      features [BITLBL, DNAME].
+
+   The changes are designed to be compatible with existing application
+   programming interfaces.  The existing support for IPv4 addresses is
+   retained.  Transition issues related to the coexistence of both IPv4
+   and IPv6 addresses in DNS are discussed in [TRANS].
+
+   This memo proposes a replacement for the specification in RFC 1886
+   [AAAA] and a departure from current implementation practices.  The
+   changes are designed to facilitate network renumbering and
+   multihoming.  Domains employing the A6 record for IPv6 addresses can
+   insert automatically-generated AAAA records in zone files to ease
+   transition.  It is expected that after a reasonable period, RFC 1886
+   will become Historic.
+
+   The next three major sections of this document are an overview of the
+   facilities defined or employed by this specification, the
+   specification itself, and examples of use.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [KWORD].  The key word
+   "SUGGESTED" signifies a strength between MAY and SHOULD: it is
+   believed that compliance with the suggestion has tangible benefits in
+   most instances.
+
+2.  Overview
+
+   This section provides an overview of the DNS facilities for storage
+   of IPv6 addresses and for lookups based on IPv6 address, including
+   those defined here and elsewhere.
+
+
+
+
+
+
+
+
+Crawford, et al.            Standards Track                     [Page 3]
+
+RFC 2874                        IPv6 DNS                       July 2000
+
+
+2.1.  Name-to-Address Lookup
+
+   IPv6 addresses are stored in one or more A6 resource records.  A
+   single A6 record may include a complete IPv6 address, or a contiguous
+   portion of an address and information leading to one or more
+   prefixes.  Prefix information comprises a prefix length and a DNS
+   name which is in turn the owner of one or more A6 records defining
+   the prefix or prefixes which are needed to form one or more complete
+   IPv6 addresses.  When the prefix length is zero, no DNS name is
+   present and all the leading bits of the address are significant.
+   There may be multiple levels of indirection and the existence of
+   multiple A6 records at any level multiplies the number of IPv6
+   addresses which are formed.
+
+   An application looking up an IPv6 address will generally cause the
+   DNS resolver to access several A6 records, and multiple IPv6
+   addresses may be returned even if the queried name was the owner of
+   only one A6 record.  The authenticity of the returned address(es)
+   cannot be directly verified by DNS Security [DNSSEC].  The A6 records
+   which contributed to the address(es) may of course be verified if
+   signed.
+
+   Implementers are reminded of the necessity to limit the amount of
+   work a resolver will perform in response to a client request.  This
+   principle MUST be extended to also limit the generation of DNS
+   requests in response to one name-to-address (or address-to-name)
+   lookup request.
+
+2.2.  Underlying Mechanisms for Reverse Lookups
+
+   This section describes the new DNS features which this document
+   exploits.  This section is an overview, not a specification of those
+   features.  The reader is directed to the referenced documents for
+   more details on each.
+
+2.2.1.  Delegation on Arbitrary Boundaries
+
+   This new scheme for reverse lookups relies on a new type of DNS label
+   called the "bit-string label" [BITLBL].  This label compactly
+   represents an arbitrary string of bits which is treated as a
+   hierarchical sequence of one-bit domain labels.  Resource records can
+   thereby be stored at arbitrary bit-boundaries.
+
+   Examples in section 5 will employ the following textual
+   representation for bit-string labels, which is a subset of the syntax
+   defined in [BITLBL].  A base indicator "x" for hexadecimal and a
+   sequence of hexadecimal digits is enclosed between "\[" and "]".  The
+   bits denoted by the digits represent a sequence of one-bit domain
+
+
+
+Crawford, et al.            Standards Track                     [Page 4]
+
+RFC 2874                        IPv6 DNS                       July 2000
+
+
+   labels ordered from most to least significant.  (This is the opposite
+   of the order they would appear if listed one bit at a time, but it
+   appears to be a convenient notation.)  The digit string may be
+   followed by a slash ("/") and a decimal count.  If omitted, the
+   implicit count is equal to four times the number of hexadecimal
+   digits.
+
+   Consecutive bit-string labels are equivalent (up to the limit imposed
+   by the size of the bit count field) to a single bit-string label
+   containing all the bits of the consecutive labels in the proper
+   order.  As an example, either of the following domain names could be
+   used in a QCLASS=IN, QTYPE=PTR query to find the name of the node
+   with IPv6 address 3ffe:7c0:40:9:a00:20ff:fe81:2b32.
+
+    \[x3FFE07C0004000090A0020FFFE812B32/128].IP6.ARPA.
+
+    \[x0A0020FFFE812B32/64].\[x0009/16].\[x3FFE07C00040/48].IP6.ARPA.
+
+2.2.2.  Reusable Zones
+
+   DNS address space delegation is implemented not by zone cuts and NS
+   records, but by a new analogue to the CNAME record, called the DNAME
+   resource record [DNAME].  The DNAME record provides alternate naming
+   to an entire subtree of the domain name space, rather than to a
+   single node.  It causes some suffix of a queried name to be
+   substituted with a name from the DNAME record's RDATA.
+
+   For example, a resolver or server providing recursion, while looking
+   up a QNAME a.b.c.d.e.f may encounter a DNAME record
+
+                        d.e.f.     DNAME     w.xy.
+
+   which will cause it to look for a.b.c.w.xy.
+
+3.  Specifications
+
+3.1.  The A6 Record Type
+
+   The A6 record type is specific to the IN (Internet) class and has
+   type number 38 (decimal).
+
+
+
+
+
+
+
+
+
+
+
+Crawford, et al.            Standards Track                     [Page 5]
+
+RFC 2874                        IPv6 DNS                       July 2000
+
+
+3.1.1.  Format
+
+   The RDATA portion of the A6 record contains two or three fields.
+
+           +-----------+------------------+-------------------+
+           |Prefix len.|  Address suffix  |    Prefix name    |
+           | (1 octet) |  (0..16 octets)  |  (0..255 octets)  |
+           +-----------+------------------+-------------------+
+
+   o  A prefix length, encoded as an eight-bit unsigned integer with
+      value between 0 and 128 inclusive.
+
+   o  An IPv6 address suffix, encoded in network order (high-order octet
+      first).  There MUST be exactly enough octets in this field to
+      contain a number of bits equal to 128 minus prefix length, with 0
+      to 7 leading pad bits to make this field an integral number of
+      octets.  Pad bits, if present, MUST be set to zero when loading a
+      zone file and ignored (other than for SIG [DNSSEC] verification)
+      on reception.
+
+   o  The name of the prefix, encoded as a domain name.  By the rules of
+      [DNSIS], this name MUST NOT be compressed.
+
+   The domain name component SHALL NOT be present if the prefix length
+   is zero.  The address suffix component SHALL NOT be present if the
+   prefix length is 128.
+
+   It is SUGGESTED that an A6 record intended for use as a prefix for
+   other A6 records have all the insignificant trailing bits in its
+   address suffix field set to zero.
+
+3.1.2.  Processing
+
+   A query with QTYPE=A6 causes type A6 and type NS additional section
+   processing for the prefix names, if any, in the RDATA field of the A6
+   records in the answer section.  This processing SHOULD be recursively
+   applied to the prefix names of A6 records included as additional
+   data.  When space in the reply packet is a limit, inclusion of
+   additional A6 records takes priority over NS records.
+
+   It is an error for an A6 record with prefix length L1 > 0 to refer to
+   a domain name which owns an A6 record with a prefix length L2 > L1.
+   If such a situation is encountered by a resolver, the A6 record with
+   the offending (larger) prefix length MUST be ignored.  Robustness
+   precludes signaling an error if addresses can still be formed from
+   valid A6 records, but it is SUGGESTED that zone maintainers from time
+   to time check all the A6 records their zones reference.
+
+
+
+
+Crawford, et al.            Standards Track                     [Page 6]
+
+RFC 2874                        IPv6 DNS                       July 2000
+
+
+3.1.3.  Textual Representation
+
+   The textual representation of the RDATA portion of the A6 resource
+   record in a zone file comprises two or three fields separated by
+   whitespace.
+
+   o  A prefix length, represented as a decimal number between 0 and 128
+      inclusive,
+
+   o  the textual representation of an IPv6 address as defined in
+      [AARCH] (although some leading and/or trailing bits may not be
+      significant),
+
+   o  a domain name, if the prefix length is not zero.
+
+   The domain name MUST be absent if the prefix length is zero.  The
+   IPv6 address MAY be be absent if the prefix length is 128.  A number
+   of leading address bits equal to the prefix length SHOULD be zero,
+   either implicitly (through the :: notation) or explicitly, as
+   specified in section 3.1.1.
+
+3.1.4.  Name Resolution Procedure
+
+   To obtain the IPv6 address or addresses which belong to a given name,
+   a DNS client MUST obtain one or more complete chains of A6 records,
+   each chain beginning with a record owned by the given name and
+   including a record owned by the prefix name in that record, and so on
+   recursively, ending with an A6 record with a prefix length of zero.
+   One IPv6 address is formed from one such chain by taking the value of
+   each bit position from the earliest A6 record in the chain which
+   validly covers that position, as indicated by the prefix length.  The
+   set of all IPv6 addresses for the given name comprises the addresses
+   formed from all complete chains of A6 records beginning at that name,
+   discarding records which have invalid prefix lengths as defined in
+   section 3.1.2.
+
+   If some A6 queries fail and others succeed, a client might obtain a
+   non-empty but incomplete set of IPv6 addresses for a host.  In many
+   situations this may be acceptable.  The completeness of a set of A6
+   records may always be determined by inspection.
+
+3.2.  Zone Structure for Reverse Lookups
+
+   Very little of the new scheme's data actually appears under IP6.ARPA;
+   only the first level of delegation needs to be under that domain.
+   More levels of delegation could be placed under IP6.ARPA if some
+   top-level delegations were done via NS records instead of DNAME
+   records, but this would incur some cost in renumbering ease at the
+
+
+
+Crawford, et al.            Standards Track                     [Page 7]
+
+RFC 2874                        IPv6 DNS                       July 2000
+
+
+   level of TLAs [AGGR].  Therefore, it is declared here that all
+   address space delegations SHOULD be done by the DNAME mechanism
+   rather than NS.
+
+   In addition, since uniformity in deployment will simplify maintenance
+   of address delegations, it is SUGGESTED that address and prefix
+   information be stored immediately below a DNS label "IP6".  Stated
+   another way, conformance with this suggestion would mean that "IP6"
+   is the first label in the RDATA field of DNAME records which support
+   IPv6 reverse lookups.
+
+   When any "reserved" or "must be zero" bits are adjacent to a
+   delegation boundary, the higher-level entity MUST retain those bits
+   in its own control and delegate only the bits over which the lower-
+   level entity has authority.
+
+   To find the name of a node given its IPv6 address, a DNS client MUST
+   perform a query with QCLASS=IN, QTYPE=PTR on the name formed from the
+   128 bit address as one or more bit-string labels [BITLBL], followed
+   by the two standard labels "IP6.ARPA".  If recursive service was not
+   obtained from a server and the desired PTR record was not returned,
+   the resolver MUST handle returned DNAME records as specified in
+   [DNAME], and NS records as specified in [DNSCF], and iterate.
+
+4.  Modifications to Existing Query Types
+
+   All existing query types that perform type A additional section
+   processing, i.e. the name server (NS), mail exchange (MX), and
+   mailbox (MB) query types, and the experimental AFS data base (AFSDB)
+   and route through (RT) types, must be redefined to perform type A, A6
+   and AAAA additional section processing, with type A having the
+   highest priority for inclusion and type AAAA the lowest.  This
+   redefinition means that a name server may add any relevant IPv4 and
+   IPv6 address information available locally to the additional section
+   of a response when processing any one of the above queries.  The
+   recursive inclusion of A6 records referenced by A6 records already
+   included in the additional section is OPTIONAL.
+
+5.  Usage Illustrations
+
+   This section provides examples of use of the mechanisms defined in
+   the previous section.  All addresses and domains mentioned here are
+   intended to be fictitious and for illustrative purposes only.
+   Example delegations will be on 4-bit boundaries solely for
+   readability; this specification is indifferent to bit alignment.
+
+   Use of the IPv6 aggregatable address format [AGGR] is assumed in the
+   examples.
+
+
+
+Crawford, et al.            Standards Track                     [Page 8]
+
+RFC 2874                        IPv6 DNS                       July 2000
+
+
+5.1.  A6 Record Chains
+
+   Let's take the example of a site X that is multi-homed to two
+   "intermediate" providers A and B.  The provider A is itself multi-
+   homed to two "transit" providers, C and D.  The provider B gets its
+   transit service from a single provider, E.  For simplicity suppose
+   that C, D and E all belong to the same top-level aggregate (TLA) with
+   identifier (including format prefix) '2345', and the TLA authority at
+   ALPHA-TLA.ORG assigns to C, D and E respectively the next level
+   aggregate (NLA) prefixes 2345:00C0::/28, 2345:00D0::/28 and
+   2345:000E::/32.
+
+   C assigns the NLA prefix 2345:00C1:CA00::/40 to A, D assigns the
+   prefix 2345:00D2:DA00::/40 to A and E assigns 2345:000E:EB00::/40 to
+   B.
+
+   A assigns to X the subscriber identification '11' and B assigns the
+   subscriber identification '22'.  As a result, the site X inherits
+   three address prefixes:
+
+   o  2345:00C1:CA11::/48 from A, for routes through C.
+   o  2345:00D2:DA11::/48 from A, for routes through D.
+   o  2345:000E:EB22::/48 from B, for routes through E.
+
+   Let us suppose that N is a node in the site X, that it is assigned to
+   subnet number 1 in this site, and that it uses the interface
+   identifier '1234:5678:9ABC:DEF0'.  In our configuration, this node
+   will have three addresses:
+
+   o  2345:00C1:CA11:0001:1234:5678:9ABC:DEF0
+   o  2345:00D2:DA11:0001:1234:5678:9ABC:DEF0
+   o  2345:000E:EB22:0001:1234:5678:9ABC:DEF0
+
+5.1.1.  Authoritative Data
+
+   We will assume that the site X is represented in the DNS by the
+   domain name X.EXAMPLE, while A, B, C, D and E are represented by
+   A.NET, B.NET, C.NET, D.NET and E.NET.  In each of these domains, we
+   assume a subdomain "IP6" that will hold the corresponding prefixes.
+   The node N is identified by the domain name N.X.EXAMPLE.  The
+   following records would then appear in X's DNS.
+
+          $ORIGIN X.EXAMPLE.
+          N            A6 64 ::1234:5678:9ABC:DEF0 SUBNET-1.IP6
+          SUBNET-1.IP6 A6 48 0:0:0:1::  IP6
+          IP6          A6 48 0::0       SUBSCRIBER-X.IP6.A.NET.
+          IP6          A6 48 0::0       SUBSCRIBER-X.IP6.B.NET.
+
+
+
+
+Crawford, et al.            Standards Track                     [Page 9]
+
+RFC 2874                        IPv6 DNS                       July 2000
+
+
+   And elsewhere there would appear
+
+        SUBSCRIBER-X.IP6.A.NET. A6 40 0:0:0011:: A.NET.IP6.C.NET.
+        SUBSCRIBER-X.IP6.A.NET. A6 40 0:0:0011:: A.NET.IP6.D.NET.
+
+        SUBSCRIBER-X.IP6.B.NET. A6 40 0:0:0022:: B-NET.IP6.E.NET.
+
+        A.NET.IP6.C.NET. A6 28 0:0001:CA00:: C.NET.ALPHA-TLA.ORG.
+
+        A.NET.IP6.D.NET. A6 28 0:0002:DA00:: D.NET.ALPHA-TLA.ORG.
+
+        B-NET.IP6.E.NET. A6 32 0:0:EB00::    E.NET.ALPHA-TLA.ORG.
+
+        C.NET.ALPHA-TLA.ORG. A6 0 2345:00C0::
+        D.NET.ALPHA-TLA.ORG. A6 0 2345:00D0::
+        E.NET.ALPHA-TLA.ORG. A6 0 2345:000E::
+
+5.1.2.  Glue
+
+   When, as is common, some or all DNS servers for X.EXAMPLE are within
+   the X.EXAMPLE zone itself, the top-level zone EXAMPLE must carry
+   enough "glue" information to enable DNS clients to reach those
+   nameservers.  This is true in IPv6 just as in IPv4.  However, the A6
+   record affords the DNS administrator some choices.  The glue could be
+   any of
+
+   o  a minimal set of A6 records duplicated from the X.EXAMPLE zone,
+
+   o  a (possibly smaller) set of records which collapse the structure
+      of that minimal set,
+
+   o  or a set of A6 records with prefix length zero, giving the entire
+      global addresses of the servers.
+
+   The trade-off is ease of maintenance against robustness.  The best
+   and worst of both may be had together by implementing either the
+   first or second option together with the third.  To illustrate the
+   glue options, suppose that X.EXAMPLE is served by two nameservers
+   NS1.X.EXAMPLE and NS2.X.EXAMPLE, having interface identifiers
+   ::1:11:111:1111 and ::2:22:222:2222 on subnets 1 and 2 respectively.
+   Then the top-level zone EXAMPLE would include one (or more) of the
+   following sets of A6 records as glue.
+
+
+
+
+
+
+
+
+
+Crawford, et al.            Standards Track                    [Page 10]
+
+RFC 2874                        IPv6 DNS                       July 2000
+
+
+   $ORIGIN EXAMPLE.            ; first option
+   X               NS NS1.X
+                   NS NS2.X
+   NS1.X           A6 64 ::1:11:111:1111 SUBNET-1.IP6.X
+   NS2.X           A6 64 ::2:22:222:2222 SUBNET-2.IP6.X
+   SUBNET-1.IP6.X  A6 48 0:0:0:1::       IP6.X
+   SUBNET-2.IP6.X  A6 48 0:0:0:2::       IP6.X
+   IP6.X           A6 48 0::0            SUBSCRIBER-X.IP6.A.NET.
+   IP6.X           A6 48 0::0            SUBSCRIBER-X.IP6.B.NET.
+
+
+   $ORIGIN EXAMPLE.            ; second option
+   X               NS NS1.X
+                   NS NS2.X
+   NS1.X           A6 48 ::1:1:11:111:1111 SUBSCRIBER-X.IP6.A.NET.
+                   A6 48 ::1:1:11:111:1111 SUBSCRIBER-X.IP6.B.NET.
+   NS2.X           A6 48 ::2:2:22:222:2222 SUBSCRIBER-X.IP6.A.NET.
+                   A6 48 ::2:2:22:222:2222 SUBSCRIBER-X.IP6.B.NET.
+
+
+   $ORIGIN EXAMPLE.            ; third option
+   X               NS NS1.X
+                   NS NS2.X
+   NS1.X           A6 0  2345:00C1:CA11:1:1:11:111:1111
+                   A6 0  2345:00D2:DA11:1:1:11:111:1111
+                   A6 0  2345:000E:EB22:1:1:11:111:1111
+   NS2.X           A6 0  2345:00C1:CA11:2:2:22:222:2222
+                   A6 0  2345:00D2:DA11:2:2:22:222:2222
+                   A6 0  2345:000E:EB22:2:2:22:222:2222
+
+   The first and second glue options are robust against renumbering of
+   X.EXAMPLE's prefixes by providers A.NET and B.NET, but will fail if
+   those providers' own DNS is unreachable.  The glue records of the
+   third option are robust against DNS failures elsewhere than the zones
+   EXAMPLE and X.EXAMPLE themselves, but must be updated when X's
+   address space is renumbered.
+
+   If the EXAMPLE zone includes redundant glue, for instance the union
+   of the A6 records of the first and third options, then under normal
+   circumstances duplicate IPv6 addresses will be derived by DNS
+   clients.  But if provider DNS fails, addresses will still be obtained
+   from the zero-prefix-length records, while if the EXAMPLE zone lags
+   behind a renumbering of X.EXAMPLE, half of the addresses obtained by
+   DNS clients will still be up-to-date.
+
+   The zero-prefix-length glue records can of course be automatically
+   generated and/or checked in practice.
+
+
+
+
+Crawford, et al.            Standards Track                    [Page 11]
+
+RFC 2874                        IPv6 DNS                       July 2000
+
+
+5.1.3.  Variations
+
+   Several more-or-less arbitrary assumptions are reflected in the above
+   structure.  All of the following choices could have been made
+   differently, according to someone's notion of convenience or an
+   agreement between two parties.
+
+      First, that site X has chosen to put subnet information in a
+      separate A6 record rather than incorporate it into each node's A6
+      records.
+
+      Second, that site X is referred to as "SUBSCRIBER-X" by both of
+      its providers A and B.
+
+      Third, that site X chose to indirect its provider information
+      through A6 records at IP6.X.EXAMPLE containing no significant
+      bits.  An alternative would have been to replicate each subnet
+      record for each provider.
+
+      Fourth, B and E used a slightly different prefix naming convention
+      between themselves than did A, C and D.  Each hierarchical pair of
+      network entities must arrange this naming between themselves.
+
+      Fifth, that the upward prefix referral chain topped out at ALPHA-
+      TLA.ORG.  There could have been another level which assigned the
+      TLA values and holds A6 records containing those bits.
+
+   Finally, the above structure reflects an assumption that address
+   fields assigned by a given entity are recorded only in A6 records
+   held by that entity.  Those bits could be entered into A6 records in
+   the lower-level entity's zone instead, thus:
+
+                IP6.X.EXAMPLE. A6 40 0:0:11::   IP6.A.NET.
+                IP6.X.EXAMPLE. A6 40 0:0:22::   IP6.B.NET.
+
+                IP6.A.NET.     A6 28 0:1:CA00:: IP6.C.NET.
+                and so on.
+
+   Or the higher-level entities could hold both sorts of A6 records
+   (with different DNS owner names) and allow the lower-level entities
+   to choose either mode of A6 chaining.  But the general principle of
+   avoiding data duplication suggests that the proper place to store
+   assigned values is with the entity that assigned them.
+
+   It is possible, but not necessarily recommended, for a zone
+   maintainer to forego the renumbering support afforded by the chaining
+   of A6 records and to record entire IPv6 addresses within one zone
+   file.
+
+
+
+Crawford, et al.            Standards Track                    [Page 12]
+
+RFC 2874                        IPv6 DNS                       July 2000
+
+
+5.2.  Reverse Mapping Zones
+
+   Supposing that address space assignments in the TLAs with Format
+   Prefix (001) binary and IDs 0345, 0678 and 09AB were maintained in
+   zones called ALPHA-TLA.ORG, BRAVO-TLA.ORG and CHARLIE-TLA.XY, then
+   the IP6.ARPA zone would include
+
+               $ORIGIN IP6.ARPA.
+               \[x234500/24]   DNAME   IP6.ALPHA-TLA.ORG.
+               \[x267800/24]   DNAME   IP6.BRAVO-TLA.ORG.
+               \[x29AB00/24]   DNAME   IP6.CHARLIE-TLA.XY.
+
+   Eight trailing zero bits have been included in each TLA ID to reflect
+   the eight reserved bits in the current aggregatable global unicast
+   addresses format [AGGR].
+
+5.2.1.  The TLA level
+
+   ALPHA-TLA's assignments to network providers C, D and E are reflected
+   in the reverse data as follows.
+
+              \[xC/4].IP6.ALPHA-TLA.ORG.   DNAME  IP6.C.NET.
+              \[xD/4].IP6.ALPHA-TLA.ORG.   DNAME  IP6.D.NET.
+              \[x0E/8].IP6.ALPHA-TLA.ORG.  DNAME  IP6.E.NET.
+
+5.2.2.  The ISP level
+
+   The providers A through E carry the following delegation information
+   in their zone files.
+
+               \[x1CA/12].IP6.C.NET.  DNAME  IP6.A.NET.
+               \[x2DA/12].IP6.D.NET.  DNAME  IP6.A.NET.
+               \[xEB/8].IP6.E.NET.    DNAME  IP6.B.NET.
+               \[x11/8].IP6.A.NET.    DNAME  IP6.X.EXAMPLE.
+               \[x22/8].IP6.B.NET.    DNAME  IP6.X.EXAMPLE.
+
+   Note that some domain names appear in the RDATA of more than one
+   DNAME record.  In those cases, one zone is being used to map multiple
+   prefixes.
+
+5.2.3.  The Site Level
+
+   Consider the customer X.EXAMPLE using IP6.X.EXAMPLE for address-to-
+   name translations.  This domain is now referenced by two different
+   DNAME records held by two different providers.
+
+
+
+
+
+
+Crawford, et al.            Standards Track                    [Page 13]
+
+RFC 2874                        IPv6 DNS                       July 2000
+
+
+           $ORIGIN IP6.X.EXAMPLE.
+           \[x0001/16]                    DNAME   SUBNET-1
+           \[x123456789ABCDEF0].SUBNET-1  PTR     N.X.EXAMPLE.
+           and so on.
+
+   SUBNET-1 need not have been named in a DNAME record; the subnet bits
+   could have been joined with the interface identifier.  But if subnets
+   are treated alike in both the A6 records and in the reverse zone, it
+   will always be possible to keep the forward and reverse definition
+   data for each prefix in one zone.
+
+5.3.  Lookups
+
+   A DNS resolver looking for a hostname for the address
+   2345:00C1:CA11:0001:1234:5678:9ABC:DEF0 would acquire certain of the
+   DNAME records shown above and would form new queries.  Assuming that
+   it began the process knowing servers for IP6.ARPA, but that no server
+   it consulted provided recursion and none had other useful additional
+   information cached, the sequence of queried names and responses would
+   be (all with QCLASS=IN, QTYPE=PTR):
+
+   To a server for IP6.ARPA:
+   QNAME=\[x234500C1CA110001123456789ABCDEF0/128].IP6.ARPA.
+
+        Answer:
+        \[x234500/24].IP6.ARPA. DNAME IP6.ALPHA-TLA.ORG.
+
+   To a server for IP6.ALPHA-TLA.ORG:
+   QNAME=\[xC1CA110001123456789ABCDEF0/104].IP6.ALPHA-TLA.ORG.
+
+        Answer:
+        \[xC/4].IP6.ALPHA-TLA.ORG. DNAME IP6.C.NET.
+
+   To a server for IP6.C.NET.:
+   QNAME=\[x1CA110001123456789ABCDEF0/100].IP6.C.NET.
+
+        Answer:
+        \[x1CA/12].IP6.C.NET. DNAME IP6.A.NET.
+
+   To a server for IP6.A.NET.:
+   QNAME=\[x110001123456789ABCDEF0/88].IP6.A.NET.
+
+        Answer:
+        \[x11/8].IP6.A.NET. DNAME IP6.X.EXAMPLE.
+
+   To a server for IP6.X.EXAMPLE.:
+   QNAME=\[x0001123456789ABCDEF0/80].IP6.X.EXAMPLE.
+
+
+
+
+Crawford, et al.            Standards Track                    [Page 14]
+
+RFC 2874                        IPv6 DNS                       July 2000
+
+
+        Answer:
+        \[x0001/16].IP6.X.EXAMPLE. DNAME SUBNET-1.IP6.X.EXAMPLE.
+        \[x123456789ABCDEF0/64].SUBNET-1.X.EXAMPLE. PTR N.X.EXAMPLE.
+
+   All the DNAME (and NS) records acquired along the way can be cached
+   to expedite resolution of addresses topologically near to this
+   address.  And if another global address of N.X.EXAMPLE were resolved
+   within the TTL of the final PTR record, that record would not have to
+   be fetched again.
+
+5.4.  Operational Note
+
+   In the illustrations in section 5.1, hierarchically adjacent
+   entities, such as a network provider and a customer, must agree on a
+   DNS name which will own the definition of the delegated prefix(es).
+   One simple convention would be to use a bit-string label representing
+   exactly the bits which are assigned to the lower-level entity by the
+   higher.  For example, "SUBSCRIBER-X" could be replaced by "\[x11/8]".
+   This would place the A6 record(s) defining the delegated prefix at
+   exactly the same point in the DNS tree as the DNAME record associated
+   with that delegation.  The cost of this simplification is that the
+   lower-level zone must update its upward-pointing A6 records when it
+   is renumbered.  This cost may be found quite acceptable in practice.
+
+6.  Transition from RFC 1886 and Deployment Notes
+
+   When prefixes have been "delegated upward" with A6 records, the
+   number of DNS resource records required to establish a single IPv6
+   address increases by some non-trivial factor.  Those records will
+   typically, but not necessarily, come from different DNS zones (which
+   can independently suffer failures for all the usual reasons).  When
+   obtaining multiple IPv6 addresses together, this increase in RR count
+   will be proportionally less -- and the total size of a DNS reply
+   might even decrease -- if the addresses are topologically clustered.
+   But the records could still easily exceed the space available in a
+   UDP response which returns a large RRset [DNSCLAR] to an MX, NS, or
+   SRV query, for example.  The possibilities for overall degradation of
+   performance and reliability of DNS lookups are numerous, and increase
+   with the number of prefix delegations involved, especially when those
+   delegations point to records in other zones.
+
+   DNS Security [DNSSEC] addresses the trustworthiness of cached data,
+   which is a problem intrinsic to DNS, but the cost of applying this to
+   an IPv6 address is multiplied by a factor which may be greater than
+   the number of prefix delegations involved if different signature
+   chains must be verified for different A6 records.  If a trusted
+   centralized caching server (as in [TSIG], for example) is used, this
+   cost might be amortized to acceptable levels.  One new phenomenon is
+
+
+
+Crawford, et al.            Standards Track                    [Page 15]
+
+RFC 2874                        IPv6 DNS                       July 2000
+
+
+   the possibility that IPv6 addresses may be formed from a A6 records
+   from a combination of secure and unsecured zones.
+
+   Until more deployment experience is gained with the A6 record, it is
+   recommended that prefix delegations be limited to one or two levels.
+   A reasonable phasing-in mechanism would be to start with no prefix
+   delegations (all A6 records having prefix length 0) and then to move
+   to the use of a single level of delegation within a single zone.  (If
+   the TTL of the "prefix" A6 records is kept to an appropriate duration
+   the capability for rapid renumbering is not lost.)  More aggressively
+   flexible delegation could be introduced for a subset of hosts for
+   experimentation.
+
+6.1.  Transition from AAAA and Coexistence with A Records
+
+   Administrators of zones which contain A6 records can easily
+   accommodate deployed resolvers which understand AAAA records but not
+   A6 records.  Such administrators can do automatic generation of AAAA
+   records for all of a zone's names which own A6 records by a process
+   which mimics the resolution of a hostname to an IPv6 address (see
+   section 3.1.4).  Attention must be paid to the TTL assigned to a
+   generated AAAA record, which MUST be no more than the minimum of the
+   TTLs of the A6 records that were used to form the IPv6 address in
+   that record.  For full robustness, those A6 records which were in
+   different zones should be monitored for changes (in TTL or RDATA)
+   even when there are no changes to zone for which AAAA records are
+   being generated.  If the zone is secure [DNSSEC], the generated AAAA
+   records MUST be signed along with the rest of the zone data.
+
+   A zone-specific heuristic MAY be used to avoid generation of AAAA
+   records for A6 records which record prefixes, although such
+   superfluous records would be relatively few in number and harmless.
+   Examples of such heuristics include omitting A6 records with a prefix
+   length less than the largest value found in the zone file, or records
+   with an address suffix field with a certain number of trailing zero
+   bits.
+
+   On the client side, when looking up and IPv6 address, the order of A6
+   and AAAA queries MAY be configurable to be one of: A6, then AAAA;
+   AAAA, then A6; A6 only; or both in parallel.  The default order (or
+   only order, if not configurable) MUST be to try A6 first, then AAAA.
+   If and when the AAAA becomes deprecated a new document will change
+   the default.
+
+   The guidelines and options for precedence between IPv4 and IPv6
+   addresses are specified in [TRANS].  All mentions of AAAA records in
+   that document are henceforth to be interpreted as meaning A6 and/or
+   AAAA records in the order specified in the previous paragraph.
+
+
+
+Crawford, et al.            Standards Track                    [Page 16]
+
+RFC 2874                        IPv6 DNS                       July 2000
+
+
+6.2.  Transition from Nibble Labels to Binary Labels
+
+   Implementations conforming to RFC 1886 [AAAA] perform reverse lookups
+   as follows:
+
+      An IPv6 address is represented as a name in the IP6.INT domain by
+      a sequence of nibbles separated by dots with the suffix
+      ".IP6.INT". The sequence of nibbles is encoded in reverse order,
+      i.e. the low-order nibble is encoded first, followed by the next
+      low-order nibble and so on. Each nibble is represented by a
+      hexadecimal digit. For example, a name for the address
+      2345:00C1:CA11:0001:1234:5678:9ABC:DEF0 of the example in section
+      5.3 would be sought at the DNS name "0.f.e.d.c.b.a.9.-
+      8.7.6.5.4.3.2.1.1.0.0.0.1.1.a.c.1.c.0.0.5.4.3.2.ip6.int."
+
+   Implementations conforming to this specification will perform a
+   lookup of a binary label in IP6.ARPA as specified in Section 3.2.  It
+   is RECOMMENDED that for a transition period implementations first
+   lookup the binary label in IP6.ARPA and if this fails try to lookup
+   the 'nibble' label in IP6.INT.
+
+7.  Security Considerations
+
+   The signing authority [DNSSEC] for the A6 records which determine an
+   IPv6 address is distributed among several entities, reflecting the
+   delegation path of the address space which that address occupies.
+   DNS Security is fully applicable to bit-string labels and DNAME
+   records.  And just as in IPv4, verification of name-to-address
+   mappings is logically independent of verification of address-to-name
+   mappings.
+
+   With or without DNSSEC, the incomplete but non-empty address set
+   scenario of section 3.1.4 could be caused by selective interference
+   with DNS lookups.  If in some situation this would be more harmful
+   than complete DNS failure, it might be mitigated on the client side
+   by refusing to act on an incomplete set, or on the server side by
+   listing all addresses in A6 records with prefix length 0.
+
+8.  IANA Considerations
+
+   The A6 resource record has been assigned a Type value of 38.
+
+
+
+
+
+
+
+
+
+
+Crawford, et al.            Standards Track                    [Page 17]
+
+RFC 2874                        IPv6 DNS                       July 2000
+
+
+9.  Acknowledgments
+
+   The authors would like to thank the following persons for valuable
+   discussions and reviews:  Mark Andrews, Rob Austein, Jim Bound, Randy
+   Bush, Brian Carpenter, David Conrad, Steve Deering, Francis Dupont,
+   Robert Elz, Bob Fink, Olafur Gudmundsson, Bob Halley, Bob Hinden,
+   Edward Lewis, Bill Manning, Keith Moore, Thomas Narten, Erik
+   Nordmark, Mike O'Dell, Michael Patton and Ken Powell.
+
+10.  References
+
+   [AAAA]    Thomson, S. and C. Huitema, "DNS Extensions to support IP
+             version 6, RFC 1886, December 1995.
+
+   [AARCH]   Hinden, R. and S. Deering, "IP Version 6 Addressing
+             Architecture", RFC 2373, July 1998.
+
+   [AGGR]    Hinden, R., O'Dell, M. and S. Deering, "An IPv6
+             Aggregatable Global Unicast Address Format", RFC 2374, July
+             1998.
+
+   [BITLBL]  Crawford, M., "Binary Labels in the Domain Name System",
+             RFC 2673, August 1999.
+
+   [DNAME]   Crawford, M., "Non-Terminal DNS Name Redirection", RFC
+             2672, August 1999.
+
+   [DNSCLAR] Elz, R. and R. Bush, "Clarifications to the DNS
+             Specification", RFC 2181, July 1997.
+
+   [DNSIS]   Mockapetris, P., "Domain names - implementation and
+             specification", STD 13, RFC 1035, November 1987.
+
+   [DNSSEC]  Eastlake, D. 3rd and C. Kaufman, "Domain Name System
+             Security Extensions", RFC 2535, March 1999.
+
+   [KWORD]   Bradner, S., "Key words for use in RFCs to Indicate
+             Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RENUM1]  Carpenter, B. and Y. Rekhter, "Renumbering Needs Work", RFC
+             1900, February 1996.
+
+   [RENUM2]  Ferguson, P. and H. Berkowitz, "Network Renumbering
+             Overview:  Why would I want it and what is it anyway?", RFC
+             2071, January 1997.
+
+   [RENUM3]  Carpenter, B., Crowcroft, J. and Y. Rekhter, "IPv4 Address
+             Behaviour Today", RFC 2101, February 1997.
+
+
+
+Crawford, et al.            Standards Track                    [Page 18]
+
+RFC 2874                        IPv6 DNS                       July 2000
+
+
+   [TRANS]   Gilligan, R. and E. Nordmark, "Transition Mechanisms for
+             IPv6 Hosts and Routers", RFC 1933, April 1996.
+
+   [TSIG]    Vixie, P., Gudmundsson, O., Eastlake, D. 3rd and B.
+             Wellington, "Secret Key Transaction Authentication for DNS
+             (TSIG)", RFC 2845, May 2000.
+
+11.  Authors' Addresses
+
+   Matt Crawford
+   Fermilab
+   MS 368
+   PO Box 500
+   Batavia, IL 60510
+   USA
+
+   Phone: +1 630 840-3461
+   EMail: crawdad@fnal.gov
+
+
+   Christian Huitema
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA 98052-6399
+
+   EMail: huitema@microsoft.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crawford, et al.            Standards Track                    [Page 19]
+
+RFC 2874                        IPv6 DNS                       July 2000
+
+
+12.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2000).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crawford, et al.            Standards Track                    [Page 20]
+
diff --git a/doc/rfc/rfc2915.txt b/doc/rfc/rfc2915.txt
new file mode 100644
index 0000000..2022ba1
--- /dev/null
+++ b/doc/rfc/rfc2915.txt
@@ -0,0 +1,1011 @@
+
+
+
+
+
+
+Network Working Group                                         M. Mealling
+Request for Comments: 2915                        Network Solutions, Inc.
+Updates: 2168                                                   R. Daniel
+Category: Standards Track                                DATAFUSION, Inc.
+                                                           September 2000
+
+
+        The Naming Authority Pointer (NAPTR) DNS Resource Record
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2000). All Rights Reserved.
+
+Abstract
+
+   This document describes a Domain Name System (DNS) resource record
+   which specifies a regular expression based rewrite rule that, when
+   applied to an existing string, will produce a new domain label or
+   Uniform Resource Identifier (URI).  Depending on the value of the
+   flags field of the resource record, the resulting domain label or URI
+   may be used in subsequent queries for the Naming Authority Pointer
+   (NAPTR) resource records (to delegate the name lookup) or as the
+   output of the entire process for which this system is used (a
+   resolution server for URI resolution, a service URI for ENUM style
+   e.164 number to URI mapping, etc).
+
+   This allows the DNS to be used to lookup services for a wide variety
+   of resource names (including URIs) which are not in domain name
+   syntax.  Reasons for doing this range from URN Resource Discovery
+   Systems to moving out-of-date services to new domains.
+
+   This document updates the portions of RFC 2168 specifically dealing
+   with the definition of the NAPTR records and how other, non-URI
+   specific applications, might use NAPTR.
+
+
+
+
+
+
+
+
+
+Mealling & Daniel           Standards Track                     [Page 1]
+
+RFC 2915                      NAPTR DNS RR                September 2000
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . .   2
+   2.  NAPTR RR Format  . . . . . . . . . . . . . . . . . . . . . .   3
+   3.  Substitution Expression Grammar  . . . . . . . . . . . . . .   7
+   4.  The Basic NAPTR Algorithm  . . . . . . . . . . . . . . . . .   8
+   5.  Concerning How NAPTR Uses SRV Records  . . . . . . . . . . .   9
+   6.  Application Specifications . . . . . . . . . . . . . . . . .  10
+   7.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . .  10
+   7.1 Example 1  . . . . . . . . . . . . . . . . . . . . . . . . .  10
+   7.2 Example 2  . . . . . . . . . . . . . . . . . . . . . . . . .  12
+   7.3 Example 3  . . . . . . . . . . . . . . . . . . . . . . . . .  13
+   8.  DNS Packet Format  . . . . . . . . . . . . . . . . . . . . .  13
+   9.  Master File Format . . . . . . . . . . . . . . . . . . . . .  14
+   10. Advice for DNS Administrators  . . . . . . . . . . . . . . .  14
+   11. Notes  . . . . . . . . . . . . . . . . . . . . . . . . . . .  15
+   12. IANA Considerations  . . . . . . . . . . . . . . . . . . . .  15
+   13. Security Considerations  . . . . . . . . . . . . . . . . . .  15
+   14. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . .  16
+       References . . . . . . . . . . . . . . . . . . . . . . . . .  16
+       Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  17
+       Full Copyright Statement . . . . . . . . . . . . . . . . . .  18
+
+1. Introduction
+
+   This RR was originally produced by the URN Working Group [3] as a way
+   to encode rule-sets in DNS so that the delegated sections of a URI
+   could be decomposed in such a way that they could be changed and re-
+   delegated over time.  The result was a Resource Record that included
+   a regular expression that would be used by a client program to
+   rewrite a string into a domain name.  Regular expressions were chosen
+   for their compactness to expressivity ratio allowing for a great deal
+   of information to be encoded in a rather small DNS packet.
+
+   The function of rewriting a string according to the rules in a record
+   has usefulness in several different applications.  This document
+   defines the basic assumptions to which all of those applications must
+   adhere to.  It does not define the reasons the rewrite is used, what
+   the expected outcomes are, or what they are used for.  Those are
+   specified by applications that define how they use the NAPTR record
+   and algorithms within their contexts.
+
+   Flags and other fields are also specified in the RR to control the
+   rewrite procedure in various ways or to provide information on how to
+   communicate with the host at the domain name that was the result of
+   the rewrite.
+
+
+
+
+
+Mealling & Daniel           Standards Track                     [Page 2]
+
+RFC 2915                      NAPTR DNS RR                September 2000
+
+
+   The final result is a RR that has several fields that interact in a
+   non-trivial but implementable way.  This document specifies those
+   fields and their values.
+
+   This document does not define applications that utilizes this rewrite
+   functionality. Instead it specifies just the mechanics of how it is
+   done.  Why its done, what the rules concerning the inputs, and the
+   types of rules used are reserved for other documents that fully
+   specify a particular application.  This separation is due to several
+   different applications all wanting to take advantage of the rewrite
+   rule lookup process.  Each one has vastly different reasons for why
+   and how it uses the service, thus requiring that the definition of
+   the service be generic.
+
+      The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
+      NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
+      in this document are to be interpreted as described in RFC 2119.
+
+      All references to Uniform Resource Identifiers in this document
+      adhere to the 'absoluteURI' production of the "Collected ABNF"
+      found in RFC 2396 [9].  Specifically, the semantics of URI
+      References do not apply since the concept of a Base makes no sense
+      here.
+
+2. NAPTR RR Format
+
+   The format of the NAPTR RR is given below.  The DNS type code [1] for
+   NAPTR is 35.
+
+   Domain TTL Class Type Order Preference Flags Service Regexp
+   Replacement
+
+   Domain
+      The domain name to which this resource record refers.  This is the
+      'key' for this entry in the rule database.  This value will either
+      be the first well known key (<something>.uri.arpa for example) or
+      a new key that is the output of a replacement or regexp rewrite.
+      Beyond this, it has the standard DNS requirements [1].
+
+   TTL
+      Standard DNS meaning [1].
+
+   Class
+      Standard DNS meaning [1].
+
+   Type
+      The Type Code [1] for NAPTR is 35.
+
+
+
+
+Mealling & Daniel           Standards Track                     [Page 3]
+
+RFC 2915                      NAPTR DNS RR                September 2000
+
+
+   Order
+      A 16-bit unsigned integer specifying the order in which the NAPTR
+      records MUST be processed to ensure the correct ordering of
+      rules.  Low numbers are processed before high numbers, and once a
+      NAPTR is found whose rule "matches" the target, the client MUST
+      NOT consider any NAPTRs with a higher value for order (except as
+      noted below for the Flags field).
+
+   Preference
+      A 16-bit unsigned integer that specifies the order in which NAPTR
+      records with equal "order" values SHOULD be processed, low
+      numbers being processed before high numbers.  This is similar to
+      the preference field in an MX record, and is used so domain
+      administrators can direct clients towards more capable hosts or
+      lighter weight protocols.  A client MAY look at records with
+      higher preference values if it has a good reason to do so such as
+      not understanding the preferred protocol or service.
+
+      The important difference between Order and Preference is that
+      once a match is found the client MUST NOT consider records with a
+      different Order but they MAY process records with the same Order
+      but different Preferences.  I.e., Preference is used to give weight
+      to rules that are considered the same from an authority
+      standpoint but not from a simple load balancing standpoint.
+
+   Flags
+      A <character-string> containing flags to control aspects of the
+      rewriting and interpretation of the fields in the record.  Flags
+      are single characters from the set [A-Z0-9].  The case of the
+      alphabetic characters is not significant.
+
+      At this time only four flags, "S", "A", "U", and "P", are
+      defined.  The "S", "A" and "U" flags denote a terminal lookup.
+      This means that this NAPTR record is the last one and that the
+      flag determines what the next stage should be.  The "S" flag
+      means that the next lookup should be for SRV records [4].  See
+      Section 5 for additional information on how NAPTR uses the SRV
+      record type.  "A" means that the next lookup should be for either
+      an A, AAAA, or A6 record.  The "U" flag means that the next step
+      is not a DNS lookup but that the output of the Regexp field is an
+      URI that adheres to the 'absoluteURI' production found in the
+      ABNF of RFC 2396 [9].  Since there may be applications that use
+      NAPTR to also lookup aspects of URIs, implementors should be
+      aware that this may cause loop conditions and should act
+      accordingly.
+
+
+
+
+
+
+Mealling & Daniel           Standards Track                     [Page 4]
+
+RFC 2915                      NAPTR DNS RR                September 2000
+
+
+      The "P" flag says that the remainder of the application side
+      algorithm shall be carried out in a Protocol-specific fashion.
+      The new set of rules is identified by the Protocol specified in
+      the Services field.  The record that contains the 'P' flag is the
+      last record that is interpreted by the rules specified in this
+      document.  The new rules are dependent on the application for
+      which they are being used and the protocol specified.  For
+      example, if the application is a URI RDS and the protocol is WIRE
+      then the new set of rules are governed by the algorithms
+      surrounding the WIRE HTTP specification and not this document.
+
+      The remaining alphabetic flags are reserved for future versions
+      of the NAPTR specification.  The numeric flags may be used for
+      local experimentation.  The S, A, U and P flags are all mutually
+      exclusive, and resolution libraries MAY signal an error if more
+      than one is given.  (Experimental code and code for assisting in
+      the creation of NAPTRs would be more likely to signal such an
+      error than a client such as a browser).  It is anticipated that
+      multiple flags will be allowed in the future, so implementers
+      MUST NOT assume that the flags field can only contain 0 or 1
+      characters.  Finally, if a client encounters a record with an
+      unknown flag, it MUST ignore it and move to the next record.  This
+      test takes precedence even over the "order" field.  Since flags
+      can control the interpretation placed on fields, a novel flag
+      might change the interpretation of the regexp and/or replacement
+      fields such that it is impossible to determine if a record
+      matched a given target.
+
+      The "S", "A", and "U"  flags are called 'terminal' flags since
+      they halt the looping rewrite algorithm.  If those flags are not
+      present, clients may assume that another NAPTR RR exists at the
+      domain name produced by the current rewrite rule.  Since the "P"
+      flag specifies a new algorithm, it may or may not be 'terminal'.
+      Thus, the client cannot assume that another NAPTR exists since
+      this case is determined elsewhere.
+
+      DNS servers MAY interpret these flags and values and use that
+      information to include appropriate SRV and A,AAAA, or A6 records
+      in the additional information portion of the DNS packet.  Clients
+      are encouraged to check for additional information but are not
+      required to do so.
+
+   Service
+      Specifies the service(s) available down this rewrite path.  It may
+      also specify the particular protocol that is used to talk with a
+      service.  A protocol MUST be specified if the flags field states
+      that the NAPTR is terminal.  If a protocol is specified, but the
+      flags field does not state that the NAPTR is terminal, the next
+
+
+
+Mealling & Daniel           Standards Track                     [Page 5]
+
+RFC 2915                      NAPTR DNS RR                September 2000
+
+
+      lookup MUST be for a NAPTR.  The client MAY choose not to perform
+      the next lookup if the protocol is unknown, but that behavior
+      MUST NOT be relied upon.
+
+      The service field may take any of the values below (using the
+      Augmented BNF of RFC 2234 [5]):
+
+                 service_field = [ [protocol] *("+" rs)]
+                 protocol      = ALPHA *31ALPHANUM
+                 rs            = ALPHA *31ALPHANUM
+                 ; The protocol and rs fields are limited to 32
+                 ; characters and must start with an alphabetic.
+
+      For example, an optional protocol specification followed by 0 or
+      more resolution services.  Each resolution service is indicated by
+      an initial '+' character.
+
+      Note that the empty string is also a valid service field.  This
+      will typically be seen at the beginning of a series of rules,
+      when it is impossible to know what services and protocols will be
+      offered by a particular service.
+
+      The actual format of the service request and response will be
+      determined by the resolution protocol, and is the subject for
+      other documents.  Protocols need not offer all services.  The
+      labels for service requests shall be formed from the set of
+      characters [A-Z0-9].  The case of the alphabetic characters is
+      not significant.
+
+      The list of "valid" protocols for any given NAPTR record is any
+      protocol that implements some or all of the services defined for
+      a NAPTR application.  Currently, THTTP [6] is the only protocol
+      that is known to make that claim at the time of publication.  Any
+      other protocol that is to be used must have documentation
+      specifying:
+
+      *  how it implements the services of the application
+
+      *  how it is to appear in the NAPTR record (i.e., the string id
+         of the protocol)
+
+      The list of valid Resolution Services is defined by the documents
+      that specify individual NAPTR based applications.
+
+      It is worth noting that the interpretation of this field is
+      subject to being changed by new flags, and that the current
+      specification is oriented towards telling clients how to talk
+      with a URN resolver.
+
+
+
+Mealling & Daniel           Standards Track                     [Page 6]
+
+RFC 2915                      NAPTR DNS RR                September 2000
+
+
+   Regexp
+      A STRING containing a substitution expression that is applied to
+      the original string held by the client in order to construct the
+      next domain name to lookup.  The grammar of the substitution
+      expression is given in the next section.
+
+      The regular expressions MUST NOT be used in a cumulative fashion,
+      that is, they should only be applied to the original string held
+      by the client, never to the domain name produced by a previous
+      NAPTR rewrite.  The latter is tempting in some applications but
+      experience has shown such use to be extremely fault sensitive,
+      very error prone, and extremely difficult to debug.
+
+   Replacement
+      The next NAME to query for NAPTR, SRV, or address records
+      depending on the value of the flags field.  This MUST be a fully
+      qualified domain-name. Unless and until permitted by future
+      standards action, name compression is not to be used for this
+      field.
+
+3. Substitution Expression Grammar
+
+   The content of the regexp field is a substitution expression.  True
+   sed(1) and Perl style substitution expressions are not appropriate
+   for use in this application for a variety of reasons stemming from
+   internationalization requirements and backref limitations, therefore
+   the contents of the regexp field MUST follow the grammar below:
+
+subst_expr   = delim-char  ere  delim-char  repl  delim-char  *flags
+delim-char   = "/" / "!" / ... <Any non-digit or non-flag character
+               other than backslash '\'. All occurances of a delim_char
+               in a subst_expr must be the same character.>
+ere          = POSIX Extended Regular Expression
+repl         = 1 * ( OCTET /  backref )
+backref      = "\" 1POS_DIGIT
+flags        = "i"
+POS_DIGIT    = %x31-39                 ; 0 is not an allowed backref
+
+   The definition of a POSIX Extended Regular Expression can be found in
+   [8], section 2.8.4.
+
+   The result of applying the substitution expression to the original
+   URI MUST result in either a string that obeys the syntax for DNS
+   domain-names [1] or a URI [9] if the Flags field contains a 'u'.
+   Since it is possible for the regexp field to be improperly specified,
+   such that a non-conforming domain-name can be constructed, client
+   software SHOULD verify that the result is a legal DNS domain-name
+   before making queries on it.
+
+
+
+Mealling & Daniel           Standards Track                     [Page 7]
+
+RFC 2915                      NAPTR DNS RR                September 2000
+
+
+   Backref expressions in the repl portion of the substitution
+   expression are replaced by the (possibly empty) string of characters
+   enclosed by '(' and ')' in the ERE portion of the substitution
+   expression. N is a single digit from 1 through 9, inclusive.  It
+   specifies the N'th backref expression, the one that begins with the
+   N'th '(' and continues to the matching ')'.  For example, the ERE
+
+                            (A(B(C)DE)(F)G)
+
+         has backref expressions:
+
+                            \1  = ABCDEFG
+                            \2  = BCDE
+                            \3  = C
+                            \4  = F
+                            \5..\9  = error - no matching subexpression
+
+   The "i" flag indicates that the ERE matching SHALL be performed in a
+   case-insensitive fashion. Furthermore, any backref replacements MAY
+   be normalized to lower case when the "i" flag is given.
+
+   The first character in the substitution expression shall be used as
+   the character that delimits the components of the substitution
+   expression.  There must be exactly three non-escaped occurrences of
+   the delimiter character in a substitution expression.  Since escaped
+   occurrences of the delimiter character will be interpreted as
+   occurrences of that character, digits MUST NOT be used as delimiters.
+   Backrefs would be confused with literal digits were this allowed.
+   Similarly, if flags are specified in the substitution expression, the
+   delimiter character must not also be a flag character.
+
+4. The Basic NAPTR Algorithm
+
+   The behavior and meaning of the flags and services assume an
+   algorithm where the output of one rewrite is a new key that points to
+   another rule.  This looping algorithm allows NAPTR records to
+   incrementally specify a complete rule.  These incremental rules can
+   be delegated which allows other entities to specify rules so that one
+   entity does not need to understand _all_ rules.
+
+   The algorithm starts with a string and some known key (domain).
+   NAPTR records for this key are retrieved, those with unknown Flags or
+   inappropriate Services are discarded and the remaining records are
+   sorted by their Order field.  Within each value of Order, the records
+   are further sorted by the Preferences field.
+
+   The records are examined in sorted order until a matching record is
+   found.  A record is considered a match iff:
+
+
+
+Mealling & Daniel           Standards Track                     [Page 8]
+
+RFC 2915                      NAPTR DNS RR                September 2000
+
+
+   o  it has a Replacement field value instead of a Regexp field value.
+
+   o  or the Regexp field matches the string held by the client.
+
+   The first match MUST be the match that is used.  Once a match is
+   found, the Services field is examined for whether or not this rule
+   advances toward the desired result.  If so, the rule is applied to
+   the target string.  If not, the process halts.  The domain that
+   results from the regular expression is then used as the domain of the
+   next loop through the NAPTR algorithm.  Note that the same target
+   string is used throughout the algorithm.
+
+   This looping is extremely important since it is the method by which
+   complex rules are broken down into manageable delegated chunks.  The
+   flags fields simply determine at which point the looping should stop
+   (or other specialized behavior).
+
+   Since flags are valid at any level of the algorithm, the degenerative
+   case is to never loop but to look up the NAPTR and then stop.  In
+   many specialized cases this is all that is needed.  Implementors
+   should be aware that the degenerative case should not become the
+   common case.
+
+5. Concerning How NAPTR Uses SRV Records
+
+   When the SRV record type was originally specified it assumed that the
+   client did not know the specific domain-name before hand.  The client
+   would construct a domain-name more in the form of a question than the
+   usual case of knowing ahead of time that the domain-name should
+   exist.  I.e., if the client wants to know if there is a TCP based
+   HTTP server running at a particular domain, the client would
+   construct the domain-name _http._tcp.somedomain.com and ask the DNS
+   if that records exists. The underscores are used to avoid collisions
+   with potentially 'real' domain-names.
+
+   In the case of NAPTR, the actual domain-name is specified by the
+   various fields in the NAPTR record.  In this case the client isn't
+   asking a question but is instead attempting to get at information
+   that it has been told exists in an SRV record at that particular
+   domain-name.  While this usage of SRV is slightly different than the
+   SRV authors originally intended it does not break any of the
+   assumptions concerning what SRV contains.  Also, since the NAPTR
+   explicitly spells out the domain-name for which an SRV exists, that
+   domain-name MUST be used in SRV queries with NO transformations.  Any
+   given NAPTR record may result in a domain-name to be used for SRV
+   queries that may or may not contain the SRV standardized underscore
+
+
+
+
+
+Mealling & Daniel           Standards Track                     [Page 9]
+
+RFC 2915                      NAPTR DNS RR                September 2000
+
+
+   characters.  NAPTR applications that make use of SRV MUST NOT attempt
+   to understand these domains or use them according to how the SRV
+   specification structures its query domains.
+
+6. Application Specifications
+
+   It should be noted that the NAPTR algorithm is the basic assumption
+   about how NAPTR works.  The reasons for the rewrite and the expected
+   output and its use are specified by documents that define what
+   applications the NAPTR record and algorithm are used for.  Any
+   document that defines such an application must define the following:
+
+   o  The first known domain-name or how to build it
+
+   o  The valid Services and Protocols
+
+   o  What the expected use is for the output of the last rewrite
+
+   o  The validity and/or behavior of any 'P' flag protocols.
+
+   o  The general semantics surrounding why and how NAPTR and its
+      algorithm are being used.
+
+7. Examples
+
+   NOTE: These are examples only.  They are taken from ongoing work and
+   may not represent the end result of that work. They are here for
+   pedagogical reasons only.
+
+7.1 Example 1
+
+   NAPTR was originally specified for use with the a Uniform Resource
+   Name Resolver Discovery System.  This example details how a
+   particular URN would use the NAPTR record to find a resolver service.
+
+   Consider a URN namespace based on MIME Content-Ids.  The URN might
+   look like this:
+
+      urn:cid:39CB83F7.A8450130@fake.gatech.edu
+
+   (Note that this example is chosen for pedagogical purposes, and does
+   not conform to the CID URL scheme.)
+
+   The first step in the resolution process is to find out about the CID
+   namespace.  The namespace identifier [3], 'cid', is extracted from
+   the URN, prepended to urn.arpa. 'cid.urn.arpa' then becomes the first
+   'known' key in the NAPTR algorithm.  The NAPTR records for
+   cid.urn.arpa looked up and return a single record:
+
+
+
+Mealling & Daniel           Standards Track                    [Page 10]
+
+RFC 2915                      NAPTR DNS RR                September 2000
+
+
+   cid.urn.arpa.
+   ;;       order pref flags service        regexp           replacement
+   IN NAPTR 100   10   ""  ""  "/urn:cid:.+@([^\.]+\.)(.*)$/\2/i"    .
+
+   There is only one NAPTR response, so ordering the responses is not a
+   problem.  The replacement field is empty, so the pattern provided in
+   the regexp field is used.  We apply that regexp to the entire URN to
+   see if it matches, which it does.  The \2 part of the substitution
+   expression returns the string "gatech.edu".  Since the flags field
+   does not contain "s" or "a", the lookup is not terminal and our next
+   probe to DNS is for more NAPTR records where the new domain is '
+   gatech.edu' and the string is the same string as before.
+
+   Note that the rule does not extract the full domain name from the
+   CID, instead it assumes the CID comes from a host and extracts its
+   domain.  While all hosts, such as mordred, could have their very own
+   NAPTR, maintaining those records for all the machines at a site as
+   large as Georgia Tech would be an intolerable burden.  Wildcards are
+   not appropriate here since they only return results when there is no
+   exactly matching names already in the system.
+
+   The record returned from the query on "gatech.edu" might look like:
+
+;;       order pref flags service           regexp  replacement
+ IN NAPTR 100  50  "s"  "z3950+I2L+I2C"     ""  _z3950._tcp.gatech.edu.
+ IN NAPTR 100  50  "s"  "rcds+I2C"          ""  _rcds._udp.gatech.edu.
+ IN NAPTR 100  50  "s"  "http+I2L+I2C+I2R"  ""  _http._tcp.gatech.edu.
+
+   Continuing with the example, note that the values of the order and
+   preference fields are equal in all records, so the client is free to
+   pick any record.  The flags field tells us that these are the last
+   NAPTR patterns we should see, and after the rewrite (a simple
+   replacement in this case) we should look up SRV records to get
+   information on the hosts that can provide the necessary service.
+
+   Assuming we prefer the Z39.50 protocol, our lookup might return:
+
+ ;;                        Pref Weight   Port Target
+ _z3950._tcp.gatech.edu. IN SRV 0    0      1000 z3950.gatech.edu.
+                         IN SRV 0    0      1000 z3950.cc.gatech.edu.
+                         IN SRV 0    0      1000 z3950.uga.edu.
+
+   telling us three hosts that could actually do the resolution, and
+   giving us the port we should use to talk to their Z39.50 server.
+
+   Recall that the regular expression used \2 to extract a domain name
+   from the CID, and \. for matching the literal '.' characters
+   separating the domain name components. Since '\' is the escape
+
+
+
+Mealling & Daniel           Standards Track                    [Page 11]
+
+RFC 2915                      NAPTR DNS RR                September 2000
+
+
+   character, literal occurances of a backslash must be escaped by
+   another backslash.  For the case of the cid.urn.arpa record above,
+   the regular expression entered into the master file should be
+   "/urn:cid:.+@([^\\.]+\\.)(.*)$/\\2/i".  When the client code actually
+   receives the record, the pattern will have been converted to
+   "/urn:cid:.+@([^\.]+\.)(.*)$/\2/i".
+
+7.2 Example 2
+
+   Even if URN systems were in place now, there would still be a
+   tremendous number of URLs.  It should be possible to develop a URN
+   resolution system that can also provide location independence for
+   those URLs.  This is related to the requirement that URNs be able to
+   grandfather in names from other naming systems, such as ISO Formal
+   Public Identifiers, Library of Congress Call Numbers, ISBNs, ISSNs,
+   etc.
+
+   The NAPTR RR could also be used for URLs that have already been
+   assigned.  Assume we have the URL for a very popular piece of
+   software that the publisher wishes to mirror at multiple sites around
+   the world:
+
+   Using the rules specified for this application we extract the prefix,
+   "http", and lookup NAPTR records for http.uri.arpa.  This might
+   return a record of the form
+
+     http.uri.arpa. IN NAPTR
+     ;;  order   pref flags service      regexp             replacement
+          100     90   ""      ""   "!http://([^/:]+)!\1!i"       .
+
+   This expression returns everything after the first double slash and
+   before the next slash or colon.  (We use the '!' character to delimit
+   the parts of the substitution expression.  Otherwise we would have to
+   use backslashes to escape the forward slashes and would have a regexp
+   in the zone file that looked like "/http:\\/\\/([^\\/:]+)/\\1/i".).
+
+   Applying this pattern to the URL extracts "www.foo.com".  Looking up
+   NAPTR records for that might return:
+
+     www.foo.com.
+     ;;       order pref flags   service  regexp     replacement
+      IN NAPTR 100  100  "s"   "http+I2R"   ""    _http._tcp.foo.com.
+      IN NAPTR 100  100  "s"   "ftp+I2R"    ""    _ftp._tcp.foo.com.
+
+   Looking up SRV records for http.tcp.foo.com would return information
+   on the hosts that foo.com has designated to be its mirror sites.  The
+   client can then pick one for the user.
+
+
+
+
+Mealling & Daniel           Standards Track                    [Page 12]
+
+RFC 2915                      NAPTR DNS RR                September 2000
+
+
+7.3 Example 3
+
+   A non-URI example is the ENUM application which uses a NAPTR record
+   to map an e.164 telephone number to a URI.  In order to convert the
+   phone number to a domain name for the first iteration all characters
+   other than digits are removed from the the telephone number, the
+   entire number is inverted, periods are put between each digit and the
+   string ".e164.arpa" is put on the left-hand side.  For example, the
+   E.164 phone number "+1-770-555-1212" converted to a domain-name it
+   would be "2.1.2.1.5.5.5.0.7.7.1.e164.arpa."
+
+   For this example telephone number we might get back the following
+   NAPTR records:
+
+$ORIGIN 2.1.2.1.5.5.5.0.7.7.1.e164.arpa.
+ IN NAPTR 100 10 "u" "sip+E2U"  "!^.*$!sip:information@tele2.se!"     .
+ IN NAPTR 102 10 "u" "mailto+E2U" "!^.*$!mailto:information@tele2.se!"  .
+
+   This application uses the same 'u' flag as the URI Resolution
+   application. This flag states that the Rule is terminal and that the
+   output is a URI which contains the information needed to contact that
+   telephone service.  ENUM also uses the same format for its Service
+   field except that it defines the 'E2U' service instead of the 'I2*'
+   services that URI resolution uses.  The example above states that the
+   available protocols used to access that telephone's service are
+   either the Session Initiation Protocol or SMTP mail.
+
+8. DNS Packet Format
+
+         The packet format for the NAPTR record is:
+
+                                          1  1  1  1  1  1
+            0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
+          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+          |                     ORDER                     |
+          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+          |                   PREFERENCE                  |
+          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+          /                     FLAGS                     /
+          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+          /                   SERVICES                    /
+          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+          /                    REGEXP                     /
+          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+          /                  REPLACEMENT                  /
+          /                                               /
+          +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+
+
+
+Mealling & Daniel           Standards Track                    [Page 13]
+
+RFC 2915                      NAPTR DNS RR                September 2000
+
+
+    where:
+
+   FLAGS A <character-string> which contains various flags.
+
+   SERVICES A <character-string> which contains protocol and service
+      identifiers.
+
+   REGEXP A <character-string> which contains a regular expression.
+
+   REPLACEMENT A <domain-name> which specifies the new value in the
+      case where the regular expression is a simple replacement
+      operation.
+
+   <character-string> and <domain-name> as used here are defined in
+   RFC1035 [1].
+
+9. Master File Format
+
+   The master file format follows the standard rules in RFC-1035 [1].
+   Order and preference, being 16-bit unsigned integers, shall be an
+   integer between 0 and 65535.  The Flags and Services and Regexp
+   fields are all quoted <character-string>s.  Since the Regexp field
+   can contain numerous backslashes and thus should be treated with
+   care.  See Section 10 for how to correctly enter and escape the
+   regular expression.
+
+10. Advice for DNS Administrators
+
+   Beware of regular expressions.  Not only are they difficult to get
+   correct on their own, but there is the previously mentioned
+   interaction with DNS.  Any backslashes in a regexp must be entered
+   twice in a zone file in order to appear once in a query response.
+   More seriously, the need for double backslashes has probably not been
+   tested by all implementors of DNS servers.
+
+   The "a" flag allows the next lookup to be for address records (A,
+   AAAA, A6) rather than SRV records.  Since there is no place for a
+   port specification in the NAPTR record, when the "A" flag is used the
+   specified protocol must be running on its default port.
+
+   The URN Syntax draft defines a canonical form for each URN, which
+   requires %encoding characters outside a limited repertoire.  The
+   regular expressions MUST be written to operate on that canonical
+   form.  Since international character sets will end up with extensive
+   use of %encoded characters, regular expressions operating on them
+   will be essentially impossible to read or write by hand.
+
+
+
+
+
+Mealling & Daniel           Standards Track                    [Page 14]
+
+RFC 2915                      NAPTR DNS RR                September 2000
+
+
+11. Notes
+
+   o  A client MUST process multiple NAPTR records in the order
+      specified by the "order" field, it MUST NOT simply use the first
+      record that provides a known protocol and service combination.
+
+   o  When multiple RRs have the same "order" and all other criteria
+      being equal, the client should use the value of the preference
+      field to select the next NAPTR to consider.  However, because it
+      will often be the case where preferred protocols or services
+      exist, clients may use this additional criteria to sort
+      the records.
+
+   o  If the lookup after a rewrite fails, clients are strongly
+      encouraged to report a failure, rather than backing up to pursue
+      other rewrite paths.
+
+   o  Note that SRV RRs impose additional requirements on clients.
+
+12. IANA Considerations
+
+   The only registration function that impacts the IANA is for the
+   values that are standardized for the Services and Flags fields.  To
+   extend the valid values of the Flags field beyond what is specified
+   in this document requires a published specification that is approved
+   by the IESG.
+
+   The values for the Services field will be determined by the
+   application that makes use of the NAPTR record.  Those values must be
+   specified in a published specification and approved by the IESG.
+
+13. Security Considerations
+
+   The interactions with DNSSEC are currently being studied.  It is
+   expected that NAPTR records will be signed with SIG records once the
+   DNSSEC work is deployed.
+
+   The rewrite rules make identifiers from other namespaces subject to
+   the same attacks as normal domain names.  Since they have not been
+   easily resolvable before, this may or may not be considered a
+   problem.
+
+   Regular expressions should be checked for sanity, not blindly passed
+   to something like PERL.
+
+   This document has discussed a way of locating a service, but has not
+   discussed any detail of how the communication with that service takes
+   place.  There are significant security considerations attached to the
+
+
+
+Mealling & Daniel           Standards Track                    [Page 15]
+
+RFC 2915                      NAPTR DNS RR                September 2000
+
+
+   communication with a service.  Those considerations are outside the
+   scope of this document, and must be addressed by the specifications
+   for particular communication protocols.
+
+14. Acknowledgments
+
+   The editors would like to thank Keith Moore for all his consultations
+   during the development of this memo.  We would also like to thank
+   Paul Vixie for his assistance in debugging our implementation, and
+   his answers on our questions.  Finally, we would like to acknowledge
+   our enormous intellectual debt to the participants in the Knoxville
+   series of meetings, as well as to the participants in the URI and URN
+   working groups.
+
+References
+
+   [1]  Mockapetris, P., "Domain names - implementation and
+        specification", STD 13, RFC 1035, November 1987.
+
+   [2]  Mockapetris, P., "Domain names - concepts and facilities", STD
+        13, RFC 1034, November 1987.
+
+   [3]  Moats, R., "URN Syntax", RFC 2141, May 1997.
+
+   [4]  Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
+        specifying the location of services (DNS SRV)", RFC 2782,
+        February 2000.
+
+   [5]  Crocker, D., "Augmented BNF for Syntax Specifications: ABNF",
+        RFC 2234, November 1997.
+
+   [6]  Daniel, R., "A Trivial Convention for using HTTP in URN
+        Resolution", RFC 2169, June 1997.
+
+   [7]  Daniel, R. and M. Mealling, "Resolution of Uniform Resource
+        Identifiers using the Domain Name System", RFC 2168, June 1997.
+
+   [8]  IEEE, "IEEE Standard for Information Technology - Portable
+        Operating System Interface (POSIX) - Part 2: Shell and Utilities
+        (Vol. 1)", IEEE Std 1003.2-1992, January 1993.
+
+   [9]  Berners-Lee, T., Fielding, R.T. and L. Masinter, "Uniform
+        Resource Identifiers (URI): Generic Syntax", RFC 2396, August
+        1998.
+
+
+
+
+
+
+
+Mealling & Daniel           Standards Track                    [Page 16]
+
+RFC 2915                      NAPTR DNS RR                September 2000
+
+
+Authors' Addresses
+
+   Michael Mealling
+   Network Solutions, Inc.
+   505 Huntmar Park Drive
+   Herndon, VA  22070
+   US
+
+   Phone: +1 770 921 2251
+   EMail: michaelm@netsol.com
+   URI:   http://www.netsol.com
+
+
+   Ron Daniel
+   DATAFUSION, Inc.
+   139 Townsend Street, Ste. 100
+   San Francisco, CA  94107
+   US
+
+   Phone: +1 415 222 0100
+   EMail: rdaniel@datafusion.net
+   URI:   http://www.datafusion.net
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mealling & Daniel           Standards Track                    [Page 17]
+
+RFC 2915                      NAPTR DNS RR                September 2000
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2000).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mealling & Daniel           Standards Track                    [Page 18]
+
diff --git a/doc/rfc/rfc2929.txt b/doc/rfc/rfc2929.txt
new file mode 100644
index 0000000..f055968
--- /dev/null
+++ b/doc/rfc/rfc2929.txt
@@ -0,0 +1,675 @@
+
+
+
+
+
+
+Network Working Group                                   D. Eastlake, 3rd
+Request for Comments: 2929                                      Motorola
+BCP: 42                                              E. Brunner-Williams
+Category: Best Current Practice                                   Engage
+                                                              B. Manning
+                                                                     ISI
+                                                          September 2000
+
+              Domain Name System (DNS) IANA Considerations
+
+Status of this Memo
+
+   This document specifies an Internet Best Current Practices for the
+   Internet Community, and requests discussion and suggestions for
+   improvements.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2000).  All Rights Reserved.
+
+Abstract
+
+   Internet Assigned Number Authority (IANA) parameter assignment
+   considerations are given for the allocation of Domain Name System
+   (DNS) classes, Resource Record (RR) types, operation codes, error
+   codes, etc.
+
+Table of Contents
+
+   1. Introduction.................................................  2
+   2. DNS Query/Response Headers...................................  2
+   2.1 One Spare Bit?..............................................  3
+   2.2 Opcode Assignment...........................................  3
+   2.3 RCODE Assignment............................................  4
+   3. DNS Resource Records.........................................  5
+   3.1 RR TYPE IANA Considerations.................................  6
+   3.1.1 Special Note on the OPT RR................................  7
+   3.2 RR CLASS IANA Considerations................................  7
+   3.3 RR NAME Considerations......................................  8
+   4. Security Considerations......................................  9
+   References......................................................  9
+   Authors' Addresses.............................................. 11
+   Full Copyright Statement........................................ 12
+
+
+
+
+
+
+
+
+Eastlake, et al.         Best Current Practice                  [Page 1]
+
+RFC 2929                DNS IANA Considerations           September 2000
+
+
+1. Introduction
+
+   The Domain Name System (DNS) provides replicated distributed secure
+   hierarchical databases which hierarchically store "resource records"
+   (RRs) under domain names.
+
+   This data is structured into CLASSes and zones which can be
+   independently maintained.  See [RFC 1034, 1035, 2136, 2181, 2535]
+   familiarity with which is assumed.
+
+   This document covers, either directly or by reference, general IANA
+   parameter assignment considerations applying across DNS query and
+   response headers and all RRs.  There may be additional IANA
+   considerations that apply to only a particular RR type or
+   query/response opcode.  See the specific RFC defining that RR type or
+   query/response opcode for such considerations if they have been
+   defined.
+
+   IANA currently maintains a web page of DNS parameters.  See
+   <http://www.iana.org/numbers.htm>.
+
+   "IETF Standards Action", "IETF Consensus", "Specification Required",
+   and "Private Use" are as defined in [RFC 2434].
+
+2. DNS Query/Response Headers
+
+   The header for DNS queries and responses contains field/bits in the
+   following diagram taken from [RFC 2136, 2535]:
+
+                                           1  1  1  1  1  1
+             0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
+            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+            |                      ID                       |
+            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+            |QR|   Opcode  |AA|TC|RD|RA| Z|AD|CD|   RCODE   |
+            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+            |                QDCOUNT/ZOCOUNT                |
+            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+            |                ANCOUNT/PRCOUNT                |
+            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+            |                NSCOUNT/UPCOUNT                |
+            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+            |                    ARCOUNT                    |
+            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+   The ID field identifies the query and is echoed in the response so
+   they can be matched.
+
+
+
+
+Eastlake, et al.         Best Current Practice                  [Page 2]
+
+RFC 2929                DNS IANA Considerations           September 2000
+
+
+   The QR bit indicates whether the header is for a query or a response.
+
+   The AA, TC, RD, RA, AD, and CD bits are each theoretically meaningful
+   only in queries or only in responses, depending on the bit.  However,
+   many DNS implementations copy the query header as the initial value
+   of the response header without clearing bits.  Thus any attempt to
+   use a "query" bit with a different meaning in a response or to define
+   a query meaning for a "response" bit is dangerous given existing
+   implementation.  Such meanings may only be assigned by an IETF
+   Standards Action.
+
+   The unsigned fields query count (QDCOUNT), answer count (ANCOUNT),
+   authority count (NSCOUNT), and additional information count (ARCOUNT)
+   express the number of records in each section for all opcodes except
+   Update.  These fields have the same structure and data type for
+   Update but are instead the counts for the zone (ZOCOUNT),
+   prerequisite (PRCOUNT), update (UPCOUNT), and additional information
+   (ARCOUNT) sections.
+
+2.1 One Spare Bit?
+
+   There have been ancient DNS implementations for which the Z bit being
+   on in a query meant that only a response from the primary server for
+   a zone is acceptable.  It is believed that current DNS
+   implementations ignore this bit.
+
+   Assigning a meaning to the Z bit requires an IETF Standards Action.
+
+2.2 Opcode Assignment
+
+   New OpCode assignments require an IETF Standards Action.
+
+   Currently DNS OpCodes are assigned as follows:
+
+       OpCode Name                      Reference
+
+        0     Query                     [RFC 1035]
+        1     IQuery  (Inverse Query)   [RFC 1035]
+        2     Status                    [RFC 1035]
+        3     available for assignment
+        4     Notify                    [RFC 1996]
+        5     Update                    [RFC 2136]
+       6-15   available for assignment
+
+
+
+
+
+
+
+
+Eastlake, et al.         Best Current Practice                  [Page 3]
+
+RFC 2929                DNS IANA Considerations           September 2000
+
+
+2.3 RCODE Assignment
+
+   It would appear from the DNS header above that only four bits of
+   RCODE, or response/error code are available.  However, RCODEs can
+   appear not only at the top level of a DNS response but also inside
+   OPT RRs [RFC 2671], TSIG RRs [RFC 2845], and TKEY RRs [RFC 2930].
+   The OPT RR provides an eight bit extension resulting in a 12 bit
+   RCODE field and the TSIG and TKEY RRs have a 16 bit RCODE field.
+
+   Error codes appearing in the DNS header and in these three RR types
+   all refer to the same error code space with the single exception of
+   error code 16 which has a different meaning in the OPT RR from its
+   meaning in other contexts.  See table below.
+
+   RCODE   Name    Description                        Reference
+   Decimal
+     Hexadecimal
+    0    NoError   No Error                           [RFC 1035]
+    1    FormErr   Format Error                       [RFC 1035]
+    2    ServFail  Server Failure                     [RFC 1035]
+    3    NXDomain  Non-Existent Domain                [RFC 1035]
+    4    NotImp    Not Implemented                    [RFC 1035]
+    5    Refused   Query Refused                      [RFC 1035]
+    6    YXDomain  Name Exists when it should not     [RFC 2136]
+    7    YXRRSet   RR Set Exists when it should not   [RFC 2136]
+    8    NXRRSet   RR Set that should exist does not  [RFC 2136]
+    9    NotAuth   Server Not Authoritative for zone  [RFC 2136]
+   10    NotZone   Name not contained in zone         [RFC 2136]
+   11-15           available for assignment
+   16    BADVERS   Bad OPT Version                    [RFC 2671]
+   16    BADSIG    TSIG Signature Failure             [RFC 2845]
+   17    BADKEY    Key not recognized                 [RFC 2845]
+   18    BADTIME   Signature out of time window       [RFC 2845]
+   19    BADMODE   Bad TKEY Mode                      [RFC 2930]
+   20    BADNAME   Duplicate key name                 [RFC 2930]
+   21    BADALG    Algorithm not supported            [RFC 2930]
+   22-3840         available for assignment
+     0x0016-0x0F00
+   3841-4095       Private Use
+     0x0F01-0x0FFF
+   4096-65535      available for assignment
+     0x1000-0xFFFF
+
+   Since it is important that RCODEs be understood for interoperability,
+   assignment of new RCODE listed above as "available for assignment"
+   requires an IETF Consensus.
+
+
+
+
+
+Eastlake, et al.         Best Current Practice                  [Page 4]
+
+RFC 2929                DNS IANA Considerations           September 2000
+
+
+3. DNS Resource Records
+
+   All RRs have the same top level format shown in the figure below
+   taken from [RFC 1035]:
+
+                                         1  1  1  1  1  1
+           0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
+         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+         |                                               |
+         /                                               /
+         /                      NAME                     /
+         |                                               |
+         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+         |                      TYPE                     |
+         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+         |                     CLASS                     |
+         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+         |                      TTL                      |
+         |                                               |
+         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+         |                   RDLENGTH                    |
+         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--|
+         /                     RDATA                     /
+         /                                               /
+         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+   NAME is an owner name, i.e., the name of the node to which this
+   resource record pertains.  NAMEs are specific to a CLASS as described
+   in section 3.2.  NAMEs consist of an ordered sequence of one or more
+   labels each of which has a label type [RFC 1035, 2671].
+
+   TYPE is a two octet unsigned integer containing one of the RR TYPE
+   codes.  See section 3.1.
+
+   CLASS is a two octet unsigned integer containing one of the RR CLASS
+   codes.  See section 3.2.
+
+   TTL is a four octet (32 bit) bit unsigned integer that specifies the
+   number of seconds that the resource record may be cached before the
+   source of the information should again be consulted.  Zero is
+   interpreted to mean that the RR can only be used for the transaction
+   in progress.
+
+   RDLENGTH is an unsigned 16 bit integer that specifies the length in
+   octets of the RDATA field.
+
+
+
+
+
+
+Eastlake, et al.         Best Current Practice                  [Page 5]
+
+RFC 2929                DNS IANA Considerations           September 2000
+
+
+   RDATA is a variable length string of octets that constitutes the
+   resource.  The format of this information varies according to the
+   TYPE and in some cases the CLASS of the resource record.
+
+3.1 RR TYPE IANA Considerations
+
+   There are three subcategories of RR TYPE numbers: data TYPEs, QTYPEs,
+   and MetaTYPEs.
+
+   Data TYPEs are the primary means of storing data.  QTYPES can only be
+   used in queries.  Meta-TYPEs designate transient data associated with
+   an particular DNS message and in some cases can also be used in
+   queries.  Thus far, data TYPEs have been assigned from 1 upwards plus
+   the block from 100 through 103 while Q and Meta Types have been
+   assigned from 255 downwards (except for the OPT Meta-RR which is
+   assigned TYPE 41).  There have been DNS implementations which made
+   caching decisions based on the top bit of the bottom byte of the RR
+   TYPE.
+
+   There are currently three Meta-TYPEs assigned: OPT [RFC 2671], TSIG
+   [RFC 2845], and TKEY [RFC 2930].
+
+   There are currently five QTYPEs assigned: * (all), MAILA, MAILB,
+   AXFR, and IXFR.
+
+   Considerations for the allocation of new RR TYPEs are as follows:
+
+     Decimal
+   Hexadecimal
+
+     0
+   0x0000 - TYPE zero is used as a special indicator for the SIG RR [RFC
+          2535] and in other circumstances and must never be allocated
+          for ordinary use.
+
+     1 - 127
+   0x0001 - 0x007F - remaining TYPEs in this range are assigned for data
+          TYPEs by IETF Consensus.
+
+     128 - 255
+   0x0080 - 0x00FF - remaining TYPEs in this rage are assigned for Q and
+          Meta TYPEs by IETF Consensus.
+
+     256 - 32767
+   0x0100 - 0x7FFF - assigned for data, Q, or Meta TYPE use by IETF
+          Consensus.
+
+
+
+
+
+Eastlake, et al.         Best Current Practice                  [Page 6]
+
+RFC 2929                DNS IANA Considerations           September 2000
+
+
+     32768 - 65279
+   0x8000 - 0xFEFF - Specification Required as defined in [RFC 2434].
+
+     65280 - 65535
+   0xFF00 - 0xFFFF - Private Use.
+
+3.1.1 Special Note on the OPT RR
+
+   The OPT (OPTion) RR, number 41, is specified in [RFC 2671].  Its
+   primary purpose is to extend the effective field size of various DNS
+   fields including RCODE, label type, flag bits, and RDATA size.  In
+   particular, for resolvers and servers that recognize it, it extends
+   the RCODE field from 4 to 12 bits.
+
+3.2 RR CLASS IANA Considerations
+
+   DNS CLASSes have been little used but constitute another dimension of
+   the DNS distributed database.  In particular, there is no necessary
+   relationship between the name space or root servers for one CLASS and
+   those for another CLASS.  The same name can have completely different
+   meanings in different CLASSes although the label types are the same
+   and the null label is usable only as root in every CLASS.  However,
+   as global networking and DNS have evolved, the IN, or Internet, CLASS
+   has dominated DNS use.
+
+   There are two subcategories of DNS CLASSes: normal data containing
+   classes and QCLASSes that are only meaningful in queries or updates.
+
+   The current CLASS assignments and considerations for future
+   assignments are as follows:
+
+     Decimal
+   Hexadecimal
+
+     0
+   0x0000 - assignment requires an IETF Standards Action.
+
+     1
+   0x0001 - Internet (IN).
+
+     2
+   0x0002 - available for assignment by IETF Consensus as a data CLASS.
+
+     3
+   0x0003 - Chaos (CH) [Moon 1981].
+
+     4
+   0x0004 - Hesiod (HS) [Dyer 1987].
+
+
+
+Eastlake, et al.         Best Current Practice                  [Page 7]
+
+RFC 2929                DNS IANA Considerations           September 2000
+
+
+     5 - 127
+   0x0005 - 0x007F - available for assignment by IETF Consensus as data
+          CLASSes only.
+
+     128 - 253
+   0x0080 - 0x00FD - available for assignment by IETF Consensus as
+          QCLASSes only.
+
+     254
+   0x00FE - QCLASS None [RFC 2136].
+
+     255
+   0x00FF - QCLASS Any [RFC 1035].
+
+     256 - 32767
+   0x0100 - 0x7FFF - assigned by IETF Consensus.
+
+     32768 - 65280
+   0x8000 - 0xFEFF - assigned based on Specification Required as defined
+          in [RFC 2434].
+
+     65280 - 65534
+   0xFF00 - 0xFFFE - Private Use.
+
+     65535
+   0xFFFF - can only be assigned by an IETF Standards Action.
+
+3.3 RR NAME Considerations
+
+   DNS NAMEs are sequences of labels [RFC 1035].  The last label in each
+   NAME is "ROOT" which is the zero length label.  By definition, the
+   null or ROOT label can not be used for any other NAME purpose.
+
+   At the present time, there are two categories of label types, data
+   labels and compression labels.  Compression labels are pointers to
+   data labels elsewhere within an RR or DNS message and are intended to
+   shorten the wire encoding of NAMEs.  The two existing data label
+   types are sometimes referred to as Text and Binary.  Text labels can,
+   in fact, include any octet value including zero octets but most
+   current uses involve only [US-ASCII].  For retrieval, Text labels are
+   defined to treat ASCII upper and lower case letter codes as matching.
+   Binary labels are bit sequences [RFC 2673].
+
+   IANA considerations for label types are given in [RFC 2671].
+
+
+
+
+
+
+
+Eastlake, et al.         Best Current Practice                  [Page 8]
+
+RFC 2929                DNS IANA Considerations           September 2000
+
+
+   NAMEs are local to a CLASS.  The Hesiod [Dyer 1987] and Chaos [Moon
+   1981] CLASSes are essentially for local use.  The IN or Internet
+   CLASS is thus the only DNS CLASS in global use on the Internet at
+   this time.
+
+   A somewhat dated description of name allocation in the IN Class is
+   given in [RFC 1591].  Some information on reserved top level domain
+   names is in Best Current Practice 32 [RFC 2606].
+
+4. Security Considerations
+
+   This document addresses IANA considerations in the allocation of
+   general DNS parameters, not security.  See [RFC 2535] for secure DNS
+   considerations.
+
+References
+
+   [Dyer 1987] Dyer, S., and F. Hsu, "Hesiod", Project Athena Technical
+               Plan - Name Service, April 1987,
+
+   [Moon 1981] D. Moon, "Chaosnet", A.I. Memo 628, Massachusetts
+               Institute of Technology Artificial Intelligence
+               Laboratory, June 1981.
+
+   [RFC 1034]  Mockapetris, P., "Domain Names - Concepts and
+               Facilities", STD 13, RFC 1034, November 1987.
+
+   [RFC 1035]  Mockapetris, P., "Domain Names - Implementation and
+               Specifications", STD 13, RFC 1035, November 1987.
+
+   [RFC 1591]  Postel, J., "Domain Name System Structure and
+               Delegation", RFC 1591, March 1994.
+
+   [RFC 1996]  Vixie, P., "A Mechanism for Prompt Notification of Zone
+               Changes (DNS NOTIFY)", RFC 1996, August 1996.
+
+   [RFC 2136]  Vixie, P., Thomson, S., Rekhter, Y. and J. Bound,
+               "Dynamic Updates in the Domain Name System (DNS UPDATE)",
+               RFC 2136, April 1997.
+
+   [RFC 2181]  Elz, R. and R. Bush, "Clarifications to the DNS
+               Specification", RFC 2181, July 1997.
+
+   [RFC 2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
+               IANA Considerations Section in RFCs", BCP 26, RFC 2434,
+               October 1998.
+
+
+
+
+
+Eastlake, et al.         Best Current Practice                  [Page 9]
+
+RFC 2929                DNS IANA Considerations           September 2000
+
+
+   [RFC 2535]  Eastlake, D., "Domain Name System Security Extensions",
+               RFC 2535, March 1999.
+
+   [RFC 2606]  Eastlake, D. and A. Panitz, "Reserved Top Level DNS
+               Names", RFC 2606, June 1999.
+
+   [RFC 2671]  Vixie, P., "Extension mechanisms for DNS (EDNS0)", RFC
+               2671, August 1999.
+
+   [RFC 2672]  Crawford, M., "Non-Terminal DNS Name Redirection", RFC
+               2672, August 1999.
+
+   [RFC 2673]  Crawford, M., "Binary Labels in the Domain Name System",
+               RFC 2673, August 1999.
+
+   [RFC 2845]  Vixie, P., Gudmundsson, O., Eastlake, D. and B.
+               Wellington, "Secret Key Transaction Authentication for
+               DNS (TSIG)", RFC 2845, May 2000.
+
+   [RFC 2930]  Eastlake, D., "Secret Key Establishment for DNS (TKEY
+               RR)", RFC 2930, September 2000.
+
+   [US-ASCII]  ANSI, "USA Standard Code for Information Interchange",
+               X3.4, American National Standards Institute: New York,
+               1968.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake, et al.         Best Current Practice                 [Page 10]
+
+RFC 2929                DNS IANA Considerations           September 2000
+
+
+Authors' Addresses
+
+   Donald E. Eastlake 3rd
+   Motorola
+   140 Forest Avenue
+   Hudson, MA 01749 USA
+
+   Phone: +1-978-562-2827 (h)
+          +1-508-261-5434 (w)
+   Fax:   +1-508-261-4447 (w)
+   EMail: Donald.Eastlake@motorola.com
+
+
+   Eric Brunner-Williams
+   Engage
+   100 Brickstone Square, 2nd Floor
+   Andover, MA 01810
+
+   Phone: +1-207-797-0525 (h)
+          +1-978-684-7796 (w)
+   Fax:   +1-978-684-3118
+   EMail: brunner@engage.com
+
+
+   Bill Manning
+   USC/ISI
+   4676 Admiralty Way, #1001
+   Marina del Rey, CA 90292 USA
+
+   Phone: +1-310-822-1511
+   EMail: bmanning@isi.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake, et al.         Best Current Practice                 [Page 11]
+
+RFC 2929                DNS IANA Considerations           September 2000
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2000).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake, et al.         Best Current Practice                 [Page 12]
+
diff --git a/doc/rfc/rfc2930.txt b/doc/rfc/rfc2930.txt
new file mode 100644
index 0000000..f99573d
--- /dev/null
+++ b/doc/rfc/rfc2930.txt
@@ -0,0 +1,899 @@
+
+
+
+
+
+
+Network Working Group                                   D. Eastlake, 3rd
+Request for Comments: 2930                                      Motorola
+Category: Standards Track                                 September 2000
+
+
+               Secret Key Establishment for DNS (TKEY RR)
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2000).  All Rights Reserved.
+
+Abstract
+
+   [RFC 2845] provides a means of authenticating Domain Name System
+   (DNS) queries and responses using shared secret keys via the
+   Transaction Signature (TSIG) resource record (RR).  However, it
+   provides no mechanism for setting up such keys other than manual
+   exchange. This document describes a Transaction Key (TKEY) RR that
+   can be used in a number of different modes to establish shared secret
+   keys between a DNS resolver and server.
+
+Acknowledgments
+
+   The comments and ideas of the following persons (listed in alphabetic
+   order) have been incorporated herein and are gratefully acknowledged:
+
+         Olafur Gudmundsson (TIS)
+
+         Stuart Kwan (Microsoft)
+
+         Ed Lewis (TIS)
+
+         Erik Nordmark (SUN)
+
+         Brian Wellington (Nominum)
+
+
+
+
+
+
+
+
+Eastlake                    Standards Track                     [Page 1]
+
+RFC 2930                    The DNS TKEY RR               September 2000
+
+
+Table of Contents
+
+   1. Introduction...............................................  2
+   1.1 Overview of Contents......................................  3
+   2. The TKEY Resource Record...................................  4
+   2.1 The Name Field............................................  4
+   2.2 The TTL Field.............................................  5
+   2.3 The Algorithm Field.......................................  5
+   2.4 The Inception and Expiration Fields.......................  5
+   2.5 The Mode Field............................................  5
+   2.6 The Error Field...........................................  6
+   2.7 The Key Size and Data Fields..............................  6
+   2.8 The Other Size and Data Fields............................  6
+   3. General TKEY Considerations................................  7
+   4. Exchange via Resolver Query................................  8
+   4.1 Query for Diffie-Hellman Exchanged Keying.................  8
+   4.2 Query for TKEY Deletion...................................  9
+   4.3 Query for GSS-API Establishment........................... 10
+   4.4 Query for Server Assigned Keying.......................... 10
+   4.5 Query for Resolver Assigned Keying........................ 11
+   5. Spontaneous Server Inclusion............................... 12
+   5.1 Spontaneous Server Key Deletion........................... 12
+   6. Methods of Encryption...................................... 12
+   7. IANA Considerations........................................ 13
+   8. Security Considerations.................................... 13
+   References.................................................... 14
+   Author's Address.............................................. 15
+   Full Copyright Statement...................................... 16
+
+1. Introduction
+
+   The Domain Name System (DNS) is a hierarchical, distributed, highly
+   available database used for bi-directional mapping between domain
+   names and addresses, for email routing, and for other information
+   [RFC 1034, 1035].  It has been extended to provide for public key
+   security and dynamic update [RFC 2535, RFC 2136].  Familiarity with
+   these RFCs is assumed.
+
+   [RFC 2845] provides a means of efficiently authenticating DNS
+   messages using shared secret keys via the TSIG resource record (RR)
+   but provides no mechanism for setting up such keys other than manual
+   exchange. This document specifies a TKEY RR that can be used in a
+   number of different modes to establish and delete such shared secret
+   keys between a DNS resolver and server.
+
+
+
+
+
+
+
+Eastlake                    Standards Track                     [Page 2]
+
+RFC 2930                    The DNS TKEY RR               September 2000
+
+
+   Note that TKEY established keying material and TSIGs that use it are
+   associated with DNS servers or resolvers.  They are not associated
+   with zones.  They may be used to authenticate queries and responses
+   but they do not provide zone based DNS data origin or denial
+   authentication [RFC 2535].
+
+   Certain modes of TKEY perform encryption which may affect their
+   export or import status for some countries.  The affected modes
+   specified in this document are the server assigned mode and the
+   resolver assigned mode.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC 2119].
+
+   In all cases herein, the term "resolver" includes that part of a
+   server which may make full and incremental [RFC 1995] zone transfer
+   queries, forwards recursive queries, etc.
+
+1.1 Overview of Contents
+
+   Section 2 below specifies the TKEY RR and provides a description of
+   and considerations for its constituent fields.
+
+   Section 3 describes general principles of operations with TKEY.
+
+   Section 4 discusses key agreement and deletion via DNS requests with
+   the Query opcode for RR type TKEY.  This method is applicable to all
+   currently defined TKEY modes, although in some cases it is not what
+   would intuitively be called a "query".
+
+   Section 5 discusses spontaneous inclusion of TKEY RRs in responses by
+   servers which is currently used only for key deletion.
+
+   Section 6 describes encryption methods for transmitting secret key
+   information. In this document these are used only for the server
+   assigned mode and the resolver assigned mode.
+
+   Section 7 covers IANA considerations in assignment of TKEY modes.
+
+   Finally, Section 8 provides the required security considerations
+   section.
+
+
+
+
+
+
+
+
+
+Eastlake                    Standards Track                     [Page 3]
+
+RFC 2930                    The DNS TKEY RR               September 2000
+
+
+2. The TKEY Resource Record
+
+   The TKEY resource record (RR) has the structure given below.  Its RR
+   type code is 249.
+
+      Field       Type         Comment
+      -----       ----         -------
+
+      NAME         domain      see description below
+      TTYPE        u_int16_t   TKEY = 249
+      CLASS        u_int16_t   ignored, SHOULD be 255 (ANY)
+      TTL          u_int32_t   ignored, SHOULD be zero
+      RDLEN        u_int16_t   size of RDATA
+      RDATA:
+       Algorithm:   domain
+       Inception:   u_int32_t
+       Expiration:  u_int32_t
+       Mode:        u_int16_t
+       Error:       u_int16_t
+       Key Size:    u_int16_t
+       Key Data:    octet-stream
+       Other Size:  u_int16_t
+       Other Data:  octet-stream  undefined by this specification
+
+2.1 The Name Field
+
+   The Name field relates to naming keys.  Its meaning differs somewhat
+   with mode and context as explained in subsequent sections.
+
+   At any DNS server or resolver only one octet string of keying
+   material may be in place for any particular key name.  An attempt to
+   establish another set of keying material at a server for an existing
+   name returns a BADNAME error.
+
+   For a TKEY with a non-root name appearing in a query, the TKEY RR
+   name SHOULD be a domain locally unique at the resolver, less than 128
+   octets long in wire encoding, and meaningful to the resolver to
+   assist in distinguishing keys and/or key agreement sessions.   For
+   TKEY(s) appearing in a response to a query, the TKEY RR name SHOULD
+   be a globally unique server assigned domain.
+
+   A reasonable key naming strategy is as follows:
+
+      If the key is generated as the result of a query with root as its
+      owner name, then the server SHOULD create a globally unique domain
+      name, to be the key name, by suffixing a pseudo-random [RFC 1750]
+      label with a domain name of the server.  For example
+      89n3mDgX072pp.server1.example.com.  If generation of a new
+
+
+
+Eastlake                    Standards Track                     [Page 4]
+
+RFC 2930                    The DNS TKEY RR               September 2000
+
+
+      pseudo-random name in each case is an excessive computation load
+      or entropy drain, a serial number prefix can be added to a fixed
+      pseudo-random name generated an DNS server start time, such as
+      1001.89n3mDgX072pp.server1.example.com.
+
+      If the key is generated as the result of a query with a non-root
+      name, say 789.resolver.example.net, then use the concatenation of
+      that with a name of the server.  For example
+      789.resolver.example.net.server1.example.com.
+
+2.2 The TTL Field
+
+   The TTL field is meaningless in TKEY RRs. It SHOULD always be zero to
+   be sure that older DNS implementations do not cache TKEY RRs.
+
+2.3 The Algorithm Field
+
+   The algorithm name is in the form of a domain name with the same
+   meaning as in [RFC 2845].  The algorithm determines how the secret
+   keying material agreed to using the TKEY RR is actually used to
+   derive the algorithm specific key.
+
+2.4 The Inception and Expiration Fields
+
+   The inception time and expiration times are in number of seconds
+   since the beginning of 1 January 1970 GMT ignoring leap seconds
+   treated as modulo 2**32 using ring arithmetic [RFC 1982]. In messages
+   between a DNS resolver and a DNS server where these fields are
+   meaningful, they are either the requested validity interval for the
+   keying material asked for or specify the validity interval of keying
+   material provided.
+
+   To avoid different interpretations of the inception and expiration
+   times in TKEY RRs, resolvers and servers exchanging them must have
+   the same idea of what time it is.  One way of doing this is with the
+   NTP protocol [RFC 2030] but that or any other time synchronization
+   used for this purpose MUST be done securely.
+
+2.5 The Mode Field
+
+   The mode field specifies the general scheme for key agreement or the
+   purpose of the TKEY DNS message.  Servers and resolvers supporting
+   this specification MUST implement the Diffie-Hellman key agreement
+   mode and the key deletion mode for queries.  All other modes are
+   OPTIONAL.  A server supporting TKEY that receives a TKEY request with
+   a mode it does not support returns the BADMODE error.  The following
+   values of the Mode octet are defined, available, or reserved:
+
+
+
+
+Eastlake                    Standards Track                     [Page 5]
+
+RFC 2930                    The DNS TKEY RR               September 2000
+
+
+         Value    Description
+         -----    -----------
+          0        - reserved, see section 7
+          1       server assignment
+          2       Diffie-Hellman exchange
+          3       GSS-API negotiation
+          4       resolver assignment
+          5       key deletion
+         6-65534   - available, see section 7
+         65535     - reserved, see section 7
+
+2.6 The Error Field
+
+   The error code field is an extended RCODE.  The following values are
+   defined:
+
+         Value   Description
+         -----   -----------
+          0       - no error
+          1-15   a non-extended RCODE
+          16     BADSIG   (TSIG)
+          17     BADKEY   (TSIG)
+          18     BADTIME  (TSIG)
+          19     BADMODE
+          20     BADNAME
+          21     BADALG
+
+   When the TKEY Error Field is non-zero in a response to a TKEY query,
+   the DNS header RCODE field indicates no error. However, it is
+   possible if a TKEY is spontaneously included in a response the TKEY
+   RR and DNS header error field could have unrelated non-zero error
+   codes.
+
+2.7 The Key Size and Data Fields
+
+   The key data size field is an unsigned 16 bit integer in network
+   order which specifies the size of the key exchange data field in
+   octets. The meaning of this data depends on the mode.
+
+2.8 The Other Size and Data Fields
+
+   The Other Size and Other Data fields are not used in this
+   specification but may be used in future extensions.  The RDLEN field
+   MUST equal the length of the RDATA section through the end of Other
+   Data or the RR is to be considered malformed and rejected.
+
+
+
+
+
+
+Eastlake                    Standards Track                     [Page 6]
+
+RFC 2930                    The DNS TKEY RR               September 2000
+
+
+3. General TKEY Considerations
+
+   TKEY is a meta-RR that is not stored or cached in the DNS and does
+   not appear in zone files.  It supports a variety of modes for the
+   establishment and deletion of shared secret keys information between
+   DNS resolvers and servers.  The establishment of such a shared key
+   requires that state be maintained at both ends and the allocation of
+   the resources to maintain such state may require mutual agreement. In
+   the absence of willingness to provide such state, servers MUST return
+   errors such as NOTIMP or REFUSED for an attempt to use TKEY and
+   resolvers are free to ignore any TKEY RRs they receive.
+
+   The shared secret keying material developed by using TKEY is a plain
+   octet sequence.  The means by which this shared secret keying
+   material, exchanged via TKEY, is actually used in any particular TSIG
+   algorithm is algorithm dependent and is defined in connection with
+   that algorithm.  For example, see [RFC 2104] for how TKEY agreed
+   shared secret keying material is used in the HMAC-MD5 algorithm or
+   other HMAC algorithms.
+
+   There MUST NOT be more than one TKEY RR in a DNS query or response.
+
+   Except for GSS-API mode, TKEY responses MUST always have DNS
+   transaction authentication to protect the integrity of any keying
+   data, error codes, etc.  This authentication MUST use a previously
+   established secret (TSIG) or public (SIG(0) [RFC 2931]) key and MUST
+   NOT use any key that the response to be verified is itself providing.
+
+   TKEY queries MUST be authenticated for all modes except GSS-API and,
+   under some circumstances, server assignment mode.  In particular, if
+   the query for a server assigned key is for a key to assert some
+   privilege, such as update authority, then the query must be
+   authenticated to avoid spoofing.  However, if the key is just to be
+   used for transaction security, then spoofing will lead at worst to
+   denial of service.  Query authentication SHOULD use an established
+   secret (TSIG) key authenticator if available.  Otherwise, it must use
+   a public (SIG(0)) key signature.  It MUST NOT use any key that the
+   query is itself providing.
+
+   In the absence of required TKEY authentication, a NOTAUTH error MUST
+   be returned.
+
+   To avoid replay attacks, it is necessary that a TKEY response or
+   query not be valid if replayed on the order of 2**32 second (about
+   136 years), or a multiple thereof, later.  To accomplish this, the
+   keying material used in any TSIG or SIG(0) RR that authenticates a
+   TKEY message MUST NOT have a lifetime of more then 2**31 - 1 seconds
+
+
+
+
+Eastlake                    Standards Track                     [Page 7]
+
+RFC 2930                    The DNS TKEY RR               September 2000
+
+
+   (about 68 years).  Thus, on attempted replay, the authenticating TSIG
+   or SIG(0) RR will not be verifiable due to key expiration and the
+   replay will fail.
+
+4. Exchange via Resolver Query
+
+   One method for a resolver and a server to agree about shared secret
+   keying material for use in TSIG is through DNS requests from the
+   resolver which are syntactically DNS queries for type TKEY.  Such
+   queries MUST be accompanied by a TKEY RR in the additional
+   information section to indicate the mode in use and accompanied by
+   other information where required.
+
+   Type TKEY queries SHOULD NOT be flagged as recursive and servers MAY
+   ignore the recursive header bit in TKEY queries they receive.
+
+4.1 Query for Diffie-Hellman Exchanged Keying
+
+   Diffie-Hellman (DH) key exchange is a means whereby two parties can
+   derive some shared secret information without requiring any secrecy
+   of the messages they exchange [Schneier].  Provisions have been made
+   for the storage of DH public keys in the DNS [RFC 2539].
+
+   A resolver sends a query for type TKEY accompanied by a TKEY RR in
+   the additional information section specifying the Diffie-Hellman mode
+   and accompanied by a KEY RR also in the additional information
+   section specifying a resolver Diffie-Hellman key.  The TKEY RR
+   algorithm field is set to the authentication algorithm the resolver
+   plans to use. The "key data" provided in the TKEY is used as a random
+   [RFC 1750] nonce to avoid always deriving the same keying material
+   for the same pair of DH KEYs.
+
+   The server response contains a TKEY in its answer section with the
+   Diffie-Hellman mode. The "key data" provided in this TKEY is used as
+   an additional nonce to avoid always deriving the same keying material
+   for the same pair of DH KEYs. If the TKEY error field is non-zero,
+   the query failed for the reason given. FORMERR is given if the query
+   included no DH KEY and BADKEY is given if the query included an
+   incompatible DH KEY.
+
+   If the TKEY error field is zero, the resolver supplied Diffie-Hellman
+   KEY RR SHOULD be echoed in the additional information section and a
+   server Diffie-Hellman KEY RR will also be present in the answer
+   section of the response.  Both parties can then calculate the same
+   shared secret quantity from the pair of Diffie-Hellman (DH) keys used
+   [Schneier] (provided these DH keys use the same generator and
+   modulus) and the data in the TKEY RRs.  The TKEY RR data is mixed
+   with the DH result as follows:
+
+
+
+Eastlake                    Standards Track                     [Page 8]
+
+RFC 2930                    The DNS TKEY RR               September 2000
+
+
+      keying material =
+           XOR ( DH value, MD5 ( query data | DH value ) |
+                           MD5 ( server data | DH value ) )
+
+   Where XOR is an exclusive-OR operation and "|" is byte-stream
+   concatenation.  The shorter of the two operands to XOR is byte-wise
+   left justified and padded with zero-valued bytes to match the length
+   of the other operand.  "DH value" is the Diffie-Hellman value derived
+   from the KEY RRs. Query data and server data are the values sent in
+   the TKEY RR data fields.  These "query data" and "server data" nonces
+   are suffixed by the DH value, digested by MD5, the results
+   concatenated, and then XORed with the DH value.
+
+   The inception and expiry times in the query TKEY RR are those
+   requested for the keying material.  The inception and expiry times in
+   the response TKEY RR are the maximum period the server will consider
+   the keying material valid.  Servers may pre-expire keys so this is
+   not a guarantee.
+
+4.2 Query for TKEY Deletion
+
+   Keys established via TKEY can be treated as soft state.  Since DNS
+   transactions are originated by the resolver, the resolver can simply
+   toss keys, although it may have to go through another key exchange if
+   it later needs one.  Similarly, the server can discard keys although
+   that will result in an error on receiving a query with a TSIG using
+   the discarded key.
+
+   To avoid attempted reliance in requests on keys no longer in effect,
+   servers MUST implement key deletion whereby the server "discards" a
+   key on receipt from a resolver of an authenticated delete request for
+   a TKEY RR with the key's name.  If the server has no record of a key
+   with that name, it returns BADNAME.
+
+   Key deletion TKEY queries MUST be authenticated.  This authentication
+   MAY be a TSIG RR using the key to be deleted.
+
+   For querier assigned and Diffie-Hellman keys, the server MUST truly
+   "discard" all active state associated with the key.  For server
+   assigned keys, the server MAY simply mark the key as no longer
+   retained by the client and may re-send it in response to a future
+   query for server assigned keying material.
+
+
+
+
+
+
+
+
+
+Eastlake                    Standards Track                     [Page 9]
+
+RFC 2930                    The DNS TKEY RR               September 2000
+
+
+4.3 Query for GSS-API Establishment
+
+   This mode is described in a separate document under preparation which
+   should be seen for the full description.  Basically the resolver and
+   server can exchange queries and responses for type TKEY with a TKEY
+   RR specifying the GSS-API mode in the additional information section
+   and a GSS-API token in the key data portion of the TKEY RR.
+
+   Any issues of possible encryption of parts the GSS-API token data
+   being transmitted are handled by the GSS-API level.  In addition, the
+   GSS-API level provides its own authentication so that this mode of
+   TKEY query and response MAY be, but do not need to be, authenticated
+   with TSIG RR or SIG(0) RR [RFC 2931].
+
+   The inception and expiry times in a GSS-API mode TKEY RR are ignored.
+
+4.4 Query for Server Assigned Keying
+
+   Optionally, the server can assign keying for the resolver.  It is
+   sent to the resolver encrypted under a resolver public key.  See
+   section 6 for description of encryption methods.
+
+   A resolver sends a query for type TKEY accompanied by a TKEY RR
+   specifying the "server assignment" mode and a resolver KEY RR to be
+   used in encrypting the response, both in the additional information
+   section. The TKEY algorithm field is set to the authentication
+   algorithm the resolver plans to use.  It is RECOMMENDED that any "key
+   data" provided in the query TKEY RR by the resolver be strongly mixed
+   by the server with server generated randomness [RFC 1750] to derive
+   the keying material to be used.  The KEY RR that appears in the query
+   need not be accompanied by a SIG(KEY) RR.  If the query is
+   authenticated by the resolver with a TSIG RR [RFC 2845] or SIG(0) RR
+   and that authentication is verified, then any SIG(KEY) provided in
+   the query SHOULD be ignored.  The KEY RR in such a query SHOULD have
+   a name that corresponds to the resolver but it is only essential that
+   it be a public key for which the resolver has the corresponding
+   private key so it can decrypt the response data.
+
+   The server response contains a TKEY RR in its answer section with the
+   server assigned mode and echoes the KEY RR provided in the query in
+   its additional information section.
+
+   If the response TKEY error field is zero, the key data portion of the
+   response TKEY RR will be the server assigned keying data encrypted
+   under the public key in the resolver provided KEY RR.  In this case,
+   the owner name of the answer TKEY RR will be the server assigned name
+   of the key.
+
+
+
+
+Eastlake                    Standards Track                    [Page 10]
+
+RFC 2930                    The DNS TKEY RR               September 2000
+
+
+   If the error field of the response TKEY is non-zero, the query failed
+   for the reason given.  FORMERR is given if the query specified no
+   encryption key.
+
+   The inception and expiry times in the query TKEY RR are those
+   requested for the keying material.  The inception and expiry times in
+   the response TKEY are the maximum period the server will consider the
+   keying material valid.  Servers may pre-expire keys so this is not a
+   guarantee.
+
+   The resolver KEY RR MUST be authenticated, through the authentication
+   of this query with a TSIG or SIG(0) or the signing of the resolver
+   KEY with a SIG(KEY).  Otherwise, an attacker can forge a resolver KEY
+   for which they know the private key, and thereby the attacker could
+   obtain a valid shared secret key from the server.
+
+4.5 Query for Resolver Assigned Keying
+
+   Optionally, a server can accept resolver assigned keys.  The keying
+   material MUST be encrypted under a server key for protection in
+   transmission as described in Section 6.
+
+   The resolver sends a TKEY query with a TKEY RR that specifies the
+   encrypted keying material and a KEY RR specifying the server public
+   key used to encrypt the data, both in the additional information
+   section.  The name of the key and the keying data are completely
+   controlled by the sending resolver so a globally unique key name
+   SHOULD be used.  The KEY RR used MUST be one for which the server has
+   the corresponding private key, or it will not be able to decrypt the
+   keying material and will return a FORMERR. It is also important that
+   no untrusted party (preferably no other party than the server) has
+   the private key corresponding to the KEY RR because, if they do, they
+   can capture the messages to the server, learn the shared secret, and
+   spoof valid TSIGs.
+
+   The query TKEY RR inception and expiry give the time period the
+   querier intends to consider the keying material valid.  The server
+   can return a lesser time interval to advise that it will not maintain
+   state for that long and can pre-expire keys in any case.
+
+   This mode of query MUST be authenticated with a TSIG or SIG(0).
+   Otherwise, an attacker can forge a resolver assigned TKEY query, and
+   thereby the attacker could specify a shared secret key that would be
+   accepted, used, and honored by the server.
+
+
+
+
+
+
+
+Eastlake                    Standards Track                    [Page 11]
+
+RFC 2930                    The DNS TKEY RR               September 2000
+
+
+5. Spontaneous Server Inclusion
+
+   A DNS server may include a TKEY RR spontaneously as additional
+   information in responses.  This SHOULD only be done if the server
+   knows the querier understands TKEY and has this option implemented.
+   This technique can be used to delete a key and may be specified for
+   modes defined in the future.  A disadvantage of this technique is
+   that there is no way for the server to get any error or success
+   indication back and, in the case of UDP, no way to even know if the
+   DNS response reached the resolver.
+
+5.1 Spontaneous Server Key Deletion
+
+   A server can optionally tell a client that it has deleted a secret
+   key by spontaneously including a TKEY RR in the additional
+   information section of a response with the key's name and specifying
+   the key deletion mode.  Such a response SHOULD be authenticated.  If
+   authenticated, it "deletes" the key with the given name.  The
+   inception and expiry times of the delete TKEY RR are ignored. Failure
+   by a client to receive or properly process such additional
+   information in a response would mean that the client might use a key
+   that the server had discarded and would then get an error indication.
+
+   For server assigned and Diffie-Hellman keys, the client MUST
+   "discard" active state associated with the key.  For querier assigned
+   keys, the querier MAY simply mark the key as no longer retained by
+   the server and may re-send it in a future query specifying querier
+   assigned keying material.
+
+6. Methods of Encryption
+
+   For the server assigned and resolver assigned key agreement modes,
+   the keying material is sent within the key data field of a TKEY RR
+   encrypted under the public key in an accompanying KEY RR [RFC 2535].
+   This KEY RR MUST be for a public key algorithm where the public and
+   private keys can be used for encryption and the corresponding
+   decryption which recovers the originally encrypted data.  The KEY RR
+   SHOULD correspond to a name for the decrypting resolver/server such
+   that the decrypting process has access to the corresponding private
+   key to decrypt the data.  The secret keying material being sent will
+   generally be fairly short, usually less than 256 bits, because that
+   is adequate for very strong protection with modern keyed hash or
+   symmetric algorithms.
+
+   If the KEY RR specifies the RSA algorithm, then the keying material
+   is encrypted as per the description of RSAES-PKCS1-v1_5 encryption in
+   PKCS#1 [RFC 2437].  (Note, the secret keying material being sent is
+   directly RSA encrypted in PKCS#1 format. It is not "enveloped" under
+
+
+
+Eastlake                    Standards Track                    [Page 12]
+
+RFC 2930                    The DNS TKEY RR               September 2000
+
+
+   some other symmetric algorithm.)  In the unlikely event that the
+   keying material will not fit within one RSA modulus of the chosen
+   public key, additional RSA encryption blocks are included.  The
+   length of each block is clear from the public RSA key specified and
+   the RSAES-PKCS1-v1_5 padding makes it clear what part of the
+   encrypted data is actually keying material and what part is
+   formatting or the required at least eight bytes of random [RFC 1750]
+   padding.
+
+7. IANA Considerations
+
+   This section is to be interpreted as provided in [RFC 2434].
+
+   Mode field values 0x0000 and 0xFFFF are reserved.
+
+   Mode field values 0x0001 through 0x00FF, and 0XFF00 through 0XFFFE
+   can only be assigned by an IETF Standards Action.
+
+   Mode field values 0x0100 through 0x0FFF and 0xF0000 through 0xFEFF
+   are allocated by IESG approval or IETF consensus.
+
+   Mode field values 0x1000 through 0xEFFF are allocated based on
+   Specification Required as defined in [RFC 2434].
+
+   Mode values should not be changed when the status of their use
+   changes.  For example, a mode value assigned based just on providing
+   a specification should not be changed later just because that use's
+   status is changed to standards track.
+
+   The following assignments are documented herein:
+
+      RR Type 249 for TKEY.
+
+      TKEY Modes 1 through 5 as listed in section 2.5.
+
+      Extended RCODE Error values of 19, 20, and 21 as listed in section
+      2.6.
+
+8. Security Considerations
+
+   The entirety of this specification is concerned with the secure
+   establishment of a shared secret between DNS clients and servers in
+   support of TSIG [RFC 2845].
+
+   Protection against denial of service via the use of TKEY is not
+   provided.
+
+
+
+
+
+Eastlake                    Standards Track                    [Page 13]
+
+RFC 2930                    The DNS TKEY RR               September 2000
+
+
+References
+
+   [Schneier] Bruce Schneier, "Applied Cryptography: Protocols,
+              Algorithms, and Source Code in C", 1996, John Wiley and
+              Sons
+
+   [RFC 1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
+              STD 13, RFC 1034, November 1987.
+
+   [RFC 1035] Mockapetris, P., "Domain Names - Implementation and
+              Specifications", STD 13, RFC 1035, November 1987.
+
+   [RFC 1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness
+              Recommendations for Security", RFC 1750, December 1994.
+
+   [RFC 1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
+              September 1996.
+
+   [RFC 1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
+              August 1996.
+
+   [RFC 2030] Mills, D., "Simple Network Time Protocol (SNTP) Version 4
+              for IPv4, IPv6 and OSI", RFC 2030, October 1996.
+
+   [RFC 2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC:  Keyed-
+              Hashing for Message Authentication", RFC 2104, February
+              1997.
+
+   [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC 2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic
+              Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
+              April 1997.
+
+   [RFC 2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
+              IANA Considerations Section in RFCs", BCP 26, RFC 2434,
+              October 1998.
+
+   [RFC 2437] Kaliski, B. and J. Staddon, "PKCS #1: RSA Cryptography
+              Specifications Version 2.0", RFC 2437, October 1998.
+
+   [RFC 2535] Eastlake, D., "Domain Name System Security Extensions",
+              RFC 2535, March 1999.
+
+   [RFC 2539] Eastlake, D., "Storage of Diffie-Hellman Keys in the
+              Domain Name System (DNS)", RFC 2539, March 1999.
+
+
+
+
+Eastlake                    Standards Track                    [Page 14]
+
+RFC 2930                    The DNS TKEY RR               September 2000
+
+
+   [RFC 2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B.
+              Wellington, "Secret Key Transaction Authentication for DNS
+              (TSIG)", RFC 2845, May 2000.
+
+   [RFC 2931] Eastlake, D., "DNS Request and Transaction Signatures
+              (SIG(0)s )", RFC 2931, September 2000.
+
+Author's Address
+
+   Donald E. Eastlake 3rd
+   Motorola
+   140 Forest Avenue
+   Hudson, MA 01749 USA
+
+   Phone: +1 978-562-2827 (h)
+          +1 508-261-5434 (w)
+   Fax:   +1 508-261-4447 (w)
+   EMail: Donald.Eastlake@motorola.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake                    Standards Track                    [Page 15]
+
+RFC 2930                    The DNS TKEY RR               September 2000
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2000).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake                    Standards Track                    [Page 16]
+
diff --git a/doc/rfc/rfc2931.txt b/doc/rfc/rfc2931.txt
new file mode 100644
index 0000000..84cc97e
--- /dev/null
+++ b/doc/rfc/rfc2931.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+Network Working Group                                    D. Eastlake 3rd
+Request for Comments: 2931                                      Motorola
+Updates: 2535                                             September 2000
+Category: Standards Track
+
+
+           DNS Request and Transaction Signatures ( SIG(0)s )
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2000).  All Rights Reserved.
+
+Abstract
+
+   Extensions to the Domain Name System (DNS) are described in [RFC
+   2535] that can provide data origin and transaction integrity and
+   authentication to security aware resolvers and applications through
+   the use of cryptographic digital signatures.
+
+   Implementation experience has indicated the need for minor but non-
+   interoperable changes in Request and Transaction signature resource
+   records ( SIG(0)s ).  These changes are documented herein.
+
+Acknowledgments
+
+   The contributions and suggestions of the following persons (in
+   alphabetic order) to this memo are gratefully acknowledged:
+
+         Olafur Gudmundsson
+
+         Ed Lewis
+
+         Erik Nordmark
+
+         Brian Wellington
+
+
+
+
+
+
+
+
+Eastlake                    Standards Track                     [Page 1]
+
+RFC 2931                       DNS SIG(0)                 September 2000
+
+
+Table of Contents
+
+   1. Introduction.................................................  2
+   2. SIG(0) Design Rationale......................................  3
+   2.1 Transaction Authentication..................................  3
+   2.2 Request Authentication......................................  3
+   2.3 Keying......................................................  3
+   2.4 Differences Between TSIG and SIG(0).........................  4
+   3. The SIG(0) Resource Record...................................  4
+   3.1 Calculating Request and Transaction SIGs....................  5
+   3.2 Processing Responses and SIG(0) RRs.........................  6
+   3.3 SIG(0) Lifetime and Expiration..............................  7
+   4. Security Considerations......................................  7
+   5. IANA Considerations..........................................  7
+   References......................................................  7
+   Author's Address................................................  8
+   Appendix: SIG(0) Changes from RFC 2535..........................  9
+   Full Copyright Statement........................................ 10
+
+1. Introduction
+
+   This document makes minor but non-interoperable changes to part of
+   [RFC 2535], familiarity with which is assumed, and includes
+   additional explanatory text.  These changes concern SIG Resource
+   Records (RRs) that are used to digitally sign DNS requests and
+   transactions / responses.  Such a resource record, because it has a
+   type covered field of zero, is frequently called a SIG(0). The
+   changes are based on implementation and attempted implementation
+   experience with TSIG [RFC 2845] and the [RFC 2535] specification for
+   SIG(0).
+
+   Sections of [RFC 2535] updated are all of 4.1.8.1 and parts of 4.2
+   and 4.3.  No changes are made herein related to the KEY or NXT RRs or
+   to the processing involved with data origin and denial authentication
+   for DNS data.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC 2119].
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake                    Standards Track                     [Page 2]
+
+RFC 2931                       DNS SIG(0)                 September 2000
+
+
+2. SIG(0) Design Rationale
+
+   SIG(0) provides protection for DNS transactions and requests that is
+   not provided by the regular SIG, KEY, and NXT RRs specified in [RFC
+   2535].  The authenticated data origin services of secure DNS either
+   provide protected data resource records (RRs) or authenticatably deny
+   their nonexistence.  These services provide no protection for glue
+   records, DNS requests, no protection for message headers on requests
+   or responses, and no protection of the overall integrity of a
+   response.
+
+2.1 Transaction Authentication
+
+   Transaction authentication means that a requester can be sure it is
+   at least getting the messages from the server it queried and that the
+   received messages are in response to the query it sent.  This is
+   accomplished by optionally adding either a TSIG RR [RFC 2845] or, as
+   described herein, a SIG(0) resource record at the end of the response
+   which digitally signs the concatenation of the server's response and
+   the corresponding resolver query.
+
+2.2 Request Authentication
+
+   Requests can also be authenticated by including a TSIG or, as
+   described herein, a special SIG(0) RR at the end of the request.
+   Authenticating requests serves no function in DNS servers that
+   predate the specification of dynamic update.  Requests with a non-
+   empty additional information section produce error returns or may
+   even be ignored by a few such older DNS servers. However, this syntax
+   for signing requests is defined for authenticating dynamic update
+   requests [RFC 2136], TKEY requests [RFC 2930], or future requests
+   requiring authentication.
+
+2.3 Keying
+
+   The private keys used in transaction security belong to the host
+   composing the DNS response message, not to the zone involved.
+   Request authentication may also involve the private key of the host
+   or other entity composing the request or of a zone to be affected by
+   the request or other private keys depending on the request authority
+   it is sought to establish. The corresponding public key(s) are
+   normally stored in and retrieved from the DNS for verification as KEY
+   RRs with a protocol byte of 3 (DNSSEC) or 255 (ANY).
+
+   Because requests and replies are highly variable, message
+   authentication SIGs can not be pre-calculated.  Thus it will be
+   necessary to keep the private key on-line, for example in software or
+   in a directly connected piece of hardware.
+
+
+
+Eastlake                    Standards Track                     [Page 3]
+
+RFC 2931                       DNS SIG(0)                 September 2000
+
+
+2.4 Differences Between TSIG and SIG(0)
+
+   There are significant differences between TSIG and SIG(0).
+
+   Because TSIG involves secret keys installed at both the requester and
+   server the presence of such a key implies that the other party
+   understands TSIG and very likely has the same key installed.
+   Furthermore, TSIG uses keyed hash authentication codes which are
+   relatively inexpensive to compute.  Thus it is common to authenticate
+   requests with TSIG and responses are authenticated with TSIG if the
+   corresponding request is authenticated.
+
+   SIG(0) on the other hand, uses public key authentication, where the
+   public keys are stored in DNS as KEY RRs and a private key is stored
+   at the signer.  Existence of such a KEY RR does not necessarily imply
+   implementation of SIG(0).  In addition, SIG(0) involves relatively
+   expensive public key cryptographic operations that should be
+   minimized and the verification of a SIG(0) involves obtaining and
+   verifying the corresponding KEY which can be an expensive and lengthy
+   operation.  Indeed, a policy of using SIG(0) on all requests and
+   verifying it before responding would, for some configurations, lead
+   to a deadly embrace with the attempt to obtain and verify the KEY
+   needed to authenticate the request SIG(0) resulting in additional
+   requests accompanied by a SIG(0) leading to further requests
+   accompanied by a SIG(0), etc.  Furthermore, omitting SIG(0)s when not
+   required on requests halves the number of public key operations
+   required by the transaction.
+
+   For these reasons, SIG(0)s SHOULD only be used on requests when
+   necessary to authenticate that the requester has some required
+   privilege or identity.  SIG(0)s on replies are defined in such a way
+   as to not require a SIG(0) on the corresponding request and still
+   provide transaction protection.  For other replies, whether they are
+   authenticated by the server or required to be authenticated by the
+   requester SHOULD be a local configuration option.
+
+3. The SIG(0) Resource Record
+
+   The structure of and type number of SIG resource records (RRs) is
+   given in [RFC 2535] Section 4.1.  However all of Section 4.1.8.1 and
+   the parts of Sections 4.2 and 4.3 related to SIG(0) should be
+   considered replaced by the material below.  Any conflict between [RFC
+   2535] and this document concerning SIG(0) RRs should be resolved in
+   favor of this document.
+
+   For all transaction SIG(0)s, the signer field MUST be a name of the
+   originating host and there MUST be a KEY RR at that name with the
+   public key corresponding to the private key used to calculate the
+
+
+
+Eastlake                    Standards Track                     [Page 4]
+
+RFC 2931                       DNS SIG(0)                 September 2000
+
+
+   signature.  (The host domain name used may be the inverse IP address
+   mapping name for an IP address of the host if the relevant KEY is
+   stored there.)
+
+   For all SIG(0) RRs, the owner name, class, TTL, and original TTL, are
+   meaningless.  The TTL fields SHOULD be zero and the CLASS field
+   SHOULD be ANY.  To conserve space, the owner name SHOULD be root (a
+   single zero octet).  When SIG(0) authentication on a response is
+   desired, that SIG RR MUST be considered the highest priority of any
+   additional information for inclusion in the response. If the SIG(0)
+   RR cannot be added without causing the message to be truncated, the
+   server MUST alter the response so that a SIG(0) can be included.
+   This response consists of only the question and a SIG(0) record, and
+   has the TC bit set and RCODE 0 (NOERROR).  The client should at this
+   point retry the request using TCP.
+
+3.1 Calculating Request and Transaction SIGs
+
+   A DNS request may be optionally signed by including one SIG(0)s at
+   the end of the query additional information section.  Such a SIG is
+   identified by having a "type covered" field of zero. It signs the
+   preceding DNS request message including DNS header but not including
+   the UDP/IP header and before the request RR counts have been adjusted
+   for the inclusions of the request SIG(0).
+
+   It is calculated by using a "data" (see [RFC 2535], Section 4.1.8) of
+   (1) the SIG's RDATA section entirely omitting (not just zeroing) the
+   signature subfield itself, (2) the DNS query messages, including DNS
+   header, but not the UDP/IP header and before the reply RR counts have
+   been adjusted for the inclusion of the SIG(0).  That is
+
+      data = RDATA | request - SIG(0)
+
+   where "|" is concatenation and RDATA is the RDATA of the SIG(0) being
+   calculated less the signature itself.
+
+   Similarly, a SIG(0) can be used to secure a response and the request
+   that produced it.  Such transaction signatures are calculated by
+   using a "data" of (1) the SIG's RDATA section omitting the signature
+   itself, (2) the entire DNS query message that produced this response,
+   including the query's DNS header but not its UDP/IP header, and (3)
+   the entire DNS response message, including DNS header but not the
+   UDP/IP header and before the response RR counts have been adjusted
+   for the inclusion of the SIG(0).
+
+
+
+
+
+
+
+Eastlake                    Standards Track                     [Page 5]
+
+RFC 2931                       DNS SIG(0)                 September 2000
+
+
+   That is
+
+      data = RDATA | full query | response - SIG(0)
+
+   where "|" is concatenation and RDATA is the RDATA of the SIG(0) being
+   calculated less the signature itself.
+
+   Verification of a response SIG(0) (which is signed by the server host
+   key, not the zone key) by the requesting resolver shows that the
+   query and response were not tampered with in transit, that the
+   response corresponds to the intended query, and that the response
+   comes from the queried server.
+
+   In the case of a DNS message via TCP, a SIG(0) on the first data
+   packet is calculated with "data" as above and for each subsequent
+   packet, it is calculated as follows:
+
+      data = RDATA | DNS payload - SIG(0) | previous packet
+
+   where "|" is concatenations, RDATA is as above, and previous packet
+   is the previous DNS payload including DNS header and the SIG(0) but
+   not the TCP/IP header.  Support of SIG(0) for TCP is OPTIONAL.  As an
+   alternative, TSIG may be used after, if necessary, setting up a key
+   with TKEY [RFC 2930].
+
+   Except where needed to authenticate an update, TKEY, or similar
+   privileged request, servers are not required to check a request
+   SIG(0).
+
+   Note: requests and responses can either have a single TSIG or one
+   SIG(0) but not both a TSIG and a SIG(0).
+
+3.2 Processing Responses and SIG(0) RRs
+
+   If a SIG RR is at the end of the additional information section of a
+   response and has a type covered of zero, it is a transaction
+   signature covering the response and the query that produced the
+   response.  For TKEY responses, it MUST be checked and the message
+   rejected if the checks fail unless otherwise specified for the TKEY
+   mode in use.  For all other responses, it MAY be checked and the
+   message rejected if the checks fail.
+
+   If a response's SIG(0) check succeed, such a transaction
+   authentication SIG does NOT directly authenticate the validity any
+   data-RRs in the message.  However, it authenticates that they were
+   sent by the queried server and have not been diddled.  (Only a proper
+   SIG(0) RR signed by the zone or a key tracing its authority to the
+   zone or to static resolver configuration can directly authenticate
+
+
+
+Eastlake                    Standards Track                     [Page 6]
+
+RFC 2931                       DNS SIG(0)                 September 2000
+
+
+   data-RRs, depending on resolver policy.) If a resolver or server does
+   not implement transaction and/or request SIGs, it MUST ignore them
+   without error where they are optional and treat them as failing where
+   they are required.
+
+3.3 SIG(0) Lifetime and Expiration
+
+   The inception and expiration times in SIG(0)s are for the purpose of
+   resisting replay attacks.  They should be set to form a time bracket
+   such that messages outside that bracket can be ignored.  In IP
+   networks, this time bracket should not normally extend further than 5
+   minutes into the past and 5 minutes into the future.
+
+4. Security Considerations
+
+   No additional considerations beyond those in [RFC 2535].
+
+   The inclusion of the SIG(0) inception and expiration time under the
+   signature improves resistance to replay attacks.
+
+5. IANA Considerations
+
+   No new parameters are created or parameter values assigned by this
+   document.
+
+References
+
+   [RFC 1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
+              September 1996.
+
+   [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC 2136] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic
+              Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
+              April 1997.
+
+   [RFC 2535] Eastlake, D., "Domain Name System Security Extensions",
+              RFC 2535, March 1999.
+
+   [RFC 2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B.
+              Wellington, "Secret Key Transaction Signatures for DNS
+              (TSIG)", RFC 2845, May 2000.
+
+   [RFC 2930] Eastlake, D., "Secret Key Establishment for DNS (RR)", RFC
+              2930, September 2000.
+
+
+
+
+
+Eastlake                    Standards Track                     [Page 7]
+
+RFC 2931                       DNS SIG(0)                 September 2000
+
+
+Author's Address
+
+   Donald E. Eastlake 3rd
+   Motorola
+   140 Forest Avenue
+   Hudson, MA 01749 USA
+
+   Phone: +1-978-562-2827(h)
+          +1-508-261-5434(w)
+   Fax:   +1 978-567-7941(h)
+          +1-508-261-4447(w)
+   EMail: Donald.Eastlake@motorola.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake                    Standards Track                     [Page 8]
+
+RFC 2931                       DNS SIG(0)                 September 2000
+
+
+Appendix: SIG(0) Changes from RFC 2535
+
+   Add explanatory text concerning the differences between TSIG and
+   SIG(0).
+
+   Change the data over which SIG(0) is calculated to include the SIG(0)
+   RDATA other than the signature itself so as to secure the signature
+   inception and expiration times and resist replay attacks.  Specify
+   SIG(0) for TCP.
+
+   Add discussion of appropriate inception and expiration times for
+   SIG(0).
+
+   Add wording to indicate that either a TSIG or one or more SIG(0)s may
+   be present but not both.
+
+   Reword some areas for clarity.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake                    Standards Track                     [Page 9]
+
+RFC 2931                       DNS SIG(0)                 September 2000
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2000).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake                    Standards Track                    [Page 10]
+
diff --git a/doc/rfc/rfc3007.txt b/doc/rfc/rfc3007.txt
new file mode 100644
index 0000000..1697475
--- /dev/null
+++ b/doc/rfc/rfc3007.txt
@@ -0,0 +1,507 @@
+
+
+
+
+
+
+Network Working Group                                      B. Wellington
+Request for Comments: 3007                                       Nominum
+Updates: 2535, 2136                                        November 2000
+Obsoletes: 2137
+Category: Standards Track
+
+
+             Secure Domain Name System (DNS) Dynamic Update
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2000).  All Rights Reserved.
+
+Abstract
+
+   This document proposes a method for performing secure Domain Name
+   System (DNS) dynamic updates.  The method described here is intended
+   to be flexible and useful while requiring as few changes to the
+   protocol as possible.  The authentication of the dynamic update
+   message is separate from later DNSSEC validation of the data.  Secure
+   communication based on authenticated requests and transactions is
+   used to provide authorization.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [RFC2119].
+
+1 - Introduction
+
+   This document defines a means to secure dynamic updates of the Domain
+   Name System (DNS), allowing only authorized sources to make changes
+   to a zone's contents.  The existing unsecured dynamic update
+   operations form the basis for this work.
+
+   Familiarity with the DNS system [RFC1034, RFC1035] and dynamic update
+   [RFC2136] is helpful and is assumed by this document.  In addition,
+   knowledge of DNS security extensions [RFC2535], SIG(0) transaction
+   security [RFC2535, RFC2931], and TSIG transaction security [RFC2845]
+   is recommended.
+
+
+
+
+Wellington                  Standards Track                     [Page 1]
+
+RFC 3007                 Secure Dynamic Update             November 2000
+
+
+   This document updates portions of RFC 2535, in particular section
+   3.1.2, and RFC 2136.  This document obsoletes RFC 2137, an alternate
+   proposal for secure dynamic update, due to implementation experience.
+
+1.1 - Overview of DNS Dynamic Update
+
+   DNS dynamic update defines a new DNS opcode and a new interpretation
+   of the DNS message if that opcode is used.  An update can specify
+   insertions or deletions of data, along with prerequisites necessary
+   for the updates to occur.  All tests and changes for a DNS update
+   request are restricted to a single zone, and are performed at the
+   primary server for the zone.  The primary server for a dynamic zone
+   must increment the zone SOA serial number when an update occurs or
+   before the next retrieval of the SOA.
+
+1.2 - Overview of DNS Transaction Security
+
+   Exchanges of DNS messages which include TSIG [RFC2845] or SIG(0)
+   [RFC2535, RFC2931] records allow two DNS entities to authenticate DNS
+   requests and responses sent between them.  A TSIG MAC (message
+   authentication code) is derived from a shared secret, and a SIG(0) is
+   generated from a private key whose public counterpart is stored in
+   DNS.  In both cases, a record containing the message signature/MAC is
+   included as the final resource record in a DNS message.  Keyed
+   hashes, used in TSIG, are inexpensive to calculate and verify.
+   Public key encryption, as used in SIG(0), is more scalable as the
+   public keys are stored in DNS.
+
+1.3 - Comparison of data authentication and message authentication
+
+   Message based authentication, using TSIG or SIG(0), provides
+   protection for the entire message with a single signing and single
+   verification which, in the case of TSIG, is a relatively inexpensive
+   MAC creation and check.  For update requests, this signature can
+   establish, based on policy or key negotiation, the authority to make
+   the request.
+
+   DNSSEC SIG records can be used to protect the integrity of individual
+   RRs or RRsets in a DNS message with the authority of the zone owner.
+   However, this cannot sufficiently protect the dynamic update request.
+
+   Using SIG records to secure RRsets in an update request is
+   incompatible with the design of update, as described below, and would
+   in any case require multiple expensive public key signatures and
+   verifications.
+
+
+
+
+
+
+Wellington                  Standards Track                     [Page 2]
+
+RFC 3007                 Secure Dynamic Update             November 2000
+
+
+   SIG records do not cover the message header, which includes record
+   counts.  Therefore, it is possible to maliciously insert or remove
+   RRsets in an update request without causing a verification failure.
+
+   If SIG records were used to protect the prerequisite section, it
+   would be impossible to determine whether the SIGs themselves were a
+   prerequisite or simply used for validation.
+
+   In the update section of an update request, signing requests to add
+   an RRset is straightforward, and this signature could be permanently
+   used to protect the data, as specified in [RFC2535].  However, if an
+   RRset is deleted, there is no data for a SIG to cover.
+
+1.4 - Data and message signatures
+
+   As specified in [RFC3008], the DNSSEC validation process performed by
+   a resolver MUST NOT process any non-zone keys unless local policy
+   dictates otherwise.  When performing secure dynamic update, all zone
+   data modified in a signed zone MUST be signed by a relevant zone key.
+   This completely disassociates authentication of an update request
+   from authentication of the data itself.
+
+   The primary usefulness of host and user keys, with respect to DNSSEC,
+   is to authenticate messages, including dynamic updates.  Thus, host
+   and user keys MAY be used to generate SIG(0) records to authenticate
+   updates and MAY be used in the TKEY [RFC2930] process to generate
+   TSIG shared secrets.  In both cases, no SIG records generated by
+   non-zone keys will be used in a DNSSEC validation process unless
+   local policy dictates.
+
+   Authentication of data, once it is present in DNS, only involves
+   DNSSEC zone keys and signatures generated by them.
+
+1.5 - Signatory strength
+
+   [RFC2535, section 3.1.2] defines the signatory field of a key as the
+   final 4 bits of the flags field, but does not define its value.  This
+   proposal leaves this field undefined.  Updating [RFC2535], this field
+   SHOULD be set to 0 in KEY records, and MUST be ignored.
+
+2 - Authentication
+
+   TSIG or SIG(0) records MUST be included in all secure dynamic update
+   messages.  This allows the server to verifiably determine the
+   originator of a message.  If the message contains authentication in
+   the form of a SIG(0), the identity of the sender (that is, the
+   principal) is the owner of the KEY RR that generated the SIG(0).  If
+   the message contains a TSIG generated by a statically configured
+
+
+
+Wellington                  Standards Track                     [Page 3]
+
+RFC 3007                 Secure Dynamic Update             November 2000
+
+
+   shared secret, the principal is the same as or derived from the
+   shared secret name.  If the message contains a TSIG generated by a
+   dynamically configured shared secret, the principal is the same as
+   the one that authenticated the TKEY process; if the TKEY process was
+   unauthenticated, no information is known about the principal, and the
+   associated TSIG shared secret MUST NOT be used for secure dynamic
+   update.
+
+   SIG(0) signatures SHOULD NOT be generated by zone keys, since
+   transactions are initiated by a host or user, not a zone.
+
+   DNSSEC SIG records (other than SIG(0)) MAY be included in an update
+   message, but MUST NOT be used to authenticate the update request.
+
+   If an update fails because it is signed with an unauthorized key, the
+   server MUST indicate failure by returning a message with RCODE
+   REFUSED.  Other TSIG, SIG(0), or dynamic update errors are returned
+   as specified in the appropriate protocol description.
+
+3 - Policy
+
+   All policy is configured by the zone administrator and enforced by
+   the zone's primary name server.  Policy dictates the authorized
+   actions that an authenticated principal can take.  Policy checks are
+   based on the principal and the desired action, where the principal is
+   derived from the message signing key and applied to dynamic update
+   messages signed with that key.
+
+   The server's policy defines criteria which determine if the key used
+   to sign the update is permitted to perform the requested updates.  By
+   default, a principal MUST NOT be permitted to make any changes to
+   zone data; any permissions MUST be enabled though configuration.
+
+   The policy is fully implemented in the primary zone server's
+   configuration for several reasons.  This removes limitations imposed
+   by encoding policy into a fixed number of bits (such as the KEY RR's
+   signatory field).  Policy is only relevant in the server applying it,
+   so there is no reason to expose it.  Finally, a change in policy or a
+   new type of policy should not affect the DNS protocol or data format,
+   and should not cause interoperability failures.
+
+3.1 - Standard policies
+
+   Implementations SHOULD allow access control policies to use the
+   principal as an authorization token, and MAY also allow policies to
+   grant permission to a signed message regardless of principal.
+
+
+
+
+
+Wellington                  Standards Track                     [Page 4]
+
+RFC 3007                 Secure Dynamic Update             November 2000
+
+
+   A common practice would be to restrict the permissions of a principal
+   by domain name.  That is, a principal could be permitted to add,
+   delete, or modify entries corresponding to one or more domain names.
+   Implementations SHOULD allow per-name access control, and SHOULD
+   provide a concise representation of the principal's own name, its
+   subdomains, and all names in the zone.
+
+   Additionally, a server SHOULD allow restricting updates by RR type,
+   so that a principal could add, delete, or modify specific record
+   types at certain names.  Implementations SHOULD allow per-type access
+   control, and SHOULD provide concise representations of all types and
+   all "user" types, where a user type is defined as one that does not
+   affect the operation of DNS itself.
+
+3.1.1 - User types
+
+   User types include all data types except SOA, NS, SIG, and NXT.  SOA
+   and NS records SHOULD NOT be modified by normal users, since these
+   types create or modify delegation points.  The addition of SIG
+   records can lead to attacks resulting in additional workload for
+   resolvers, and the deletion of SIG records could lead to extra work
+   for the server if the zone SIG was deleted.  Note that these records
+   are not forbidden, but not recommended for normal users.
+
+   NXT records MUST NOT be created, modified, or deleted by dynamic
+   update, as their update may cause instability in the protocol.  This
+   is an update to RFC 2136.
+
+   Issues concerning updates of KEY records are discussed in the
+   Security Considerations section.
+
+3.2 - Additional policies
+
+   Users are free to implement any policies.  Policies may be as
+   specific or general as desired, and as complex as desired.  They may
+   depend on the principal or any other characteristics of the signed
+   message.
+
+4 - Interaction with DNSSEC
+
+   Although this protocol does not change the way updates to secure
+   zones are processed, there are a number of issues that should be
+   clarified.
+
+
+
+
+
+
+
+
+Wellington                  Standards Track                     [Page 5]
+
+RFC 3007                 Secure Dynamic Update             November 2000
+
+
+4.1 - Adding SIGs
+
+   An authorized update request MAY include SIG records with each RRset.
+   Since SIG records (except SIG(0) records) MUST NOT be used for
+   authentication of the update message, they are not required.
+
+   If a principal is authorized to update SIG records and there are SIG
+   records in the update, the SIG records are added without
+   verification.  The server MAY examine SIG records and drop SIGs with
+   a temporal validity period in the past.
+
+4.2 - Deleting SIGs
+
+   If a principal is authorized to update SIG records and the update
+   specifies the deletion of SIG records, the server MAY choose to
+   override the authority and refuse the update.  For example, the
+   server may allow all SIG records not generated by a zone key to be
+   deleted.
+
+4.3 - Non-explicit updates to SIGs
+
+   If the updated zone is secured, the RRset affected by an update
+   operation MUST, at the completion of the update, be signed in
+   accordance with the zone's signing policy.  This will usually require
+   one or more SIG records to be generated by one or more zone keys
+   whose private components MUST be online [RFC3008].
+
+   When the contents of an RRset are updated, the server MAY delete all
+   associated SIG records, since they will no longer be valid.
+
+4.4 - Effects on the zone
+
+   If any changes are made, the server MUST, if necessary, generate a
+   new SOA record and new NXT records, and sign these with the
+   appropriate zone keys.  Changes to NXT records by secure dynamic
+   update are explicitly forbidden.  SOA updates are allowed, since the
+   maintenance of SOA parameters is outside of the scope of the DNS
+   protocol.
+
+5 - Security Considerations
+
+   This document requires that a zone key and possibly other
+   cryptographic secret material be held in an on-line, network-
+   connected host, most likely a name server.  This material is at the
+   mercy of host security to remain a secret.  Exposing this secret puts
+   DNS data at risk of masquerade attacks.  The data at risk is that in
+   both zones served by the machine and delegated from this machine.
+
+
+
+
+Wellington                  Standards Track                     [Page 6]
+
+RFC 3007                 Secure Dynamic Update             November 2000
+
+
+   Allowing updates of KEY records may lead to undesirable results,
+   since a principal may be allowed to insert a public key without
+   holding the private key, and possibly masquerade as the key owner.
+
+6 - Acknowledgements
+
+   The author would like to thank the following people for review and
+   informative comments (in alphabetical order):
+
+   Harald Alvestrand
+   Donald Eastlake
+   Olafur Gudmundsson
+   Andreas Gustafsson
+   Bob Halley
+   Stuart Kwan
+   Ed Lewis
+
+7 - References
+
+   [RFC1034]  Mockapetris, P., "Domain Names - Concepts and Facilities",
+              STD 13, RFC 1034, November 1987.
+
+   [RFC1035]  Mockapetris, P., "Domain Names - Implementation and
+              Specification", STD 13, RFC 1035, November 1987.
+
+   [RFC2136]  Vixie (Ed.), P., Thomson, S., Rekhter, Y. and J. Bound,
+              "Dynamic Updates in the Domain Name System", RFC 2136,
+              April 1997.
+
+   [RFC2137]  Eastlake, D., "Secure Domain Name System Dynamic Update",
+              RFC 2137, April 1997.
+
+   [RFC2535]  Eastlake, G., "Domain Name System Security Extensions",
+              RFC 2535, March 1999.
+
+   [RFC2845]  Vixie, P., Gudmundsson, O., Eastlake, D. and B.
+              Wellington, "Secret Key Transaction Signatures for DNS
+              (TSIG)", RFC 2845, May 2000.
+
+   [RFC2930]  Eastlake, D., "Secret Key Establishment for DNS (TKEY
+              RR)", RFC 2930, September 2000.
+
+   [RFC2931]  Eastlake, D., "DNS Request and Transaction Signatures
+              (SIG(0)s)", RFC 2931, September 2000.
+
+   [RFC3008]  Wellington, B., "Domain Name System Security (DNSSEC)
+              Signing Authority", RFC 3008, November 2000.
+
+
+
+
+Wellington                  Standards Track                     [Page 7]
+
+RFC 3007                 Secure Dynamic Update             November 2000
+
+
+8 - Author's Address
+
+   Brian Wellington
+   Nominum, Inc.
+   950 Charter Street
+   Redwood City, CA 94063
+
+   Phone: +1 650 381 6022
+   EMail: Brian.Wellington@nominum.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wellington                  Standards Track                     [Page 8]
+
+RFC 3007                 Secure Dynamic Update             November 2000
+
+
+9.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2000).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wellington                  Standards Track                     [Page 9]
+
diff --git a/doc/rfc/rfc3008.txt b/doc/rfc/rfc3008.txt
new file mode 100644
index 0000000..08a4a8f
--- /dev/null
+++ b/doc/rfc/rfc3008.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Network Working Group                                      B. Wellington
+Request for Comments: 3008                                       Nominum
+Updates: 2535                                              November 2000
+Category: Standards Track
+
+
+         Domain Name System Security (DNSSEC) Signing Authority
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2000).  All Rights Reserved.
+
+Abstract
+
+   This document proposes a revised model of Domain Name System Security
+   (DNSSEC) Signing Authority.  The revised model is designed to clarify
+   earlier documents and add additional restrictions to simplify the
+   secure resolution process.  Specifically, this affects the
+   authorization of keys to sign sets of records.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [RFC2119].
+
+1 - Introduction
+
+   This document defines additional restrictions on DNSSEC signatures
+   (SIG) records relating to their authority to sign associated data.
+   The intent is to establish a standard policy followed by a secure
+   resolver; this policy can be augmented by local rules.  This builds
+   upon [RFC2535], updating section 2.3.6 of that document.
+
+   The most significant change is that in a secure zone, zone data is
+   required to be signed by the zone key.
+
+   Familiarity with the DNS system [RFC1034, RFC1035] and the DNS
+   security extensions [RFC2535] is assumed.
+
+
+
+
+
+
+Wellington                  Standards Track                     [Page 1]
+
+RFC 3008                DNSSEC Signing Authority           November 2000
+
+
+2 - The SIG Record
+
+   A SIG record is normally associated with an RRset, and "covers" (that
+   is, demonstrates the authenticity and integrity of) the RRset.  This
+   is referred to as a "data SIG".  Note that there can be multiple SIG
+   records covering an RRset, and the same validation process should be
+   repeated for each of them.  Some data SIGs are considered "material",
+   that is, relevant to a DNSSEC capable resolver, and some are
+   "immaterial" or "extra-DNSSEC", as they are not relevant to DNSSEC
+   validation.  Immaterial SIGs may have application defined roles.  SIG
+   records may exist which are not bound to any RRset; these are also
+   considered immaterial.  The validation process determines which SIGs
+   are material; once a SIG is shown to be immaterial, no other
+   validation is necessary.
+
+   SIGs may also be used for transaction security.  In this case, a SIG
+   record with a type covered field of 0 is attached to a message, and
+   is used to protect message integrity.  This is referred to as a
+   SIG(0) [RFC2535, RFC2931].
+
+   The following sections define requirements for all of the fields of a
+   SIG record.  These requirements MUST be met in order for a DNSSEC
+   capable resolver to process this signature.  If any of these
+   requirements are not met, the SIG cannot be further processed.
+   Additionally, once a KEY has been identified as having generated this
+   SIG, there are requirements that it MUST meet.
+
+2.1 - Type Covered
+
+   For a data SIG, the type covered MUST be the same as the type of data
+   in the associated RRset.  For a SIG(0), the type covered MUST be 0.
+
+2.2 - Algorithm Number
+
+   The algorithm specified in a SIG MUST be recognized by the client,
+   and it MUST be an algorithm that has a defined SIG rdata format.
+
+2.3 - Labels
+
+   The labels count MUST be less than or equal to the number of labels
+   in the SIG owner name, as specified in [RFC2535, section 4.1.3].
+
+2.4 - Original TTL
+
+   The original TTL MUST be greater than or equal to the TTL of the SIG
+   record itself, since the TTL cannot be increased by intermediate
+   servers.  This field can be ignored for SIG(0) records.
+
+
+
+
+Wellington                  Standards Track                     [Page 2]
+
+RFC 3008                DNSSEC Signing Authority           November 2000
+
+
+2.5 - Signature Expiration and Inception
+
+   The current time at the time of validation MUST lie within the
+   validity period bounded by the inception and expiration times.
+
+2.6 - Key Tag
+
+   There are no restrictions on the Key Tag field, although it is
+   possible that future algorithms will impose constraints.
+
+2.7 - Signer's Name
+
+   The signer's name field of a data SIG MUST contain the name of the
+   zone to which the data and signature belong.  The combination of
+   signer's name, key tag, and algorithm MUST identify a zone key if the
+   SIG is to be considered material.  The only exception that the
+   signer's name field in a SIG KEY at a zone apex SHOULD contain the
+   parent zone's name, unless the KEY set is self-signed.  This document
+   defines a standard policy for DNSSEC validation; local policy may
+   override the standard policy.
+
+   There are no restrictions on the signer field of a SIG(0) record.
+   The combination of signer's name, key tag, and algorithm MUST
+   identify a key if this SIG(0) is to be processed.
+
+2.8 - Signature
+
+   There are no restrictions on the signature field.  The signature will
+   be verified at some point, but does not need to be examined prior to
+   verification unless a future algorithm imposes constraints.
+
+3 - The Signing KEY Record
+
+   Once a signature has been examined and its fields validated (but
+   before the signature has been verified), the resolver attempts to
+   locate a KEY that matches the signer name, key tag, and algorithm
+   fields in the SIG.  If one is not found, the SIG cannot be verified
+   and is considered immaterial.  If KEYs are found, several fields of
+   the KEY record MUST have specific values if the SIG is to be
+   considered material and authorized.  If there are multiple KEYs, the
+   following checks are performed on all of them, as there is no way to
+   determine which one generated the signature until the verification is
+   performed.
+
+
+
+
+
+
+
+
+Wellington                  Standards Track                     [Page 3]
+
+RFC 3008                DNSSEC Signing Authority           November 2000
+
+
+3.1 - Type Flags
+
+   The signing KEY record MUST have a flags value of 00 or 01
+   (authentication allowed, confidentiality optional) [RFC2535, 3.1.2].
+   A DNSSEC resolver MUST only trust signatures generated by keys that
+   are permitted to authenticate data.
+
+3.2 - Name Flags
+
+   The interpretation of this field is considerably different for data
+   SIGs and SIG(0) records.
+
+3.2.1 - Data SIG
+
+   If the SIG record covers an RRset, the name type of the associated
+   KEY MUST be 01 (zone) [RFC2535, 3.1.2].  This updates RFC 2535,
+   section 2.3.6.  The DNSSEC validation process performed by a resolver
+   MUST ignore all keys that are not zone keys unless local policy
+   dictates otherwise.
+
+   The primary reason that RFC 2535 allows host and user keys to
+   generate material DNSSEC signatures is to allow dynamic update
+   without online zone keys; that is, avoid storing private keys in an
+   online server.  The desire to avoid online signing keys cannot be
+   achieved, though, because they are necessary to sign NXT and SOA sets
+   [RFC3007].  These online zone keys can sign any incoming data.
+   Removing the goal of having no online keys removes the reason to
+   allow host and user keys to generate material signatures.
+
+   Limiting material signatures to zone keys simplifies the validation
+   process.  The length of the verification chain is bounded by the
+   name's label depth.  The authority of a key is clearly defined; a
+   resolver does not need to make a potentially complicated decision to
+   determine whether a key has the proper authority to sign data.
+
+   Finally, there is no additional flexibility granted by allowing
+   host/user key generated material signatures.  As long as users and
+   hosts have the ability to authenticate update requests to the primary
+   zone server, signatures by zone keys are sufficient to protect the
+   integrity of the data to the world at large.
+
+3.2.2 - SIG(0)
+
+   If the SIG record is a SIG(0) protecting a message, the name type of
+   the associated KEY SHOULD be 00 (user) or 10 (host/entity).
+   Transactions are initiated by a host or user, not a zone, so zone
+   keys SHOULD not generate SIG(0) records.
+
+
+
+
+Wellington                  Standards Track                     [Page 4]
+
+RFC 3008                DNSSEC Signing Authority           November 2000
+
+
+   A client is either explicitly executed by a user or on behalf of a
+   host, therefore the name type of a SIG(0) generated by a client
+   SHOULD be either user or host.  A nameserver is associated with a
+   host, and its use of SIG(0) is not associated with a particular zone,
+   so the name type of a SIG(0) generated by a nameserver SHOULD be
+   host.
+
+3.3 - Signatory Flags
+
+   This document does not assign any values to the signatory field, nor
+   require any values to be present.
+
+3.4 - Protocol
+
+   The signing KEY record MUST have a protocol value of 3 (DNSSEC) or
+   255 (ALL).  If a key is not specified for use with DNSSEC, a DNSSEC
+   resolver MUST NOT trust any signature that it generates.
+
+3.5 - Algorithm Number
+
+   The algorithm field MUST be identical to that of the generated SIG
+   record, and MUST meet all requirements for an algorithm value in a
+   SIG record.
+
+4 - Security Considerations
+
+   This document defines a standard baseline for a DNSSEC capable
+   resolver.  This is necessary for a thorough security analysis of
+   DNSSEC, if one is to be done.
+
+   Specifically, this document places additional restrictions on SIG
+   records that a resolver must validate before the signature can be
+   considered worthy of DNSSEC trust.  This simplifies the protocol,
+   making it more robust and able to withstand scrutiny by the security
+   community.
+
+5 - Acknowledgements
+
+   The author would like to thank the following people for review and
+   informative comments (in alphabetical order):
+
+   Olafur Gudmundsson
+   Ed Lewis
+
+
+
+
+
+
+
+
+Wellington                  Standards Track                     [Page 5]
+
+RFC 3008                DNSSEC Signing Authority           November 2000
+
+
+6 - References
+
+   [RFC1034]  Mockapetris, P., "Domain Names - Concepts and Facilities",
+              STD 13, RFC 1034, November 1987.
+
+   [RFC1035]  Mockapetris, P., "Domain Names - Implementation and
+              Specification", STD 13, RFC 1035, November 1987.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2136]  Vixie (Ed.), P., Thomson, S., Rekhter, Y. and J. Bound,
+              "Dynamic Updates in the Domain Name System", RFC 2136,
+              April 1997.
+
+   [RFC2535]  Eastlake, D., "Domain Name System Security Extensions",
+              RFC 2535, March 1999.
+
+   [RFC2931]  Eastlake, D., "DNS Request and Transaction Signatures
+              (SIG(0)s )", RFC 2931, September 2000.
+
+   [RFC3007]      Wellington, B., "Simple Secure Domain Name System
+              (DNS) Dynamic Update", RFC 3007, November 2000.
+
+7 - Author's Address
+
+   Brian Wellington
+   Nominum, Inc.
+   950 Charter Street
+   Redwood City, CA 94063
+
+   Phone: +1 650 381 6022
+   EMail: Brian.Wellington@nominum.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wellington                  Standards Track                     [Page 6]
+
+RFC 3008                DNSSEC Signing Authority           November 2000
+
+
+8  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2000).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wellington                  Standards Track                     [Page 7]
+
diff --git a/doc/rfc/rfc3071.txt b/doc/rfc/rfc3071.txt
new file mode 100644
index 0000000..2c4d52f
--- /dev/null
+++ b/doc/rfc/rfc3071.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+Network Working Group                                         J. Klensin
+Request for Comments: 3071                                 February 2001
+Category: Informational
+
+
+      Reflections on the DNS, RFC 1591, and Categories of Domains
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2001).  All Rights Reserved.
+
+Abstract
+
+   RFC 1591, "Domain Name System Structure and Delegation", laid out the
+   basic administrative design and principles for the allocation and
+   administration of domains, from the top level down.  It was written
+   before the introduction of the world wide web (WWW) and rapid growth
+   of the Internet put significant market, social, and political
+   pressure on domain name allocations.  In recent years, 1591 has been
+   cited by all sides in various debates, and attempts have been made by
+   various bodies to update it or adjust its provisions, sometimes under
+   pressures that have arguably produced policies that are less well
+   thought out than the original.  Some of those efforts have begun from
+   misconceptions about the provisions of 1591 or the motivation for
+   those provisions.  The current directions of the Internet Corporation
+   for Assigned Names and Numbers (ICANN) and other groups who now
+   determine the Domain Name System (DNS) policy directions appear to be
+   drifting away from the policies and philosophy of 1591.  This
+   document is being published primarily for historical context and
+   comparative purposes, essentially to document some thoughts about how
+   1591 might have been interpreted and adjusted by the Internet
+   Assigned Numbers Authority (IANA) and ICANN to better reflect today's
+   world while retaining characteristics and policies that have proven
+   to be effective in supporting Internet growth and stability.  An
+   earlier variation of this memo was submitted to ICANN as a comment on
+   its evolving Top-level Domain (TLD) policies.
+
+
+
+
+
+
+
+
+
+Klensin                      Informational                      [Page 1]
+
+RFC 3071          Reflections on the DNS and RFC 1591      February 2001
+
+
+1.  Introduction
+
+   RFC 1591 [1] has been heavily discussed and referenced in the last
+   year or two, especially in discussions within ICANN and its
+   predecessors about the creation, delegation, and management of top-
+   level domains.  In particular, the ICANN Domain Name Supporting
+   Organization (DNSO), and especially its ccTLD constituency, have been
+   the home of many discussions in which 1591 and interpretations of it
+   have been cited in support of a variety of sometimes-contradictory
+   positions.  During that period, other discussions have gone on to try
+   to reconstruct the thinking that went into RFC 1591.  Those in turn
+   have led me and others to muse on how that original thinking might
+   relate to some of the issues being raised.  1591 is, I believe, one
+   of Jon Postel's masterpieces, drawing together very different
+   philosophies (e.g., his traditional view that people are basically
+   reasonable and will do the right thing if told what it is with some
+   stronger mechanisms when that model is not successful) into a single
+   whole.
+
+   RFC 1591 was written in the context of the assumption that what it
+   described as generic TLDs would be bound to policies and categories
+   of registration (see the "This domain is intended..."  text in
+   section 2) while ccTLDs were expected to be used primarily to support
+   users and uses within and for a country and its residents.  The
+   notion that different domains would be run in different ways --albeit
+   within the broad contexts of "public service on behalf of the
+   Internet community" and "trustee... for the global Internet
+   community"-- was considered a design feature and a safeguard against
+   a variety of potential abuses.  Obviously the world has changed in
+   many ways in the seven or eight years since 1591 was written.  In
+   particular, the Internet has become more heavily used and, because
+   the design of the world wide web has put domain names in front of
+   users, top-level domain names and registrations in them have been
+   heavily in demand: not only has the number of hosts increased
+   dramatically during that time, but the ratio between registered
+   domain names and physical hosts has increased very significantly.
+
+   The issues 1591 attempted to address when it was written and those we
+   face today have not changed significantly in principle.  But one
+   alternative to present trends would be to take a step back to refine
+   it into a model that can function effectively today.  Therefore, it
+   may be useful to try to reconstruct 1591's principles and think about
+   their applicability today as a model that could continue to be
+   applied: not because it is historically significant, but because many
+   of its elements have proven to work reasonably well, even in
+   difficult situations.  In particular, for many domains (some in
+   1591's "generic" list and others in its "country code" category) the
+   notion of "public service" --expected then to imply being carried out
+
+
+
+Klensin                      Informational                      [Page 2]
+
+RFC 3071          Reflections on the DNS and RFC 1591      February 2001
+
+
+   at no or minimal cost to the users, not merely on a non-profit
+   basis-- has yielded to profitability calculations.  And, in most of
+   the rest, considerations of at least calculating and recovering costs
+   have crept in.  While many of us feel some nostalgia for the old
+   system, it is clear that its days are waning if not gone: perhaps the
+   public service notions as understood when 1591 was written just don't
+   scale to rapid internet growth and very large numbers of
+   yregistrations.
+
+   In particular, some ccTLDs have advertised for registrations outside
+   the designated countries (or other entities), while others have made
+   clear decisions to allow registrations by non-nationals.  These
+   decisions and others have produced protests from many sides,
+   suggesting, in turn, that a recategorization is in order.  For
+   example, we have heard concerns by governments and managers of
+   traditional, "public service", in-country, ccTLDs about excessive
+   ICANN interference and fears of being forced to conform to
+   internationally-set policies for dispute resolution when their
+   domestic ones are considered more appropriate.  We have also heard
+   concerns from registrars and operators of externally-marketed ccTLDs
+   about unreasonable government interference and from gTLD registrars
+   and registries about unreasonable competition from aggressively
+   marketed ccTLDs.  The appropriate distinction is no longer between
+   what RFC 1591 described as "generic" TLDs (but which were really
+   intended to be "purpose-specific", a term I will use again below) and
+   ccTLDs but among:
+
+      (i) true "generic" TLDs, in which any registration is acceptable
+      and, ordinarily, registrations from all sources are actively
+      promoted.  This list currently includes (the formerly purpose-
+      specific) COM, NET, and ORG, and some ccTLDs.  There have been
+      proposals from time to time for additional TLDs of this variety in
+      which, as with COM (and, more recently, NET and ORG) anyone
+      (generally subject only to name conflicts and national law) could
+      register who could pay the fees.
+
+      (ii) purpose-specific TLDs, in which registration is accepted only
+      from organizations or individuals meeting particular
+      qualifications, but where those qualifications are not tied to
+      national boundaries.  This list currently includes INT, EDU, the
+      infrastructure domain ARPA, and, arguably, the specialized US
+      Government TLDs MIL and GOV.  There have been proposals from time
+      to time for other international TLDs of this variety, e.g., for
+      medical entities such as physicians and hospitals and for museums.
+      ICANN has recently approved several TLDs of this type and
+      describes them as "sponsored" TLDs.
+
+
+
+
+
+Klensin                      Informational                      [Page 3]
+
+RFC 3071          Reflections on the DNS and RFC 1591      February 2001
+
+
+      (iii) Country domains, operated according to the original
+      underlying assumptions of 1591, i.e., registrants are largely
+      expected to be people or other entities within the country.  While
+      external registrations might be accepted by some of these, the
+      country does not aggressively advertise for such registrations,
+      nor does anyone expect to derive significant fee revenue from
+      them.  All current domains in this category are ccTLDs, but not
+      all ccTLDs are in this category.
+
+   These categories are clearly orthogonal to the association between
+   the use of the IS 3166-1 registered code list [2] and two-letter
+   "country" domain names.  If that relationship is to be maintained
+   (and I believe it is desirable), the only inherent requirement is
+   that no two-letter TLDs be created except from that list (in order to
+   avoid future conflicts).  ICANN should control the allocation and
+   delegation of TLDs using these, and other, criteria, but only
+   registered 3166-1 two letter codes should be used as two-letter TLDs.
+
+2. Implications of the Categories
+
+   If we had adopted this type of three-way categorization and could
+   make it work, I believe it would have presented several opportunities
+   for ICANN and the community more generally to reduce controversies
+   and move forward.  Of course, there will be cases where the
+   categorization of a particular domain and its operating style will
+   not be completely clear-cut (see section 3, below).  But having ICANN
+   work out procedures for dealing with those (probably few) situations
+   appears preferable to strategies that would tend to propel ICANN into
+   areas that are beyond its competence or that might require
+   significant expansion of its mandate.
+
+   First, the internally-operated ccTLDs (category iii above) should not
+   be required to have much interaction with ICANN or vice versa.  Once
+   a domain of this sort is established and delegated, and assuming that
+   the "admin contact in the country" rule is strictly observed, the
+   domain should be able to function effectively without ICANN
+   intervention or oversight.  In particular, while a country might
+   choose to adopt the general ICANN policies about dispute resolution
+   or name management, issues that arise in these areas might equally
+   well be dealt with exclusively under applicable national laws.  If a
+   domain chooses to use ICANN services that cost resources to provide,
+   it should contribute to ICANN's support, but, if it does not, ICANN
+   should not presume to charge it for other than a reasonable fraction
+   of the costs to ICANN of operating the root, root servers, and any
+   directory systems that are generally agreed upon to be necessary and
+   in which the domain participates.
+
+
+
+
+
+Klensin                      Informational                      [Page 4]
+
+RFC 3071          Reflections on the DNS and RFC 1591      February 2001
+
+
+   By contrast, ccTLDs operated as generic domains ought to be treated
+   as generic domains.  ICANN dispute resolution and name management
+   policies and any special rules developed to protect the Internet
+   public in multiple registrar or registry situations should reasonably
+   apply.
+
+3.  Telling TLD types apart
+
+   If appropriate policies are adopted, ccTLDs operated as generic
+   domains (category (i) above) and those operated as country domains
+   (category (iii) above) ought to be able to be self-identified.  There
+   are several criteria that could be applied to make this
+   determination.  For example, either a domain is aggressively seeking
+   outside registrations or it is not and either the vast majority of
+   registrants in a domain are in-country or they are not.  One could
+   also think of this as the issue of having some tangible level of
+   presence in the jurisdiction - e.g., is the administrative contact
+   subject, in practical terms, to the in-country laws, or are the
+   registration rules such that it is reasonably likely that a court in
+   the jurisdiction of the country associated with the domain can
+   exercise jurisdiction and enforce a judgment against the registrant.
+
+   One (fairly non-intrusive) rule ICANN might well impose on all top-
+   level domains is that they identify and publish the policies they
+   intend to use.  E.g., registrants in a domain that will use the laws
+   of one particular country to resolve disputes should have a
+   reasonable opportunity to understand those policies prior to
+   registration and to make other arrangements (e.g., to register
+   elsewhere) if that mechanism for dispute resolution is not
+   acceptable.  Giving IANA (as the root registrar) incorrect
+   information about the purpose and use of a domain should be subject
+   to challenge, and should be grounds for reviewing the appropriateness
+   of the domain delegation, just as not acting consistently and
+   equitably provides such grounds under the original provisions of RFC
+   1591.
+
+   In order to ensure the availability of accurate and up-to-date
+   registration information the criteria must be consistent, and
+   consistent with more traditional gTLDs, for all nominally country
+   code domains operating as generic TLDs.
+
+4. The role of ICANN in country domains
+
+   ICANN (and IANA) should, as described above, have as little
+   involvement as possible in the direction of true country [code]
+   domains (i.e., category (iii)).  There is no particular reason why
+
+
+
+
+
+Klensin                      Informational                      [Page 5]
+
+RFC 3071          Reflections on the DNS and RFC 1591      February 2001
+
+
+   these domains should be subject to ICANN regulation beyond the basic
+   principles of 1591 and associated arrangements needed to ensure
+   Internet interoperability and stability.
+
+   ICANN's avoiding such involvement strengthens it: the desirability of
+   avoiding collisions with national sovereignty, determinations about
+   government legitimacy, and the authority of someone purportedly
+   writing on behalf of a government, is as important today as it was
+   when 1591 was written.  The alternatives take us quickly from
+   "administration" into "internet governance" or, in the case of
+   determining which claimant is the legitimate government of a country,
+   "international relations", and the reasons for not moving in that
+   particular direction are legion.
+
+5. The role of governments
+
+   The history of IANA strategy in handling ccTLDs included three major
+   "things to avoid" considerations:
+
+      * Never get involved in determining which entities were countries
+        and which ones were not.
+
+      * Never get involved in determining who was, or was not, the
+        legitimate government of a country.  And, more generally, avoid
+        deciding what entity --government, religion, commercial,
+        academic, etc.-- has what legitimacy or rights.
+
+      * If possible, never become involved in in-country disputes.
+        Instead, very strongly encourage internal parties to work
+        problems out among themselves.  At most, adopt a role as
+        mediator and educator, rather than judge, unless abuses are very
+        clear and clearly will not be settled by any internal mechanism.
+
+   All three considerations were obviously intended to avoid IANA's
+   being dragged into a political morass in which it had (and, I
+   suggest, has) no competence to resolve the issues and could only get
+   bogged down.  The first consideration was the most visible (and the
+   easiest) and was implemented by strict and careful adherence (see
+   below) to the ISO 3166 registered Country Code list.  If an entity
+   had a code, it was eligible to be registered with a TLD (although
+   IANA was free to apply additional criteria-most of them stated in
+   1591).  If it did not, there were no exceptions: the applicant's only
+   recourse was a discussion with the 3166 Registration Authority (now
+   Maintenance Agency, often known just as "3166/MA") or the UN
+   Statistical Office (now Statistics Bureau), not with IANA.
+
+
+
+
+
+
+Klensin                      Informational                      [Page 6]
+
+RFC 3071          Reflections on the DNS and RFC 1591      February 2001
+
+
+   There are actually five ccTLD exceptions to the strict rules.  One,
+   "UK", is historical: it predates the adoption of ISO 3166 for this
+   purpose.  The others --Ascension Island, Guernsey, Isle of Man, and
+   Jersey --are arguably, at least in retrospect, just mistakes.
+   Regardless of the historical reasons (about which there has been much
+   speculation), it is almost certainly the case that the right way to
+   handle mistakes of this sort is to acknowledge them and move on,
+   rather than trying to use them as precedents to justify more
+   mistakes.
+
+   This, obviously, is also the argument against use of the "reserved"
+   list (technically internal to the 3166 maintenance activity, and not
+   part of the Standard): since IANA (or ICANN) can ask that a name be
+   placed on that list, there is no rule of an absolute determination by
+   an external organization.  Purported countries can come to ICANN,
+   insist on having delegations made and persuade ICANN to ask that the
+   names be reserved.  Then, since the reserved name would exist, they
+   could insist that the domain be delegated.  Worse, someone could use
+   another organization to request reservation of the name by 3166/MA;
+   once it was reserved, ICANN might be hard-pressed not to do the
+   delegation.  Of course, ICANN could (and probably would be forced to)
+   adopt additional criteria other than appearance on the "reserved
+   list" in order to delegate such domains.  But those criteria would
+   almost certainly be nearly equivalent to determining which applicants
+   were legitimate and stable enough to be considered a country, the
+   exact decision process that 1591 strove to avoid.
+
+   The other two considerations were more subtle and not always
+   successful: from time to time, both before and after the formal
+   policy shifted toward "governments could have their way", IANA
+   received letters from people purporting to be competent government
+   authorities asking for changes.  Some of them turned out later to not
+   have that authority or appropriate qualifications.  The assumption of
+   1591 itself was that, if the "administrative contact in country" rule
+   was strictly observed, as was the rule that delegation changes
+   requested by the administrative contact would be honored, then, if a
+   government _really_ wanted to assert itself, it could pressure the
+   administrative contact into requesting the changes it wanted, using
+   whatever would pass for due process in that country.  And the ability
+   to apply that process and pressure would effectively determine who
+   was the government and who wasn't, and would do so far more
+   effectively than any IANA evaluation of, e.g., whether the letterhead
+   on a request looked authentic (and far more safely for ICANN than
+   asking the opinion of any particular other government or selection of
+   governments).
+
+
+
+
+
+
+Klensin                      Informational                      [Page 7]
+
+RFC 3071          Reflections on the DNS and RFC 1591      February 2001
+
+
+   Specific language in 1591 permitted IANA to adopt a "work it out
+   yourselves; if we have to decide, we will strive for a solution that
+   is not satisfactory to any party" stance.  That approach was used
+   successfully, along with large doses of education, on many occasions
+   over the years, to avoid IANA's having to assume the role of judge
+   between conflicting parties.
+
+   Similar principles could be applied to the boundary between country-
+   code-based generic TLDs and country domains.  Different countries,
+   under different circumstances, might prefer to operate the ccTLD
+   either as a national service or as a profit center where the
+   "customers" were largely external.  Whatever decisions were made
+   historically, general Internet stability argues that changes should
+   not be made lightly.  At the same time, if a government wishes to
+   make a change, the best mechanism for doing so is not to involve
+   ICANN in a potential determination of legitimacy (or even to have
+   ICANN's Government Advisory Committee (GAC) try to formally make that
+   decision for individual countries) but for the relevant government to
+   use its own procedures to persuade the administrative contact to
+   request the change and for IANA to promptly and efficiently carry out
+   requests made by administrative contacts.
+
+6. Implications for the current ICANN DNSO structure.
+
+   The arguments by some of the ccTLD administrators that they are
+   different from the rest of the ICANN and DNSO structures are (in this
+   model) correct: they are different.  The ccTLDs that are operating as
+   generic TLDs should be separated from the ccTLD constituency and
+   joined to the gTLD constituency.  The country ccTLDs should be
+   separated from ICANN's immediate Supporting Organization structure,
+   and operate in a parallel and advisory capacity to ICANN, similar to
+   the arrangements used with the GAC.  The DNSO and country TLDs should
+   not be required to interact with each other except on a mutually
+   voluntary basis and, if ICANN needs interaction or advice from some
+   of all of those TLDs, it would be more appropriate to get it in the
+   form of an advisory body like the GAC rather than as DNSO
+   constituency.
+
+7. References
+
+   [1] Postel, J., "Domain Name System Structure and Delegation", RFC
+       1591, March 1994.
+
+   [2] ISO 3166. ISO 3166-1. Codes for the representation of names of
+       countries and their subdivisions - Part 1: Country codes (1997).
+
+
+
+
+
+
+Klensin                      Informational                      [Page 8]
+
+RFC 3071          Reflections on the DNS and RFC 1591      February 2001
+
+
+8. Acknowledgements and disclaimer
+
+   These reflections have been prepared in my individual capacity and do
+   not necessarily reflect the views of my past or present employers.
+   Several people, including Randy Bush, Theresa Swinehart, Zita Wenzel,
+   Geoff Huston, Havard Eidnes, and several anonymous reviewers, made
+   suggestions or offered editorial comments about earlier versions of
+   this document.  Cord Wischhoefer, of the ISO 3166/MA, was also kind
+   enough to look at the draft and supplied some useful details.  Those
+   comments contributed significantly to whatever clarity the document
+   has, but the author bears responsibility for the selection of
+   comments which were ultimately incorporated and the way in which the
+   conclusions were presented.
+
+9.  Security Considerations
+
+   This memo addresses the context for a set of administrative decisions
+   and procedures, and does not raise or address security issues.
+
+10. Author's Address
+
+   John C. Klensin
+   1770 Massachusetts Ave, Suite 322
+   Cambridge, MA 02140, USA
+
+   EMail: klensin@jck.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Klensin                      Informational                      [Page 9]
+
+RFC 3071          Reflections on the DNS and RFC 1591      February 2001
+
+
+11. Full Copyright Statement
+
+   Copyright (C) The Internet Society 2001. All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others provided that the above copyright notice and this paragraph
+   are included on all such copies.  However, this document itself may
+   not be modified in any way, such as by removing the copyright notice
+   or references to the Internet Society or other Internet
+   organizations, except as required to translate it into languages
+   other than English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR  IMPLIED, INCLUDING
+   BUT NOT  LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY  IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Klensin                      Informational                     [Page 10]
+
diff --git a/doc/rfc/rfc3090.txt b/doc/rfc/rfc3090.txt
new file mode 100644
index 0000000..08008f7
--- /dev/null
+++ b/doc/rfc/rfc3090.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+Network Working Group                                           E. Lewis
+Request for Comments: 3090                                      NAI Labs
+Category: Standards Track                                     March 2001
+
+
+          DNS Security Extension Clarification on Zone Status
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2001).  All Rights Reserved.
+
+Abstract
+
+   The definition of a secured zone is presented, clarifying and
+   updating sections of RFC 2535.  RFC 2535 defines a zone to be secured
+   based on a per algorithm basis, e.g., a zone can be secured with RSA
+   keys, and not secured with DSA keys.  This document changes this to
+   define a zone to be secured or not secured regardless of the key
+   algorithm used (or not used).  To further simplify the determination
+   of a zone's status, "experimentally secure" status is deprecated.
+
+1 Introduction
+
+   Whether a DNS zone is "secured" or not is a question asked in at
+   least four contexts.  A zone administrator asks the question when
+   configuring a zone to use DNSSEC.  A dynamic update server asks the
+   question when an update request arrives, which may require DNSSEC
+   processing.  A delegating zone asks the question of a child zone when
+   the parent enters data indicating the status the child.  A resolver
+   asks the question upon receipt of data belonging to the zone.
+
+1.1 When a Zone's Status is Important
+
+   A zone administrator needs to be able to determine what steps are
+   needed to make the zone as secure as it can be.  Realizing that due
+   to the distributed nature of DNS and its administration, any single
+   zone is at the mercy of other zones when it comes to the appearance
+   of security.  This document will define what makes a zone qualify as
+   secure.
+
+
+
+
+Lewis                       Standards Track                     [Page 1]
+
+RFC 3090         DNS Security Extension on Zone Status        March 2001
+
+
+   A name server performing dynamic updates needs to know whether a zone
+   being updated is to have signatures added to the updated data, NXT
+   records applied, and other required processing.  In this case, it is
+   conceivable that the name server is configured with the knowledge,
+   but being able to determine the status of a zone by examining the
+   data is a desirable alternative to configuration parameters.
+
+   A delegating zone is required to indicate whether a child zone is
+   secured.  The reason for this requirement lies in the way in which a
+   resolver makes its own determination about a zone (next paragraph).
+   To shorten a long story, a parent needs to know whether a child
+   should be considered secured.  This is a two part question.  Under
+   what circumstances does a parent consider a child zone to be secure,
+   and how does a parent know if the child conforms?
+
+   A resolver needs to know if a zone is secured when the resolver is
+   processing data from the zone.  Ultimately, a resolver needs to know
+   whether or not to expect a usable signature covering the data.  How
+   this determination is done is out of the scope of this document,
+   except that, in some cases, the resolver will need to contact the
+   parent of the zone to see if the parent states that the child is
+   secured.
+
+1.2 Islands of Security
+
+   The goal of DNSSEC is to have each zone secured, from the root zone
+   and the top-level domains down the hierarchy to the leaf zones.
+   Transitioning from an unsecured DNS, as we have now, to a fully
+   secured - or "as much as will be secured" - tree will take some time.
+   During this time, DNSSEC will be applied in various locations in the
+   tree, not necessarily "top down."
+
+   For example, at a particular instant, the root zone and the "test."
+   TLD might be secured, but region1.test. might not be.  (For
+   reference, let's assume that region2.test. is secured.)  However,
+   subarea1.region1.test. may have gone through the process of becoming
+   secured, along with its delegations.  The dilemma here is that
+   subarea1 cannot get its zone keys properly signed as its parent zone,
+   region1, is not secured.
+
+   The colloquial phrase describing the collection of contiguous secured
+   zones at or below subarea1.region1.test. is an "island of security."
+   The only way in which a DNSSEC resolver will come to trust any data
+   from this island is if the resolver is pre-configured with the zone
+   key(s) for subarea1.region1.test., i.e., the root of the island of
+   security.  Other resolvers (not so configured) will recognize this
+   island as unsecured.
+
+
+
+
+Lewis                       Standards Track                     [Page 2]
+
+RFC 3090         DNS Security Extension on Zone Status        March 2001
+
+
+   An island of security begins with one zone whose public key is pre-
+   configured in resolvers.  Within this island are subzones which are
+   also secured.  The "bottom" of the island is defined by delegations
+   to unsecured zones.  One island may also be on top of another -
+   meaning that there is at least one unsecured zone between the bottom
+   of the upper island and the root of the lower secured island.
+
+   Although both subarea1.region1.test. and region2.test. have both been
+   properly brought to a secured state by the administering staff, only
+   the latter of the two is actually "globally" secured - in the sense
+   that all DNSSEC resolvers can and will verify its data.  The former,
+   subarea1, will be seen as secured by a subset of those resolvers,
+   just those appropriately configured.  This document refers to such
+   zones as being "locally" secured.
+
+   In RFC 2535, there is a provision for "certification authorities,"
+   entities that will sign public keys for zones such as subarea1.
+   There is another document, [RFC3008], that restricts this activity.
+   Regardless of the other document, resolvers would still need proper
+   configuration to be able to use the certification authority to verify
+   the data for the subarea1 island.
+
+1.2.1 Determining the closest security root
+
+   Given a domain, in order to determine whether it is secure or not,
+   the first step is to determine the closest security root.  The
+   closest security root is the top of an island of security whose name
+   has the most matching (in order from the root) right-most labels to
+   the given domain.
+
+   For example, given a name "sub.domain.testing.signed.exp.test.", and
+   given the secure roots "exp.test.", "testing.signed.exp.test." and
+   "not-the-same.xy.", the middle one is the closest.  The first secure
+   root shares 2 labels, the middle 4, and the last 0.
+
+   The reason why the closest is desired is to eliminate false senses of
+   insecurity because of a NULL key.  Continuing with the example, the
+   reason both "testing..." and "exp.test." are listed as secure root is
+   presumably because "signed.exp.test." is unsecured (has a NULL key).
+   If we started to descend from "exp.test." to our given domain
+   (sub...), we would encounter a NULL key and conclude that sub... was
+   unsigned.  However, if we descend from "testing..." and find keys
+   "domain...." then we can conclude that "sub..." is secured.
+
+   Note that this example assumes one-label deep zones, and assumes that
+   we do not configure overlapping islands of security.  To be clear,
+   the definition given should exclude "short.xy.test." from being a
+   closest security root for "short.xy." even though 2 labels match.
+
+
+
+Lewis                       Standards Track                     [Page 3]
+
+RFC 3090         DNS Security Extension on Zone Status        March 2001
+
+
+   Overlapping islands of security introduce no conceptually interesting
+   ideas and do not impact the protocol in anyway.  However, protocol
+   implementers are advised to make sure their code is not thrown for a
+   loop by overlaps.  Overlaps are sure to be configuration problems as
+   islands of security grow to encompass larger regions of the name
+   space.
+
+1.3 Parent Statement of Child Security
+
+   In 1.1 of this document, there is the comment "the parent states that
+   the child is secured."  This has caused quite a bit of confusion.
+
+   The need to have the parent "state" the status of a child is derived
+   from the following observation.  If you are looking to see if an
+   answer is secured, that it comes from an "island of security" and is
+   properly signed, you must begin at the (appropriate) root of the
+   island of security.
+
+   To find the answer you are inspecting, you may have to descend
+   through zones within the island of security.  Beginning with the
+   trusted root of the island, you descend into the next zone down.  As
+   you trust the upper zone, you need to get data from it about the next
+   zone down, otherwise there is a vulnerable point in which a zone can
+   be hijacked. When or if you reach a point of traversing from a
+   secured zone to an unsecured zone, you have left the island of
+   security and should conclude that the answer is unsecured.
+
+   However, in RFC 2535, section 2.3.4, these words seem to conflict
+   with the need to have the parent "state" something about a child:
+
+      There MUST be a zone KEY RR, signed by its superzone, for every
+      subzone if the superzone is secure.  This will normally appear in
+      the subzone and may also be included in the superzone.  But, in
+      the case of an unsecured subzone which can not or will not be
+      modified to add any security RRs, a KEY declaring the subzone to
+      be unsecured MUST appear with the superzone signature in the
+      superzone, if the superzone is secure.
+
+   The confusion here is that in RFC 2535, a secured parent states that
+   a child is secured by SAYING NOTHING ("may also be" as opposed to
+   "MUST also be").  This is counter intuitive, the fact that an absence
+   of data means something is "secured."  This notion, while acceptable
+   in a theoretic setting has met with some discomfort in an operation
+   setting.  However, the use of "silence" to state something does
+   indeed work in this case, so there hasn't been sufficient need
+   demonstrated to change the definition.
+
+
+
+
+
+Lewis                       Standards Track                     [Page 4]
+
+RFC 3090         DNS Security Extension on Zone Status        March 2001
+
+
+1.4 Impact on RFC 2535
+
+   This document updates sections of RFC 2535.  The definition of a
+   secured zone is an update to section 3.4 of the RFC.  Section 3.4 is
+   updated to eliminate the definition of experimental keys and
+   illustrate a way to still achieve the functionality they were
+   designed to provide.  Section 3.1.3 is updated by the specifying the
+   value of the protocol octet in a zone key.
+
+1.5 "MUST" and other key words
+
+   The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY"
+   in this document are to be interpreted as described in [RFC 2119].
+   Currently, only "MUST" is used in this document.
+
+2 Status of a Zone
+
+   In this section, rules governing a zone's DNSSEC status are
+   presented.  There are three levels of security defined: global,
+   local, and unsecured.  A zone is globally secure when it complies
+   with the strictest set of DNSSEC processing rules.  A zone is locally
+   secured when it is configured in such a way that only resolvers that
+   are appropriately configured see the zone as secured.  All other
+   zones are unsecured.
+
+   Note: there currently is no document completely defining DNSSEC
+   verification rules.  For the purposes of this document, the strictest
+   rules are assumed to state that the verification chain of zone keys
+   parallels the delegation tree up to the root zone.  (See 2.b below.)
+   This is not intended to disallow alternate verification paths, just
+   to establish a baseline definition.
+
+   To avoid repetition in the rules below, the following terms are
+   defined.
+
+   2.a Zone signing KEY RR - A KEY RR whose flag field has the value 01
+   for name type (indicating a zone key) and either value 00 or value 01
+   for key type (indicating a key permitted to authenticate data).  (See
+   RFC 2535, section 3.1.2).  The KEY RR also has a protocol octet value
+   of DNSSEC (3) or ALL (255).
+
+   The definition updates RFC 2535's definition of a zone key.  The
+   requirement that the protocol field be either DNSSEC or ALL is a new
+   requirement (a change to section 3.1.3.)
+
+   2.b On-tree Validation - The authorization model in which only the
+   parent zone is recognized to supply a DNSSEC-meaningful signature
+   that is used by a resolver to build a chain of trust from the child's
+
+
+
+Lewis                       Standards Track                     [Page 5]
+
+RFC 3090         DNS Security Extension on Zone Status        March 2001
+
+
+   keys to a recognized root of security.  The term "on-tree" refers to
+   following the DNS domain hierarchy (upwards) to reach a trusted key,
+   presumably the root key if no other key is available.  The term
+   "validation" refers to the digital signature by the parent to prove
+   the integrity, authentication and authorization of the child's key to
+   sign the child's zone data.
+
+   2.c Off-tree Validation - Any authorization model that permits domain
+   names other than the parent's to provide a signature over a child's
+   zone keys that will enable a resolver to trust the keys.
+
+2.1 Globally Secured
+
+   A globally secured zone, in a nutshell, is a zone that uses only
+   mandatory to implement algorithms (RFC 2535, section 3.2) and relies
+   on a key certification chain that parallels the delegation tree (on-
+   tree validation).  Globally secured zones are defined by the
+   following rules.
+
+   2.1.a. The zone's apex MUST have a KEY RR set.  There MUST be at
+   least one zone signing KEY RR (2.a) of a mandatory to implement
+   algorithm in the set.
+
+   2.1.b. The zone's apex KEY RR set MUST be signed by a private key
+   belonging to the parent zone.  The private key's public companion
+   MUST be a zone signing KEY RR (2.a) of a mandatory to implement
+   algorithm and owned by the parent's apex.
+
+   If a zone cannot get a conforming signature from the parent zone, the
+   child zone cannot be considered globally secured.  The only exception
+   to this is the root zone, for which there is no parent zone.
+
+   2.1.c. NXT records MUST be deployed throughout the zone.  (Clarifies
+   RFC 2535, section 2.3.2.)  Note: there is some operational discomfort
+   with the current NXT record.  This requirement is open to
+   modification when two things happen.  First, an alternate mechanism
+   to the NXT is defined and second, a means by which a zone can
+   indicate that it is using an alternate method.
+
+   2.1.d. Each RR set that qualifies for zone membership MUST be signed
+   by a key that is in the apex's KEY RR set and is a zone signing KEY
+   RR (2.a) of a mandatory to implement algorithm.  (Updates 2535,
+   section 2.3.1.)
+
+   Mentioned earlier, the root zone is a special case.  The root zone
+   will be considered to be globally secured provided that if conforms
+   to the rules for locally secured, with the exception that rule 2.1.a.
+   be also met (mandatory to implement requirement).
+
+
+
+Lewis                       Standards Track                     [Page 6]
+
+RFC 3090         DNS Security Extension on Zone Status        March 2001
+
+
+2.2 Locally Secured
+
+   The term "locally" stems from the likely hood that the only resolvers
+   to be configured for a particular zone will be resolvers "local" to
+   an organization.
+
+   A locally secured zone is a zone that complies with rules like those
+   for a globally secured zone with the following exceptions.  The
+   signing keys may be of an algorithm that is not mandatory to
+   implement and/or the verification of the zone keys in use may rely on
+   a verification chain that is not parallel to the delegation tree
+   (off-tree validation).
+
+   2.2.a. The zone's apex MUST have a KEY RR set.  There MUST be at
+   least one zone signing KEY RR (2.a) in the set.
+
+   2.2.b. The zone's apex KEY RR set MUST be signed by a private key and
+   one of the following two subclauses MUST hold true.
+
+   2.2.b.1 The private key's public companion MUST be pre-configured in
+   all the resolvers of interest.
+
+   2.2.b.2 The private key's public companion MUST be a zone signing KEY
+   RR (2.a) authorized to provide validation of the zone's apex KEY RR
+   set, as recognized by resolvers of interest.
+
+   The previous sentence is trying to convey the notion of using a
+   trusted third party to provide validation of keys.  If the domain
+   name owning the validating key is not the parent zone, the domain
+   name must represent someone the resolver trusts to provide
+   validation.
+
+   2.2.c. NXT records MUST be deployed throughout the zone.  Note: see
+   the discussion following 2.1.c.
+
+   2.2.d. Each RR set that qualifies for zone membership MUST be signed
+   by a key that is in the apex's KEY RR set and is a zone signing KEY
+   RR (2.a).  (Updates 2535, section 2.3.1.)
+
+2.3 Unsecured
+
+   All other zones qualify as unsecured.  This includes zones that are
+   designed to be experimentally secure, as defined in a later section
+   on that topic.
+
+
+
+
+
+
+
+Lewis                       Standards Track                     [Page 7]
+
+RFC 3090         DNS Security Extension on Zone Status        March 2001
+
+
+2.4 Wrap up
+
+   The designation of globally secured, locally secured, and unsecured
+   are merely labels to apply to zones, based on their contents.
+   Resolvers, when determining whether a signature is expected or not,
+   will only see a zone as secured or unsecured.
+
+   Resolvers that follow the most restrictive DNSSEC verification rules
+   will only see globally secured zones as secured, and all others as
+   unsecured, including zones which are locally secured.  Resolvers that
+   are not as restrictive, such as those that implement algorithms in
+   addition to the mandatory to implement algorithms, will see some
+   locally secured zones as secured.
+
+   The intent of the labels "global" and "local" is to identify the
+   specific attributes of a zone.  The words are chosen to assist in the
+   writing of a document recommending the actions a zone administrator
+   take in making use of the DNS security extensions.  The words are
+   explicitly not intended to convey a state of compliance with DNS
+   security standards.
+
+3 Experimental Status
+
+   The purpose of an experimentally secured zone is to facilitate the
+   migration from an unsecured zone to a secured zone.  This distinction
+   is dropped.
+
+   The objective of facilitating the migration can be achieved without a
+   special designation of an experimentally secure status.
+   Experimentally secured is a special case of locally secured.  A zone
+   administrator can achieve this by publishing a zone with signatures
+   and configuring a set of test resolvers with the corresponding public
+   keys.  Even if the public key is published in a KEY RR, as long as
+   there is no parent signature, the resolvers will need some pre-
+   configuration to know to process the signatures.  This allows a zone
+   to be secured with in the sphere of the experiment, yet still be
+   registered as unsecured in the general Internet.
+
+4 IANA Considerations
+
+   This document does not request any action from an assigned number
+   authority nor recommends any actions.
+
+
+
+
+
+
+
+
+
+Lewis                       Standards Track                     [Page 8]
+
+RFC 3090         DNS Security Extension on Zone Status        March 2001
+
+
+5 Security Considerations
+
+   Without a means to enforce compliance with specified protocols or
+   recommended actions, declaring a DNS zone to be "completely" secured
+   is impossible.  Even if, assuming an omnipotent view of DNS, one can
+   declare a zone to be properly configured for security, and all of the
+   zones up to the root too, a misbehaving resolver could be duped into
+   believing bad data.  If a zone and resolver comply, a non-compliant
+   or subverted parent could interrupt operations.  The best that can be
+   hoped for is that all parties are prepared to be judged secure and
+   that security incidents can be traced to the cause in short order.
+
+6 Acknowledgements
+
+   The need to refine the definition of a secured zone has become
+   apparent through the efforts of the participants at two DNSSEC
+   workshops, sponsored by the NIC-SE (.se registrar), CAIRN (a DARPA-
+   funded research network), and other workshops.  Further discussions
+   leading to the document include Olafur Gudmundsson, Russ Mundy,
+   Robert Watson, and Brian Wellington.  Roy Arends, Ted Lindgreen and
+   others have contributed significant input via the namedroppers
+   mailing list.
+
+7 References
+
+   [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
+             STD 13, RFC 1034, November 1987.
+
+   [RFC1035] Mockapetris, P., "Domain Names - Implementation and
+             Specification", STD 13, RFC 1035, November 1987.
+
+   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+             Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2136] Vixie, P., (Ed.), Thomson, S., Rekhter, Y. and J. Bound,
+             "Dynamic Updates in the Domain Name System", RFC 2136,
+             April 1997.
+
+   [RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC
+             2535, March 1999.
+
+   [RFC3007] Wellington, B., "Simple Secure Domain Name System (DNS)
+             Dynamic Update", RFC 3007, November 2000.
+
+   [RFC3008] Wellington, B., "Domain Name System Security (DNSSEC)
+             Signing Authority", RFC 3008, November 2000.
+
+
+
+
+
+Lewis                       Standards Track                     [Page 9]
+
+RFC 3090         DNS Security Extension on Zone Status        March 2001
+
+
+10 Author's Address
+
+   Edward Lewis
+   NAI Labs
+   3060 Washington Road Glenwood
+   MD 21738
+
+   Phone: +1 443 259 2352
+   EMail: lewis@tislabs.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lewis                       Standards Track                    [Page 10]
+
+RFC 3090         DNS Security Extension on Zone Status        March 2001
+
+
+11 Full Copyright Statement
+
+   Copyright (C) The Internet Society (2001).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lewis                       Standards Track                    [Page 11]
+
diff --git a/doc/rfc/rfc3110.txt b/doc/rfc/rfc3110.txt
new file mode 100644
index 0000000..7646948
--- /dev/null
+++ b/doc/rfc/rfc3110.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Network Working Group                                    D. Eastlake 3rd
+Request for Comments: 3110                                      Motorola
+Obsoletes: 2537                                                 May 2001
+Category: Standards Track
+
+
+      RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS)
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2001).  All Rights Reserved.
+
+Abstract
+
+   This document describes how to produce RSA/SHA1 SIG resource records
+   (RRs) in Section 3 and, so as to completely replace RFC 2537,
+   describes how to produce RSA KEY RRs in Section 2.
+
+   Since the adoption of a Proposed Standard for RSA signatures in the
+   DNS (Domain Name Space), advances in hashing have been made.  A new
+   DNS signature algorithm is defined to make these advances available
+   in SIG RRs.  The use of the previously specified weaker mechanism is
+   deprecated.  The algorithm number of the RSA KEY RR is changed to
+   correspond to this new SIG algorithm.  No other changes are made to
+   DNS security.
+
+Acknowledgements
+
+   Material and comments from the following have been incorporated and
+   are gratefully acknowledged:
+
+      Olafur Gudmundsson
+
+      The IESG
+
+      Charlie Kaufman
+
+      Steve Wang
+
+
+
+
+
+D. Eastlake 3rd             Standards Track                     [Page 1]
+
+RFC 3110              RSA SIGs and KEYs in the DNS              May 2001
+
+
+Table of Contents
+
+   1. Introduction................................................... 2
+   2. RSA Public KEY Resource Records................................ 3
+   3. RSA/SHA1 SIG Resource Records.................................. 3
+   4. Performance Considerations..................................... 4
+   5. IANA Considerations............................................ 5
+   6. Security Considerations........................................ 5
+   References........................................................ 5
+   Author's Address.................................................. 6
+   Full Copyright Statement.......................................... 7
+
+1. Introduction
+
+   The Domain Name System (DNS) is the global hierarchical replicated
+   distributed database system for Internet addressing, mail proxy, and
+   other information [RFC1034, 1035, etc.].  The DNS has been extended
+   to include digital signatures and cryptographic keys as described in
+   [RFC2535].  Thus the DNS can now be secured and used for secure key
+   distribution.
+
+   Familiarity with the RSA and SHA-1 algorithms is assumed [Schneier,
+   FIP180] in this document.
+
+   RFC 2537 described how to store RSA keys and RSA/MD5 based signatures
+   in the DNS.  However, since the adoption of RFC 2537, continued
+   cryptographic research has revealed hints of weakness in the MD5
+   [RFC1321] algorithm used in RFC 2537.  The SHA1 Secure Hash Algorithm
+   [FIP180], which produces a larger hash, has been developed.  By now
+   there has been sufficient experience with SHA1 that it is generally
+   acknowledged to be stronger than MD5.  While this stronger hash is
+   probably not needed today in most secure DNS zones, critical zones
+   such a root, most top level domains, and some second and third level
+   domains, are sufficiently valuable targets that it would be negligent
+   not to provide what are generally agreed to be stronger mechanisms.
+   Furthermore, future advances in cryptanalysis and/or computer speeds
+   may require a stronger hash everywhere.  In addition, the additional
+   computation required by SHA1 above that required by MD5 is
+   insignificant compared with the computational effort required by the
+   RSA modular exponentiation.
+
+   This document describes how to produce RSA/SHA1 SIG RRs in Section 3
+   and, so as to completely replace RFC 2537, describes how to produce
+   RSA KEY RRs in Section 2.
+
+   Implementation of the RSA algorithm in DNS with SHA1 is MANDATORY for
+   DNSSEC.  The generation of RSA/MD5 SIG RRs as described in RFC 2537
+   is NOT RECOMMENDED.
+
+
+
+D. Eastlake 3rd             Standards Track                     [Page 2]
+
+RFC 3110              RSA SIGs and KEYs in the DNS              May 2001
+
+
+   The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", "NOT
+   RECOMMENDED", and "MAY" in this document are to be interpreted as
+   described in RFC 2119.
+
+2. RSA Public KEY Resource Records
+
+   RSA public keys are stored in the DNS as KEY RRs using algorithm
+   number 5 [RFC2535].  The structure of the algorithm specific portion
+   of the RDATA part of such RRs is as shown below.
+
+         Field             Size
+         -----             ----
+         exponent length   1 or 3 octets (see text)
+         exponent          as specified by length field
+         modulus           remaining space
+
+   For interoperability, the exponent and modulus are each limited to
+   4096 bits in length.  The public key exponent is a variable length
+   unsigned integer.  Its length in octets is represented as one octet
+   if it is in the range of 1 to 255 and by a zero octet followed by a
+   two octet unsigned length if it is longer than 255 bytes.  The public
+   key modulus field is a multiprecision unsigned integer.  The length
+   of the modulus can be determined from the RDLENGTH and the preceding
+   RDATA fields including the exponent.  Leading zero octets are
+   prohibited in the exponent and modulus.
+
+   Note: KEY RRs for use with RSA/SHA1 DNS signatures MUST use this
+   algorithm number (rather than the algorithm number specified in the
+   obsoleted RFC 2537).
+
+   Note: This changes the algorithm number for RSA KEY RRs to be the
+   same as the new algorithm number for RSA/SHA1 SIGs.
+
+3. RSA/SHA1 SIG Resource Records
+
+   RSA/SHA1 signatures are stored in the DNS using SIG resource records
+   (RRs) with algorithm number 5.
+
+   The signature portion of the SIG RR RDATA area, when using the
+   RSA/SHA1 algorithm, is calculated as shown below.  The data signed is
+   determined as specified in RFC 2535.  See RFC 2535 for fields in the
+   SIG RR RDATA which precede the signature itself.
+
+         hash = SHA1 ( data )
+
+         signature = ( 01 | FF* | 00 | prefix | hash ) ** e (mod n)
+
+
+
+
+
+D. Eastlake 3rd             Standards Track                     [Page 3]
+
+RFC 3110              RSA SIGs and KEYs in the DNS              May 2001
+
+
+   where SHA1 is the message digest algorithm documented in [FIP180],
+   "|" is concatenation, "e" is the private key exponent of the signer,
+   and "n" is the modulus of the signer's public key.  01, FF, and 00
+   are fixed octets of the corresponding hexadecimal value.  "prefix" is
+   the ASN.1 BER SHA1 algorithm designator prefix required in PKCS1
+   [RFC2437], that is,
+
+         hex 30 21 30 09 06 05 2B 0E 03 02 1A 05 00 04 14
+
+   This prefix is included to make it easier to use standard
+   cryptographic libraries.  The FF octet MUST be repeated the maximum
+   number of times such that the value of the quantity being
+   exponentiated is one octet shorter than the value of n.
+
+   (The above specifications are identical to the corresponding parts of
+   Public Key Cryptographic Standard #1 [RFC2437].)
+
+   The size of "n", including most and least significant bits (which
+   will be 1) MUST be not less than 512 bits and not more than 4096
+   bits.  "n" and "e" SHOULD be chosen such that the public exponent is
+   small.  These are protocol limits.  For a discussion of key size see
+   RFC 2541.
+
+   Leading zero bytes are permitted in the RSA/SHA1 algorithm signature.
+
+4. Performance Considerations
+
+   General signature generation speeds are roughly the same for RSA and
+   DSA [RFC2536].  With sufficient pre-computation, signature generation
+   with DSA is faster than RSA.  Key generation is also faster for DSA.
+   However, signature verification is an order of magnitude slower with
+   DSA when the RSA public exponent is chosen to be small as is
+   recommended for KEY RRs used in domain name system (DNS) data
+   authentication.
+
+   A public exponent of 3 minimizes the effort needed to verify a
+   signature.  Use of 3 as the public exponent is weak for
+   confidentiality uses since, if the same data can be collected
+   encrypted under three different keys with an exponent of 3 then,
+   using the Chinese Remainder Theorem [NETSEC], the original plain text
+   can be easily recovered.  If a key is known to be used only for
+   authentication, as is the case with DNSSEC, then an exponent of 3 is
+   acceptable.  However other applications in the future may wish to
+   leverage DNS distributed keys for applications that do require
+   confidentiality.  For keys which might have such other uses, a more
+   conservative choice would be 65537 (F4, the fourth fermat number).
+
+
+
+
+
+D. Eastlake 3rd             Standards Track                     [Page 4]
+
+RFC 3110              RSA SIGs and KEYs in the DNS              May 2001
+
+
+   Current DNS implementations are optimized for small transfers,
+   typically less than 512 bytes including DNS overhead.  Larger
+   transfers will perform correctly and extensions have been
+   standardized [RFC2671] to make larger transfers more efficient, it is
+   still advisable at this time to make reasonable efforts to minimize
+   the size of KEY RR sets stored within the DNS consistent with
+   adequate security.  Keep in mind that in a secure zone, at least one
+   authenticating SIG RR will also be returned.
+
+5. IANA Considerations
+
+   The DNSSEC algorithm number 5 is allocated for RSA/SHA1 SIG RRs and
+   RSA KEY RRs.
+
+6. Security Considerations
+
+   Many of the general security considerations in RFC 2535 apply.  Keys
+   retrieved from the DNS should not be trusted unless (1) they have
+   been securely obtained from a secure resolver or independently
+   verified by the user and (2) this secure resolver and secure
+   obtainment or independent verification conform to security policies
+   acceptable to the user.  As with all cryptographic algorithms,
+   evaluating the necessary strength of the key is essential and
+   dependent on local policy.  For particularly critical applications,
+   implementers are encouraged to consider the range of available
+   algorithms and key sizes.  See also RFC 2541, "DNS Security
+   Operational Considerations".
+
+References
+
+   [FIP180]   U.S. Department of Commerce, "Secure Hash Standard", FIPS
+              PUB 180-1, 17 Apr 1995.
+
+   [NETSEC]   Network Security: PRIVATE Communications in a PUBLIC
+              World, Charlie Kaufman, Radia Perlman, & Mike Speciner,
+              Prentice Hall Series in Computer Networking and
+              Distributed Communications, 1995.
+
+   [RFC1034]  Mockapetris, P., "Domain Names - Concepts and Facilities",
+              STD 13, RFC 1034, November 1987.
+
+   [RFC1035]  Mockapetris, P., "Domain Names - Implementation and
+              Specification", STD 13, RFC 1035, November 1987.
+
+   [RFC1321]  Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
+              April 1992.
+
+
+
+
+
+D. Eastlake 3rd             Standards Track                     [Page 5]
+
+RFC 3110              RSA SIGs and KEYs in the DNS              May 2001
+
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2437]  Kaliski, B. and J. Staddon, "PKCS #1: RSA Cryptography
+              Specifications Version 2.0", RFC 2437, October 1998.
+
+   [RFC2535]  Eastlake, D., "Domain Name System Security Extensions",
+              RFC 2535, March 1999.
+
+   [RFC2536]  Eastlake, D., "DSA KEYs and SIGs in the Domain Name System
+              (DNS)", RFC 2536, March 1999.
+
+   [RFC2537]  Eastlake, D., "RSA/MD5 KEYs and SIGs in the Domain Name
+              System (DNS)", RFC 2537, March 1999.
+
+   [RFC2541]  Eastlake, D., "DNS Security Operational Considerations",
+              RFC 2541, March 1999.
+
+   [RFC2671]  Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
+              2671, August 1999.
+
+   [Schneier] Bruce Schneier, "Applied Cryptography Second Edition:
+              protocols, algorithms, and source code in C", 1996, John
+              Wiley and Sons, ISBN 0-471-11709-9.
+
+Author's Address
+
+   Donald E. Eastlake 3rd
+   Motorola
+   155 Beaver Street
+   Milford, MA 01757 USA
+
+   Phone:   +1-508-261-5434 (w)
+            +1-508-634-2066 (h)
+   Fax      +1-508-261-4777 (w)
+   EMail:   Donald.Eastlake@motorola.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+D. Eastlake 3rd             Standards Track                     [Page 6]
+
+RFC 3110              RSA SIGs and KEYs in the DNS              May 2001
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2001).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+D. Eastlake 3rd             Standards Track                     [Page 7]
+
diff --git a/doc/rfc/rfc3123.txt b/doc/rfc/rfc3123.txt
new file mode 100644
index 0000000..3b2fe00
--- /dev/null
+++ b/doc/rfc/rfc3123.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Network Working Group                                            P. Koch
+Request for Comments: 3123                        Universitaet Bielefeld
+Category: Experimental                                         June 2001
+
+
+          A DNS RR Type for Lists of Address Prefixes (APL RR)
+
+Status of this Memo
+
+   This memo defines an Experimental Protocol for the Internet
+   community.  It does not specify an Internet standard of any kind.
+   Discussion and suggestions for improvement are requested.
+   Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2001).  All Rights Reserved.
+
+Abstract
+
+   The Domain Name System (DNS) is primarily used to translate domain
+   names into IPv4 addresses using A RRs (Resource Records).  Several
+   approaches exist to describe networks or address ranges.  This
+   document specifies a new DNS RR type "APL" for address prefix lists.
+
+1. Conventions used in this document
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+   Domain names herein are for explanatory purposes only and should not
+   be expected to lead to useful information in real life [RFC2606].
+
+2. Background
+
+   The Domain Name System [RFC1034], [RFC1035] provides a mechanism to
+   associate addresses and other Internet infrastructure elements with
+   hierarchically built domain names.  Various types of resource records
+   have been defined, especially those for IPv4 and IPv6 [RFC2874]
+   addresses.  In [RFC1101] a method is described to publish information
+   about the address space allocated to an organisation.  In older BIND
+   versions, a weak form of controlling access to zone data was
+   implemented using TXT RRs describing address ranges.
+
+   This document specifies a new RR type for address prefix lists.
+
+
+
+
+
+Koch                          Experimental                      [Page 1]
+
+RFC 3123                       DNS APL RR                      June 2001
+
+
+3. APL RR Type
+
+   An APL record has the DNS type of "APL" and a numeric value of 42
+   [IANA].  The APL RR is defined in the IN class only.  APL RRs cause
+   no additional section processing.
+
+4. APL RDATA format
+
+   The RDATA section consists of zero or more items (<apitem>) of the
+   form
+
+      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+      |                          ADDRESSFAMILY                        |
+      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+      |             PREFIX            | N |         AFDLENGTH         |
+      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+      /                            AFDPART                            /
+      |                                                               |
+      +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+
+      ADDRESSFAMILY     16 bit unsigned value as assigned by IANA
+                        (see IANA Considerations)
+      PREFIX            8 bit unsigned binary coded prefix length.
+                        Upper and lower bounds and interpretation of
+                        this value are address family specific.
+      N                 negation flag, indicates the presence of the
+                        "!" character in the textual format.  It has
+                        the value "1" if the "!" was given, "0" else.
+      AFDLENGTH         length in octets of the following address
+                        family dependent part (7 bit unsigned).
+      AFDPART           address family dependent part.  See below.
+
+   This document defines the AFDPARTs for address families 1 (IPv4) and
+   2 (IPv6).  Future revisions may deal with additional address
+   families.
+
+4.1. AFDPART for IPv4
+
+   The encoding of an IPv4 address (address family 1) follows the
+   encoding specified for the A RR by [RFC1035], section 3.4.1.
+
+   PREFIX specifies the number of bits of the IPv4 address starting at
+   the most significant bit.  Legal values range from 0 to 32.
+
+   Trailing zero octets do not bear any information (e.g., there is no
+   semantic difference between 10.0.0.0/16 and 10/16) in an address
+   prefix, so the shortest possible AFDLENGTH can be used to encode it.
+   However, for DNSSEC [RFC2535] a single wire encoding must be used by
+
+
+
+Koch                          Experimental                      [Page 2]
+
+RFC 3123                       DNS APL RR                      June 2001
+
+
+   all.  Therefore the sender MUST NOT include trailing zero octets in
+   the AFDPART regardless of the value of PREFIX.  This includes cases
+   in which AFDLENGTH times 8 results in a value less than PREFIX.  The
+   AFDPART is padded with zero bits to match a full octet boundary.
+
+   An IPv4 AFDPART has a variable length of 0 to 4 octets.
+
+4.2. AFDPART for IPv6
+
+   The 128 bit IPv6 address (address family 2) is encoded in network
+   byte order (high-order byte first).
+
+   PREFIX specifies the number of bits of the IPv6 address starting at
+   the most significant bit.  Legal values range from 0 to 128.
+
+   With the same reasoning as in 4.1 above, the sender MUST NOT include
+   trailing zero octets in the AFDPART regardless of the value of
+   PREFIX.  This includes cases in which AFDLENGTH times 8 results in a
+   value less than PREFIX.  The AFDPART is padded with zero bits to
+   match a full octet boundary.
+
+   An IPv6 AFDPART has a variable length of 0 to 16 octets.
+
+5. Zone File Syntax
+
+   The textual representation of an APL RR in a DNS zone file is as
+   follows:
+
+   <owner>   IN   <TTL>   APL   {[!]afi:address/prefix}*
+
+   The data consists of zero or more strings of the address family
+   indicator <afi>, immediately followed by a colon ":", an address,
+   immediately followed by the "/" character, immediately followed by a
+   decimal numeric value for the prefix length.  Any such string may be
+   preceded by a "!" character.  The strings are separated by
+   whitespace.  The <afi> is the decimal numeric value of that
+   particular address family.
+
+5.1. Textual Representation of IPv4 Addresses
+
+   An IPv4 address in the <address> part of an <apitem> is in dotted
+   quad notation, just as in an A RR.  The <prefix> has values from the
+   interval 0..32 (decimal).
+
+
+
+
+
+
+
+
+Koch                          Experimental                      [Page 3]
+
+RFC 3123                       DNS APL RR                      June 2001
+
+
+5.2. Textual Representation of IPv6 Addresses
+
+   The representation of an IPv6 address in the <address> part of an
+   <apitem> follows [RFC2373], section 2.2.  Legal values for <prefix>
+   are from the interval 0..128 (decimal).
+
+6. APL RR usage
+
+   An APL RR with empty RDATA is valid and implements an empty list.
+   Multiple occurrences of the same <apitem> in a single APL RR are
+   allowed and MUST NOT be merged by a DNS server or resolver.
+   <apitems> MUST be kept in order and MUST NOT be rearranged or
+   aggregated.
+
+   A single APL RR may contain <apitems> belonging to different address
+   families.  The maximum number of <apitems> is upper bounded by the
+   available RDATA space.
+
+   RRSets consisting of more than one APL RR are legal but the
+   interpretation is left to the particular application.
+
+7. Applicability Statement
+
+   The APL RR defines a framework without specifying any particular
+   meaning for the list of prefixes.  It is expected that APL RRs will
+   be used in different application scenarios which have to be
+   documented separately.  Those scenarios may be distinguished by
+   characteristic prefixes placed in front of the DNS owner name.
+
+   An APL application specification MUST include information on
+
+   o  the characteristic prefix, if any
+
+   o  how to interpret APL RRSets consisting of more than one RR
+
+   o  how to interpret an empty APL RR
+
+   o  which address families are expected to appear in the APL RRs for
+      that application
+
+   o  how to deal with APL RR list elements which belong to other
+      address families, including those not yet defined
+
+   o  the exact semantics of list elements negated by the "!" character
+
+
+
+
+
+
+
+Koch                          Experimental                      [Page 4]
+
+RFC 3123                       DNS APL RR                      June 2001
+
+
+   Possible applications include the publication of address ranges
+   similar to [RFC1101], description of zones built following [RFC2317]
+   and in-band access control to limit general access or zone transfer
+   (AXFR) availability for zone data held in DNS servers.
+
+   The specification of particular application scenarios is out of the
+   scope of this document.
+
+8. Examples
+
+   The following examples only illustrate some of the possible usages
+   outlined in the previous section.  None of those applications are
+   hereby specified nor is it implied that any particular APL RR based
+   application does exist now or will exist in the future.
+
+  ; RFC 1101-like announcement of address ranges for foo.example
+  foo.example.             IN APL 1:192.168.32.0/21 !1:192.168.38.0/28
+
+  ; CIDR blocks covered by classless delegation
+  42.168.192.IN-ADDR.ARPA. IN APL ( 1:192.168.42.0/26 1:192.168.42.64/26
+                                  1:192.168.42.128/25 )
+
+  ; Zone transfer restriction
+  _axfr.sbo.example.       IN APL 1:127.0.0.1/32 1:172.16.64.0/22
+
+  ; List of address ranges for multicast
+  multicast.example.       IN APL 1:224.0.0.0/4  2:FF00:0:0:0:0:0:0:0/8
+
+   Note that since trailing zeroes are ignored in the first APL RR the
+   AFDLENGTH of both <apitems> is three.
+
+9. Security Considerations
+
+   Any information obtained from the DNS should be regarded as unsafe
+   unless techniques specified in [RFC2535] or [RFC2845] were used.  The
+   definition of a new RR type does not introduce security problems into
+   the DNS, but usage of information made available by APL RRs may
+   compromise security.  This includes disclosure of network topology
+   information and in particular the use of APL RRs to construct access
+   control lists.
+
+
+
+
+
+
+
+
+
+
+
+Koch                          Experimental                      [Page 5]
+
+RFC 3123                       DNS APL RR                      June 2001
+
+
+10. IANA Considerations
+
+   This section is to be interpreted as following [RFC2434].
+
+   This document does not define any new namespaces.  It uses the 16 bit
+   identifiers for address families maintained by IANA in
+   http://www.iana.org/numbers.html.
+
+   The IANA assigned numeric RR type value 42 for APL [IANA].
+
+11. Acknowledgements
+
+   The author would like to thank Mark Andrews, Olafur Gudmundsson, Ed
+   Lewis, Thomas Narten, Erik Nordmark, and Paul Vixie for their review
+   and constructive comments.
+
+12. References
+
+   [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
+             STD 13, RFC 1034, November 1987.
+
+   [RFC1035] Mockapetris, P., "Domain Names - Implementation and
+             Specification", STD 13, RFC 1035, November 1987.
+
+   [RFC1101] Mockapetris, P., "DNS Encoding of Network Names and Other
+             Types", RFC 1101, April 1989.
+
+   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+             Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
+             Specification", RFC 2181, July 1997.
+
+   [RFC2317] Eidnes, H., de Groot, G. and P. Vixie, "Classless IN-
+             ADDR.ARPA delegation", BCP 20, RFC 2317, March 1998.
+
+   [RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing
+             Architecture", RFC 2373, July 1998.
+
+   [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
+             IANA Considerations Section in RFCs", BCP 26, RFC 2434,
+             October 1998.
+
+   [RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC
+             2535, March 1999.
+
+   [RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS Names",
+             BCP 32, RFC 2606, June 1999.
+
+
+
+Koch                          Experimental                      [Page 6]
+
+RFC 3123                       DNS APL RR                      June 2001
+
+
+   [RFC2845] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
+             "Secret Key Transaction Authentication for DNS (TSIG)", RFC
+             2845, May 2000.
+
+   [RFC2874] Crawford, M. and C. Huitema, "DNS Extensions to Support
+             IPv6 Address Aggregation and Renumbering", RFC 2874, July
+             2000.
+
+   [IANA]    http://www.iana.org/assignments/dns-parameters
+
+13. Author's Address
+
+   Peter Koch
+   Universitaet Bielefeld
+   Technische Fakultaet
+   D-33594 Bielefeld
+   Germany
+
+   Phone: +49 521 106 2902
+   EMail: pk@TechFak.Uni-Bielefeld.DE
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Koch                          Experimental                      [Page 7]
+
+RFC 3123                       DNS APL RR                      June 2001
+
+
+14. Full Copyright Statement
+
+   Copyright (C) The Internet Society (2001).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Koch                          Experimental                      [Page 8]
+
diff --git a/doc/rfc/rfc3152.txt b/doc/rfc/rfc3152.txt
new file mode 100644
index 0000000..b226ce6
--- /dev/null
+++ b/doc/rfc/rfc3152.txt
@@ -0,0 +1,227 @@
+
+
+
+
+
+
+Network Working Group                                            R. Bush
+Request for Comments: 3152                                         RGnet
+BCP: 49                                                      August 2001
+Updates: 2874, 2772, 2766, 2553, 1886
+Category: Best Current Practice
+
+
+                         Delegation of IP6.ARPA
+
+Status of this Memo
+
+   This document specifies an Internet Best Current Practices for the
+   Internet Community, and requests discussion and suggestions for
+   improvements.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2001).  All Rights Reserved.
+
+Abstract
+
+   This document discusses the need for delegation of the IP6.ARPA DNS
+   zone, and specifies a plan for the technical operation thereof.
+
+1. Why IP6.ARPA?
+
+   In the IPv6 address space, there is a need for 'reverse mapping' of
+   addresses to DNS names analogous to that provided by the IN-ADDR.ARPA
+   zone for IPv4.
+
+   The IAB recommended that the ARPA top level domain (the name is now
+   considered an acronym for "Address and Routing Parameters Area") be
+   used for technical infrastructure sub-domains when possible.  It is
+   already in use for IPv4 reverse mapping and has been established as
+   the location for E.164 numbering on the Internet [RFC2916 RFC3026].
+
+   IETF consensus was reached that the IP6.ARPA domain be used for
+   address to DNS name mapping for the IPv6 address space [RFC2874].
+
+2. Obsoleted Usage
+
+   This document deprecates references to IP6.INT in [RFC1886] section
+   2.5, [RFC2553] section 6.2.3, [RFC2766] section 4.1, [RFC2772]
+   section 7.1.c, and [RFC2874] section 2.5.
+
+   In this context, 'deprecate' means that the old usage is not
+   appropriate for new implementations, and IP6.INT will likely be
+   phased out in an orderly fashion.
+
+
+
+Bush                     Best Current Practice                  [Page 1]
+
+RFC 3152                 Delegation of IP6.ARPA              August 2001
+
+
+3. IANA Considerations
+
+   This memo requests that the IANA delegate the IP6.ARPA domain
+   following instructions to be provided by the IAB.  Names within this
+   zone are to be further delegated to the regional IP registries in
+   accordance with the delegation of IPv6 address space to those
+   registries.  The names allocated should be hierarchic in accordance
+   with the address space assignment.
+
+4. Security Considerations
+
+   While DNS spoofing of address to name mapping has been exploited in
+   IPv4, delegation of the IP6.ARPA zone creates no new threats to the
+   security of the internet.
+
+5. References
+
+   [RFC1886]   Thomson, S. and C. Huitema, "DNS Extensions to support IP
+               version 6", RFC 1886, December 1995.
+
+   [RFC2553]   Gilligan, R., Thomson, S., Bound, J. and W. Stevens,
+               "Basic Socket Interface Extensions for IPv6", RFC 2553,
+               March 1999.
+
+   [RFC2766]   Tsirtsis, G. and P. Srisuresh, "Network Address
+               Translation - Protocol Translation (NAT-PT)", RFC 2766,
+               February 2000.
+
+   [RFC2772]   Rockell, R. and R. Fink, "6Bone Backbone Routing
+               Guidelines", RFC 2772, February 2000.
+
+   [RFC2874]   Crawford, M. and C. Huitema, "DNS Extensions to Support
+               IPv6 Address Aggregation and Renumbering", RFC 2874, July
+               2001.
+
+   [RFC2916]   Faltstrom, P., "E.164 number and DNS", RFC 2916,
+               September 2000.
+
+   [RFC3026]   Blane, R., "Liaison to IETF/ISOC on ENUM", RFC 3026,
+               January 2001.
+
+
+
+
+
+
+
+
+
+
+
+Bush                     Best Current Practice                  [Page 2]
+
+RFC 3152                 Delegation of IP6.ARPA              August 2001
+
+
+6. Author's Address
+
+   Randy Bush
+   5147 Crystal Springs
+   Bainbridge Island, WA US-98110
+
+   Phone: +1 206 780 0431
+   EMail: randy@psg.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bush                     Best Current Practice                  [Page 3]
+
+RFC 3152                 Delegation of IP6.ARPA              August 2001
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2001).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bush                     Best Current Practice                  [Page 4]
+
diff --git a/doc/rfc/rfc3197.txt b/doc/rfc/rfc3197.txt
new file mode 100644
index 0000000..94cefa4
--- /dev/null
+++ b/doc/rfc/rfc3197.txt
@@ -0,0 +1,283 @@
+
+
+
+
+
+
+Network Working Group                                         R. Austein
+Request for Comments: 3197                                 InterNetShare
+Category: Informational                                    November 2001
+
+
+             Applicability Statement for DNS MIB Extensions
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2001).  All Rights Reserved.
+
+Abstract
+
+   This document explains why, after more than six years as proposed
+   standards, the DNS Server and Resolver MIB extensions were never
+   deployed, and recommends retiring these MIB extensions by moving them
+   to Historical status.
+
+1. History
+
+   The road to the DNS MIB extensions was paved with good intentions.
+
+   In retrospect, it's obvious that the working group never had much
+   agreement on what belonged in the MIB extensions, just that we should
+   have some.  This happened during the height of the craze for MIB
+   extensions in virtually every protocol that the IETF was working on
+   at the time, so the question of why we were doing this in the first
+   place never got a lot of scrutiny.  Very late in the development
+   cycle we discovered that much of the support for writing the MIB
+   extensions in the first place had come from people who wanted to use
+   SNMP SET operations to update DNS zones on the fly.  Examination of
+   the security model involved, however, led us to conclude that this
+   was not a good way to do dynamic update and that a separate DNS
+   Dynamic Update protocol would be necessary.
+
+   The MIB extensions started out being fairly specific to one
+   particular DNS implementation (BIND-4.8.3); as work progressed, the
+   BIND-specific portions were rewritten to be as implementation-neutral
+   as we knew how to make them, but somehow every revision of the MIB
+   extensions managed to create new counters that just happened to
+   closely match statistics kept by some version of BIND.  As a result,
+   the MIB extensions ended up being much too big, which raised a number
+
+
+
+Austein                      Informational                      [Page 1]
+
+RFC 3197      Applicability Statement - DNS MIB Extensions November 2001
+
+
+   of concerns with the network management directorate, but the WG
+   resisted every attempt to remove any of these variables.  In the end,
+   large portions of the MIB extensions were moved into optional groups
+   in an attempt to get the required subset down to a manageable size.
+
+   The DNS Server and Resolver MIB extensions were one of the first
+   attempts to write MIB extensions for a protocol usually considered to
+   be at the application layer.  Fairly early on it became clear that,
+   while it was certainly possible to write MIB extensions for DNS, the
+   SMI was not really designed with this sort of thing in mind.  A case
+   in point was the attempt to provide direct indexing into the caches
+   in the resolver MIB extensions: while arguably the only sane way to
+   do this for a large cache, this required much more complex indexing
+   clauses than is usual, and ended up running into known length limits
+   for object identifiers in some SNMP implementations.
+
+   Furthermore, the lack of either real proxy MIB support in SNMP
+   managers or a standard subagent protocol meant that there was no
+   reasonable way to implement the MIB extensions in the dominant
+   implementation (BIND).  When the AgentX subagent protocol was
+   developed a few years later, we initially hoped that this would
+   finally clear the way for an implementation of the DNS MIB
+   extensions, but by the time AgentX was a viable protocol it had
+   become clear that nobody really wanted to implement these MIB
+   extensions.
+
+   Finally, the MIB extensions took much too long to produce.  In
+   retrospect, this should have been a clear warning sign, particularly
+   when the WG had clearly become so tired of the project that the
+   authors found it impossible to elicit any comments whatsoever on the
+   documents.
+
+2. Lessons
+
+   Observations based on the preceding list of mistakes, for the benefit
+   of anyone else who ever attempts to write DNS MIB extensions again:
+
+   -  Define a clear set of goals before writing any MIB extensions.
+      Know who the constituency is and make sure that what you write
+      solves their problem.
+
+   -  Keep the MIB extensions short, and don't add variables just
+      because somebody in the WG thinks they'd be a cool thing to
+      measure.
+
+   -  If some portion of the task seems to be very hard to do within the
+      SMI, that's a strong hint that SNMP is not the right tool for
+      whatever it is that you're trying to do.
+
+
+
+Austein                      Informational                      [Page 2]
+
+RFC 3197      Applicability Statement - DNS MIB Extensions November 2001
+
+
+   -  If the entire project is taking too long, perhaps that's a hint
+      too.
+
+3. Recommendation
+
+   In view of the community's apparent total lack of interest in
+   deploying these MIB extensions, we recommend that RFCs 1611 and 1612
+   be reclassified as Historical documents.
+
+4. Security Considerations
+
+   Re-classifying an existing MIB document from Proposed Standard to
+   Historic should not have any negative impact on security for the
+   Internet.
+
+5. IANA Considerations
+
+   Getting rid of the DNS MIB extensions should not impose any new work
+   on IANA.
+
+6. Acknowledgments
+
+   The author would like to thank all the people who were involved in
+   this project over the years for their optimism and patience,
+   misguided though it may have been.
+
+7. References
+
+   [DNS-SERVER-MIB]     Austein, R. and J. Saperia, "DNS Server MIB
+                        Extensions", RFC 1611, May 1994.
+
+   [DNS-RESOLVER-MIB]   Austein, R. and J. Saperia, "DNS Resolver MIB
+                        Extensions", RFC 1612, May 1994.
+
+   [DNS-DYNAMIC-UPDATE] Vixie, P., Thomson, S., Rekhter, Y. and J.
+                        Bound, "Dynamic Updates in the Domain Name
+                        System (DNS UPDATE)", RFC 2136, April 1997.
+
+   [AGENTX]             Daniele, M., Wijnen, B., Ellison, M., and D.
+                        Francisco, "Agent Extensibility (AgentX)
+                        Protocol Version 1", RFC 2741, January 2000.
+
+
+
+
+
+
+
+
+
+
+Austein                      Informational                      [Page 3]
+
+RFC 3197      Applicability Statement - DNS MIB Extensions November 2001
+
+
+8. Author's Address
+
+   Rob Austein
+   InterNetShare, Incorporated
+   325M Sharon Park Drive, Suite 308
+   Menlo Park, CA  94025
+   USA
+
+   EMail: sra@hactrn.net
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Austein                      Informational                      [Page 4]
+
+RFC 3197      Applicability Statement - DNS MIB Extensions November 2001
+
+
+9. Full Copyright Statement
+
+   Copyright (C) The Internet Society (2001).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Austein                      Informational                      [Page 5]
+
diff --git a/doc/rfc/rfc3225.txt b/doc/rfc/rfc3225.txt
new file mode 100644
index 0000000..13e6768
--- /dev/null
+++ b/doc/rfc/rfc3225.txt
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+Network Working Group                                          D. Conrad
+Request for Comments: 3225                                 Nominum, Inc.
+Category: Standards Track                                  December 2001
+
+
+                 Indicating Resolver Support of DNSSEC
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2001).  All Rights Reserved.
+
+Abstract
+
+   In order to deploy DNSSEC (Domain Name System Security Extensions)
+   operationally, DNSSEC aware servers should only perform automatic
+   inclusion of DNSSEC RRs when there is an explicit indication that the
+   resolver can understand those RRs.  This document proposes the use of
+   a bit in the EDNS0 header to provide that explicit indication and
+   describes the necessary protocol changes to implement that
+   notification.
+
+1. Introduction
+
+   DNSSEC [RFC2535] has been specified to provide data integrity and
+   authentication to security aware resolvers and applications through
+   the use of cryptographic digital signatures.  However, as DNSSEC is
+   deployed, non-DNSSEC-aware clients will likely query DNSSEC-aware
+   servers.  In such situations, the DNSSEC-aware server (responding to
+   a request for data in a signed zone) will respond with SIG, KEY,
+   and/or NXT records.  For reasons described in the subsequent section,
+   such responses can have significant negative operational impacts for
+   the DNS infrastructure.
+
+   This document discusses a method to avoid these negative impacts,
+   namely DNSSEC-aware servers should only respond with SIG, KEY, and/or
+   NXT RRs when there is an explicit indication from the resolver that
+   it can understand those RRs.
+
+   For the purposes of this document, "DNSSEC security RRs" are
+   considered RRs of type SIG, KEY, or NXT.
+
+
+
+Conrad                      Standards Track                     [Page 1]
+
+RFC 3225         Indicating Resolver Support of DNSSEC     December 2001
+
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+2. Rationale
+
+   Initially, as DNSSEC is deployed, the vast majority of queries will
+   be from resolvers that are not DNSSEC aware and thus do not
+   understand or support the DNSSEC security RRs.  When a query from
+   such a resolver is received for a DNSSEC signed zone, the DNSSEC
+   specification indicates the nameserver must respond with the
+   appropriate DNSSEC security RRs.  As DNS UDP datagrams are limited to
+   512 bytes [RFC1035], responses including DNSSEC security RRs have a
+   high probability of resulting in a truncated response being returned
+   and the resolver retrying the query using TCP.
+
+   TCP DNS queries result in significant overhead due to connection
+   setup and teardown.  Operationally, the impact of these TCP queries
+   will likely be quite detrimental in terms of increased network
+   traffic (typically five packets for a single query/response instead
+   of two), increased latency resulting from the additional round trip
+   times, increased incidences of queries failing due to timeouts, and
+   significantly increased load on nameservers.
+
+   In addition, in preliminary and experimental deployment of DNSSEC,
+   there have been reports of non-DNSSEC aware resolvers being unable to
+   handle responses which contain DNSSEC security RRs, resulting in the
+   resolver failing (in the worst case) or entire responses being
+   ignored (in the better case).
+
+   Given these operational implications, explicitly notifying the
+   nameserver that the client is prepared to receive (if not understand)
+   DNSSEC security RRs would be prudent.
+
+   Client-side support of DNSSEC is assumed to be binary -- either the
+   client is willing to receive all DNSSEC security RRs or it is not
+   willing to accept any.  As such, a single bit is sufficient to
+   indicate client-side DNSSEC support.  As effective use of DNSSEC
+   implies the need of EDNS0 [RFC2671], bits in the "classic" (non-EDNS
+   enhanced DNS header) are scarce, and there may be situations in which
+   non-compliant caching or forwarding servers inappropriately copy data
+   from classic headers as queries are passed on to authoritative
+   servers, the use of a bit from the EDNS0 header is proposed.
+
+   An alternative approach would be to use the existence of an EDNS0
+   header as an implicit indication of client-side support of DNSSEC.
+   This approach was not chosen as there may be applications in which
+   EDNS0 is supported but in which the use of DNSSEC is inappropriate.
+
+
+
+Conrad                      Standards Track                     [Page 2]
+
+RFC 3225         Indicating Resolver Support of DNSSEC     December 2001
+
+
+3. Protocol Changes
+
+   The mechanism chosen for the explicit notification of the ability of
+   the client to accept (if not understand) DNSSEC security RRs is using
+   the most significant bit of the Z field on the EDNS0 OPT header in
+   the query.  This bit is referred to as the "DNSSEC OK" (DO) bit.  In
+   the context of the EDNS0 OPT meta-RR, the DO bit is the first bit of
+   the third and fourth bytes of the "extended RCODE and flags" portion
+   of the EDNS0 OPT meta-RR, structured as follows:
+
+                +0 (MSB)                +1 (LSB)
+         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+      0: |   EXTENDED-RCODE      |       VERSION         |
+         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+      2: |DO|                    Z                       |
+         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+   Setting the DO bit to one in a query indicates to the server that the
+   resolver is able to accept DNSSEC security RRs.  The DO bit cleared
+   (set to zero) indicates the resolver is unprepared to handle DNSSEC
+   security RRs and those RRs MUST NOT be returned in the response
+   (unless DNSSEC security RRs are explicitly queried for).  The DO bit
+   of the query MUST be copied in the response.
+
+   More explicitly, DNSSEC-aware nameservers MUST NOT insert SIG, KEY,
+   or NXT RRs to authenticate a response as specified in [RFC2535]
+   unless the DO bit was set on the request.  Security records that
+   match an explicit SIG, KEY, NXT, or ANY query, or are part of the
+   zone data for an AXFR or IXFR query, are included whether or not the
+   DO bit was set.
+
+   A recursive DNSSEC-aware server MUST set the DO bit on recursive
+   requests, regardless of the status of the DO bit on the initiating
+   resolver request.  If the initiating resolver request does not have
+   the DO bit set, the recursive DNSSEC-aware server MUST remove DNSSEC
+   security RRs before returning the data to the client, however cached
+   data MUST NOT be modified.
+
+   In the event a server returns a NOTIMP, FORMERR or SERVFAIL response
+   to a query that has the DO bit set, the resolver SHOULD NOT expect
+   DNSSEC security RRs and SHOULD retry the query without EDNS0 in
+   accordance with section 5.3 of [RFC2671].
+
+
+
+
+
+
+
+
+
+Conrad                      Standards Track                     [Page 3]
+
+RFC 3225         Indicating Resolver Support of DNSSEC     December 2001
+
+
+Security Considerations
+
+   The absence of DNSSEC data in response to a query with the DO bit set
+   MUST NOT be taken to mean no security information is available for
+   that zone as the response may be forged or a non-forged response of
+   an altered (DO bit cleared) query.
+
+IANA Considerations
+
+   EDNS0 [RFC2671] defines 16 bits as extended flags in the OPT record,
+   these bits are encoded into the TTL field of the OPT record (RFC2671
+   section 4.6).
+
+   This document reserves one of these bits as the OK bit.  It is
+   requested that the left most bit be allocated.  Thus the USE of the
+   OPT record TTL field would look like
+
+                +0 (MSB)                +1 (LSB)
+         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+      0: |   EXTENDED-RCODE      |       VERSION         |
+         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+      2: |DO|                    Z                       |
+         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+
+Acknowledgements
+
+   This document is based on a rough draft by Bob Halley with input from
+   Olafur Gudmundsson, Andreas Gustafsson, Brian Wellington, Randy Bush,
+   Rob Austein, Steve Bellovin, and Erik Nordmark.
+
+References
+
+   [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
+             STD 13, RFC 1034, November 1987.
+
+   [RFC1035] Mockapetris, P., "Domain Names - Implementation and
+             Specifications", STD 13, RFC 1035, November 1987.
+
+   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+             Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC
+             2535, March 1999.
+
+   [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
+             2671, August 1999.
+
+
+
+
+
+Conrad                      Standards Track                     [Page 4]
+
+RFC 3225         Indicating Resolver Support of DNSSEC     December 2001
+
+
+Author's Address
+
+   David Conrad
+   Nominum Inc.
+   950 Charter Street
+   Redwood City, CA 94063
+   USA
+
+   Phone: +1 650 381 6003
+   EMail: david.conrad@nominum.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Conrad                      Standards Track                     [Page 5]
+
+RFC 3225         Indicating Resolver Support of DNSSEC     December 2001
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2001).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Conrad                      Standards Track                     [Page 6]
+
diff --git a/doc/rfc/rfc3226.txt b/doc/rfc/rfc3226.txt
new file mode 100644
index 0000000..dac0e11
--- /dev/null
+++ b/doc/rfc/rfc3226.txt
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+Network Working Group                                     O. Gudmundsson
+Request for Comments: 3226                                 December 2001
+Updates: 2874, 2535
+Category: Standards Track
+
+
+   DNSSEC and IPv6 A6 aware server/resolver message size requirements
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2001).  All Rights Reserved.
+
+Abstract
+
+   This document mandates support for EDNS0 (Extension Mechanisms for
+   DNS) in DNS entities claiming to support either DNS Security
+   Extensions or A6 records.  This requirement is necessary because
+   these new features increase the size of DNS messages.  If EDNS0 is
+   not supported fall back to TCP will happen, having a detrimental
+   impact on query latency and DNS server load.  This document updates
+   RFC 2535 and RFC 2874, by adding new requirements.
+
+1.  Introduction
+
+   Familiarity with the DNS [RFC1034, RFC1035], DNS Security Extensions
+   [RFC2535], EDNS0 [RFC2671] and A6 [RFC2874] is helpful.
+
+   STD 13, RFC 1035 Section 2.3.4 requires that DNS messages over UDP
+   have a data payload of 512 octets or less.  Most DNS software today
+   will not accept larger UDP datagrams.  Any answer that requires more
+   than 512 octets, results in a partial and sometimes useless reply
+   with the Truncation Bit set; in most cases the requester will then
+   retry using TCP.  Furthermore, server delivery of truncated responses
+   varies widely and resolver handling of these responses also varies,
+   leading to additional inefficiencies in handling truncation.
+
+   Compared to UDP, TCP is an expensive protocol to use for a simple
+   transaction like DNS: a TCP connection requires 5 packets for setup
+   and tear down, excluding data packets, thus requiring at least 3
+   round trips on top of the one for the original UDP query.  The DNS
+
+
+
+Gudmundsson                 Standards Track                     [Page 1]
+
+RFC 3226            DNSSEC and IPv6 A6 requirements        December 2001
+
+
+   server also needs to keep a state of the connection during this
+   transaction.  Many DNS servers answer thousands of queries per
+   second, requiring them to use TCP will cause significant overhead and
+   delays.
+
+1.1.  Requirements
+
+   The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY"
+   in this document are to be interpreted as described in RFC 2119.
+
+2.  Motivating factors
+
+2.1.  DNSSEC motivations
+
+   DNSSEC [RFC2535] secures DNS by adding a Public Key signature on each
+   RR set.  These signatures range in size from about 80 octets to 800
+   octets, most are going to be in the range of 80 to 200 octets.  The
+   addition of signatures on each or most RR sets in an answer
+   significantly increases the size of DNS answers from secure zones.
+
+   For performance reasons and to reduce load on DNS servers, it is
+   important that security aware servers and resolvers get all the data
+   in Answer and Authority section in one query without truncation.
+   Sending Additional Data in the same query is helpful when the server
+   is authoritative for the data, and this reduces round trips.
+
+   DNSSEC OK[OK] specifies how a client can, using EDNS0, indicate that
+   it is interested in receiving DNSSEC records.  The OK bit does not
+   eliminate the need for large answers for DNSSEC capable clients.
+
+2.1.1.  Message authentication or TSIG motivation
+
+   TSIG [RFC2845] allows for the light weight authentication of DNS
+   messages, but increases the size of the messages by at least 70
+   octets.  DNSSEC specifies for computationally expensive message
+   authentication SIG(0) using a standard public key signature.  As only
+   one TSIG or SIG(0) can be attached to each DNS answer the size
+   increase of message authentication is not significant, but may still
+   lead to a truncation.
+
+2.2.  IPv6 Motivations
+
+   IPv6 addresses [RFC2874] are 128 bits and can be represented in the
+   DNS by multiple A6 records, each consisting of a domain name and a
+   bit field.  The domain name refers to an address prefix that may
+   require additional A6 RRs to be included in the answer.  Answers
+   where the queried name has multiple A6 addresses may overflow a 512-
+   octet UDP packet size.
+
+
+
+Gudmundsson                 Standards Track                     [Page 2]
+
+RFC 3226            DNSSEC and IPv6 A6 requirements        December 2001
+
+
+2.3.  Root server and TLD server motivations
+
+   The current number of root servers is limited to 13 as that is the
+   maximum number of name servers and their address records that fit in
+   one 512-octet answer for a SOA record.  If root servers start
+   advertising A6 or KEY records then the answer for the root NS records
+   will not fit in a single 512-octet DNS message, resulting in a large
+   number of TCP query connections to the root servers.  Even if all
+   client resolver query their local name server for information, there
+   are millions of these servers.  Each name server must periodically
+   update its information about the high level servers.
+
+   For redundancy, latency and load balancing reasons, large numbers of
+   DNS servers are required for some zones.  Since the root zone is used
+   by the entire net, it is important to have as many servers as
+   possible.  Large TLDs (and many high-visibility SLDs) often have
+   enough servers that either A6 or KEY records would cause the NS
+   response to overflow the 512 byte limit.  Note that these zones with
+   large numbers of servers are often exactly those zones that are
+   critical to network operation and that already sustain fairly high
+   loads.
+
+2.4.  UDP vs TCP for DNS messages
+
+   Given all these factors, it is essential that any implementation that
+   supports DNSSEC and or A6 be able to use larger DNS messages than 512
+   octets.
+
+   The original 512 restriction was put in place to reduce the
+   probability of fragmentation of DNS responses.  A fragmented UDP
+   message that suffers a loss of one of the fragments renders the
+   answer useless and the query must be retried.  A TCP connection
+   requires a larger number of round trips for establishment, data
+   transfer and tear down, but only the lost data segments are
+   retransmitted.
+
+   In the early days a number of IP implementations did not handle
+   fragmentation well, but all modern operating systems have overcome
+   that issue thus sending fragmented messages is fine from that
+   standpoint.  The open issue is the effect of losses on fragmented
+   messages.  If connection has high loss ratio only TCP will allow
+   reliable transfer of DNS data, most links have low loss ratios thus
+   sending fragmented UDP packet in one round trip is better than
+   establishing a TCP connection to transfer a few thousand octets.
+
+
+
+
+
+
+
+Gudmundsson                 Standards Track                     [Page 3]
+
+RFC 3226            DNSSEC and IPv6 A6 requirements        December 2001
+
+
+2.5.  EDNS0 and large UDP messages
+
+   EDNS0 [RFC2671] allows clients to declare the maximum size of UDP
+   message they are willing to handle.  Thus, if the expected answer is
+   between 512 octets and the maximum size that the client can accept,
+   the additional overhead of a TCP connection can be avoided.
+
+3.  Protocol changes:
+
+   This document updates RFC 2535 and RFC 2874, by adding new
+   requirements.
+
+   All RFC 2535 compliant servers and resolvers MUST support EDNS0 and
+   advertise message size of at least 1220 octets, but SHOULD advertise
+   message size of 4000.  This value might be too low to get full
+   answers for high level servers and successor of this document may
+   require a larger value.
+
+   All RFC 2874 compliant servers and resolver MUST support EDNS0 and
+   advertise message size of at least 1024 octets, but SHOULD advertise
+   message size of 2048.  The IPv6 datagrams should be 1024 octets,
+   unless the MTU of the path is known.  (Note that this is smaller than
+   the minimum IPv6 MTU to allow for some extension headers and/or
+   encapsulation without exceeding the minimum MTU.)
+
+   All RFC 2535 and RFC 2874 compliant entities MUST be able to handle
+   fragmented IPv4 and IPv6 UDP packets.
+
+   All hosts supporting both RFC 2535 and RFC 2874 MUST use the larger
+   required value in EDNS0 advertisements.
+
+4.  Acknowledgments
+
+   Harald Alvestrand, Rob Austein, Randy Bush, David Conrad, Andreas
+   Gustafsson, Jun-ichiro itojun Hagino, Bob Halley, Edward Lewis
+   Michael Patton and Kazu Yamamoto were instrumental in motivating and
+   shaping this document.
+
+5.  Security Considerations:
+
+   There are no additional security considerations other than those in
+   RFC 2671.
+
+6.  IANA Considerations:
+
+   None
+
+
+
+
+
+Gudmundsson                 Standards Track                     [Page 4]
+
+RFC 3226            DNSSEC and IPv6 A6 requirements        December 2001
+
+
+7.  References
+
+   [RFC1034]  Mockapetris, P., "Domain Names - Concepts and Facilities",
+              STD 13, RFC 1034, November 1987.
+
+   [RFC1035]  Mockapetris, P., "Domain Names - Implementation and
+              Specification", STD 13, RFC 1035, November 1987.
+
+   [RFC2535]  Eastlake, D. "Domain Name System Security Extensions", RFC
+              2535, March 1999.
+
+   [RFC2671]  Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
+              2671, August 1999.
+
+   [RFC2845]  Vixie, P., Gudmundsson, O., Eastlake, D. and B.
+              Wellington, "Secret Key Transaction Authentication for DNS
+              (TSIG)", RFC 2845, May 2000.
+
+   [RFC2874]  Crawford, M. and C. Huitema, "DNS Extensions to Support
+              IPv6 Address Aggregation and Renumbering", RFC 2874, July
+              2000.
+
+   [RFC3225]  Conrad, D., "Indicating Resolver Support of DNSSEC", RFC
+              3225, December 2001.
+
+8.  Author Address
+
+   Olafur Gudmundsson
+   3826 Legation Street, NW
+   Washington, DC 20015
+   USA
+
+   EMail: ogud@ogud.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gudmundsson                 Standards Track                     [Page 5]
+
+RFC 3226            DNSSEC and IPv6 A6 requirements        December 2001
+
+
+9.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2001).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gudmundsson                 Standards Track                     [Page 6]
+
diff --git a/doc/rfc/rfc3258.txt b/doc/rfc/rfc3258.txt
new file mode 100644
index 0000000..dcd4b34
--- /dev/null
+++ b/doc/rfc/rfc3258.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+Network Working Group                                          T. Hardie
+Request for Comments: 3258                                 Nominum, Inc.
+Category: Informational                                       April 2002
+
+
+  Distributing Authoritative Name Servers via Shared Unicast Addresses
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+
+Abstract
+
+   This memo describes a set of practices intended to enable an
+   authoritative name server operator to provide access to a single
+   named server in multiple locations.  The primary motivation for the
+   development and deployment of these practices is to increase the
+   distribution of Domain Name System (DNS) servers to previously
+   under-served areas of the network topology and to reduce the latency
+   for DNS  query responses in those areas.
+
+1.  Introduction
+
+   This memo describes a set of practices intended to enable an
+   authoritative name server operator to provide access to a single
+   named server in multiple locations.  The primary motivation for the
+   development and deployment of these practices is to increase the
+   distribution of DNS servers to previously under-served areas of the
+   network topology and to reduce the latency for DNS query responses in
+   those areas.  This document presumes a one-to-one mapping between
+   named authoritative servers and administrative entities (operators).
+   This document contains no guidelines or recommendations for caching
+   name servers.  The shared unicast system described here is specific
+   to IPv4; applicability to IPv6 is an area for further study.  It
+   should also be noted that the system described here is related to
+   that described in [ANYCAST], but it does not require dedicated
+   address space, routing changes, or the other elements of a full
+   anycast infrastructure which that document describes.
+
+
+
+
+
+
+
+Hardie                       Informational                      [Page 1]
+
+RFC 3258        Distributing Authoritative Name Servers       April 2002
+
+
+2.  Architecture
+
+2.1 Server Requirements
+
+   Operators of authoritative name servers may wish to refer to
+   [SECONDARY] and [ROOT] for general guidance on appropriate practice
+   for authoritative name servers.  In addition to proper configuration
+   as a standard authoritative name server, each of the hosts
+   participating in a shared-unicast system should be configured with
+   two network interfaces.  These interfaces may be either two physical
+   interfaces or one physical interface mapped to two logical
+   interfaces.  One of the network interfaces should use the IPv4 shared
+   unicast address associated with the authoritative name server.  The
+   other interface, referred to as the administrative interface below,
+   should use a distinct IPv4 address specific to that host.  The host
+   should respond to DNS queries only on the shared-unicast interface.
+   In order to provide the most consistent set of responses from the
+   mesh of anycast hosts, it is good practice to limit responses on that
+   interface to zones for which the host is authoritative.
+
+2.2 Zone file delivery
+
+   In order to minimize the risk of man-in-the-middle attacks, zone
+   files should be delivered to the administrative interface of the
+   servers participating in the mesh.  Secure file transfer methods and
+   strong authentication should be used for all transfers.  If the hosts
+   in the mesh make their zones available for zone transfer, the
+   administrative interfaces should be used for those transfers as well,
+   in order to avoid the problems with potential routing changes for TCP
+   traffic noted in section 2.5 below.
+
+2.3 Synchronization
+
+   Authoritative name servers may be loosely or tightly synchronized,
+   depending on the practices set by the operating organization.  As
+   noted below in section 4.1.2, lack of synchronization among servers
+   using the same shared unicast address could create problems for some
+   users of this service.  In order to minimize that risk, switch-overs
+   from one data set to another data set should be coordinated as much
+   as possible.  The use of synchronized clocks on the participating
+   hosts and set times for switch-overs provides a basic level of
+   coordination.  A more complete coordination process would involve:
+
+      a) receipt of zones at a distribution host
+      b) confirmation of the integrity of zones received
+      c) distribution of the zones to all of the servers in the mesh
+      d) confirmation of the integrity of the zones at each server
+
+
+
+
+Hardie                       Informational                      [Page 2]
+
+RFC 3258        Distributing Authoritative Name Servers       April 2002
+
+
+      e) coordination of the switchover times for the servers in the
+         mesh
+      f) institution of a failure process to ensure that servers that
+         did not receive correct data or could not switchover to the new
+         data ceased to respond to incoming queries until the problem
+         could be resolved.
+
+   Depending on the size of the mesh, the distribution host may also be
+   a participant; for authoritative servers, it may also be the host on
+   which zones are generated.
+
+   This document presumes that the usual DNS failover methods are the
+   only ones used to ensure reachability of the data for clients.  It
+   does not advise that the routes be withdrawn in the case of failure;
+   it advises instead that the DNS process shutdown so that servers on
+   other addresses are queried.  This recommendation reflects a choice
+   between performance and operational complexity.  While it would be
+   possible to have some process withdraw the route for a specific
+   server instance when it is not available, there is considerable
+   operational complexity involved in ensuring that this occurs
+   reliably.  Given the existing DNS failover methods, the marginal
+   improvement in performance will not be sufficient to justify the
+   additional complexity for most uses.
+
+2.4 Server Placement
+
+   Though the geographic diversity of server placement helps reduce the
+   effects of service disruptions due to local problems, it is diversity
+   of placement in the network topology which is the driving force
+   behind these distribution practices.  Server placement should
+   emphasize that diversity.  Ideally, servers should be placed
+   topologically near the points at which the operator exchanges routes
+   and traffic with other networks.
+
+2.5 Routing
+
+   The organization administering the mesh of servers sharing a unicast
+   address must have an autonomous system number and speak BGP to its
+   peers.  To those peers, the organization announces a route to the
+   network containing the shared-unicast address of the name server.
+   The organization's border routers must then deliver the traffic
+   destined for the name server to the nearest instantiation.  Routing
+   to the administrative interfaces for the servers can use the normal
+   routing methods for the administering organization.
+
+   One potential problem with using shared unicast addresses is that
+   routers forwarding traffic to them may have more than one available
+   route, and those routes may, in fact, reach different instances of
+
+
+
+Hardie                       Informational                      [Page 3]
+
+RFC 3258        Distributing Authoritative Name Servers       April 2002
+
+
+   the shared unicast address.  Applications like the DNS, whose
+   communication typically consists of independent request-response
+   messages each fitting in a single UDP packet present no problem.
+   Other applications, in which multiple packets must reach the same
+   endpoint (e.g., TCP) may fail or present unworkable performance
+   characteristics in some circumstances.  Split-destination failures
+   may occur when a router does per-packet (or round-robin) load
+   sharing, a topology change occurs that changes the relative metrics
+   of two paths to the same anycast destination, etc.
+
+   Four things mitigate the severity of this problem.  The first is that
+   UDP is a fairly high proportion of the query traffic to name servers.
+   The second is that the aim of this proposal is to diversify
+   topological placement; for most users, this means that the
+   coordination of placement will ensure that new instances of a name
+   server will be at a significantly different cost metric from existing
+   instances.  Some set of users may end up in the middle, but that
+   should be relatively rare.  The third is that per packet load sharing
+   is only one of the possible load sharing mechanisms, and other
+   mechanisms are increasing in popularity.
+
+   Lastly, in the case where the traffic is TCP, per packet load sharing
+   is used, and equal cost routes to different instances of a name
+   server are available, any DNS implementation which measures the
+   performance of servers to select a preferred server will quickly
+   prefer a server for which this problem does not occur.  For the DNS
+   failover mechanisms to reliably avoid this problem, however, those
+   using shared unicast distribution mechanisms must take care that all
+   of the servers for a specific zone are not participants in the same
+   shared-unicast mesh.  To guard even against the case where multiple
+   meshes have a set of users affected by per packet load sharing along
+   equal cost routes, organizations implementing these practices should
+   always provide at least one authoritative server which is not a
+   participant in any shared unicast mesh.  Those deploying shared-
+   unicast meshes should note that any specific host may become
+   unreachable to a client should a server fail, a path fail, or the
+   route to that host be withdrawn.  These error conditions are,
+   however, not specific to shared-unicast distributions, but would
+   occur for standard unicast hosts.
+
+   Since ICMP response packets might go to a different member of the
+   mesh than that sending a packet, packets sent with a shared unicast
+   source address should also avoid using path MTU discovery.
+
+   Appendix A. contains an ASCII diagram of an example of a simple
+   implementation of this system.  In it, the odd numbered routers
+   deliver traffic to the shared-unicast interface network and filter
+   traffic from the administrative network; the even numbered routers
+
+
+
+Hardie                       Informational                      [Page 4]
+
+RFC 3258        Distributing Authoritative Name Servers       April 2002
+
+
+   deliver traffic to the administrative network and filter traffic from
+   the shared-unicast network.  These are depicted as separate routers
+   for the ease this gives in explanation, but they could easily be
+   separate interfaces on the same router.  Similarly, a local NTP
+   source is depicted for synchronization, but the level of
+   synchronization needed would not require that source to be either
+   local or a stratum one NTP server.
+
+3. Administration
+
+3.1 Points of Contact
+
+   A single point of contact for reporting problems is crucial to the
+   correct administration of this system.  If an external user of the
+   system needs to report a problem related to the service, there must
+   be no ambiguity about whom to contact.  If internal monitoring does
+   not indicate a problem, the contact may, of course, need to work with
+   the external user to identify which server generated the error.
+
+4. Security Considerations
+
+   As a core piece of Internet infrastructure, authoritative name
+   servers are common targets of attack.  The practices outlined here
+   increase the risk of certain kinds of attacks and reduce the risk of
+   others.
+
+4.1 Increased Risks
+
+4.1.1 Increase in physical servers
+
+   The architecture outlined in this document increases the number of
+   physical servers, which could increase the possibility that a server
+   mis-configuration will occur which allows for a security breach.  In
+   general, the entity administering a mesh should ensure that patches
+   and security mechanisms applied to a single member of the mesh are
+   appropriate for and applied to all of the members of a mesh.
+   "Genetic diversity" (code from different code bases) can be a useful
+   security measure in avoiding attacks based on vulnerabilities in a
+   specific code base; in order to ensure consistency of responses from
+   a single named server, however, that diversity should be applied to
+   different shared-unicast meshes or between a mesh and a related
+   unicast authoritative server.
+
+4.1.2 Data synchronization problems
+
+   The level of systemic synchronization described above should be
+   augmented by synchronization of the data present at each of the
+   servers.  While the DNS itself is a loosely coupled system, debugging
+
+
+
+Hardie                       Informational                      [Page 5]
+
+RFC 3258        Distributing Authoritative Name Servers       April 2002
+
+
+   problems with data in specific zones would be far more difficult if
+   two different servers sharing a single unicast address might return
+   different responses to the same query.  For example, if the data
+   associated with www.example.com has changed and the administrators of
+   the domain are testing for the changes at the example.com
+   authoritative name servers, they should not need to check each
+   instance of a named authoritative server.  The use of NTP to provide
+   a synchronized time for switch-over eliminates some aspects of this
+   problem, but mechanisms to handle failure during the switchover are
+   required.  In particular, a server which cannot make the switchover
+   must not roll-back to a previous version; it must cease to respond to
+   queries so that other servers are queried.
+
+4.1.3 Distribution risks
+
+   If the mechanism used to distribute zone files among the servers is
+   not well secured, a man-in-the-middle attack could result in the
+   injection of false information.  Digital signatures will alleviate
+   this risk, but encrypted transport and tight access lists are a
+   necessary adjunct to them.  Since zone files will be distributed to
+   the administrative interfaces of meshed servers, the access control
+   list for distribution of the zone files should include the
+   administrative interface of the server or servers, rather than their
+   shared unicast addresses.
+
+4.2 Decreased Risks
+
+   The increase in number of physical servers reduces the likelihood
+   that a denial-of-service attack will take out a significant portion
+   of the DNS infrastructure.  The increase in servers also reduces the
+   effect of machine crashes, fiber cuts, and localized disasters by
+   reducing the number of users dependent on a specific machine.
+
+5. Acknowledgments
+
+   Masataka Ohta, Bill Manning, Randy Bush, Chris Yarnell, Ray Plzak,
+   Mark Andrews, Robert Elz, Geoff Huston, Bill Norton, Akira Kato,
+   Suzanne Woolf, Bernard Aboba, Casey Ajalat, and Gunnar Lindberg all
+   provided input and commentary on this work.  The editor wishes to
+   remember in particular the contribution of the late Scott Tucker,
+   whose extensive systems experience and plain common sense both
+   contributed greatly to the editor's own deployment experience and are
+   missed by all who knew him.
+
+
+
+
+
+
+
+
+Hardie                       Informational                      [Page 6]
+
+RFC 3258        Distributing Authoritative Name Servers       April 2002
+
+
+6. References
+
+   [SECONDARY] Elz, R., Bush, R., Bradner, S. and M. Patton, "Selection
+               and Operation of Secondary DNS Servers", BCP 16, RFC
+               2182, July 1997.
+
+   [ROOT]      Bush, R., Karrenberg, D., Kosters, M. and R. Plzak, "Root
+               Name Server Operational Requirements", BCP 40, RFC 2870,
+               June 2000.
+
+   [ANYCAST]   Patridge, C., Mendez, T. and W. Milliken, "Host
+               Anycasting Service", RFC 1546, November 1993.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hardie                       Informational                      [Page 7]
+
+RFC 3258        Distributing Authoritative Name Servers       April 2002
+
+
+Appendix A.
+
+       __________________
+Peer 1-|                |
+Peer 2-|                |
+Peer 3-|     Switch     |
+Transit|                |  _________                   _________
+etc    |                |--|Router1|---|----|----------|Router2|---WAN-|
+       |                |  ---------   |    |          ---------       |
+       |                |              |    |                          |
+       |                |              |    |                          |
+       ------------------            [NTP] [DNS]                       |
+                                                                       |
+                                                                       |
+                                                                       |
+                                                                       |
+       __________________                                              |
+Peer 1-|                |                                              |
+Peer 2-|                |                                              |
+Peer 3-|     Switch     |                                              |
+Transit|                |  _________                   _________       |
+etc    |                |--|Router3|---|----|----------|Router4|---WAN-|
+       |                |  ---------   |    |          ---------       |
+       |                |              |    |                          |
+       |                |              |    |                          |
+       ------------------            [NTP] [DNS]                       |
+                                                                       |
+                                                                       |
+                                                                       |
+                                                                       |
+       __________________                                              |
+Peer 1-|                |                                              |
+Peer 2-|                |                                              |
+Peer 3-|     Switch     |                                              |
+Transit|                |  _________                   _________       |
+etc    |                |--|Router5|---|----|----------|Router6|---WAN-|
+       |                |  ---------   |    |          ---------       |
+       |                |              |    |                          |
+       |                |              |    |                          |
+       ------------------            [NTP] [DNS]                       |
+                                                                       |
+                                                                       |
+                                                                       |
+
+
+
+
+
+
+
+
+Hardie                       Informational                      [Page 8]
+
+RFC 3258        Distributing Authoritative Name Servers       April 2002
+
+
+                                                                       |
+       __________________                                              |
+Peer 1-|                |                                              |
+Peer 2-|                |                                              |
+Peer 3-|     Switch     |                                              |
+Transit|                |  _________                   _________       |
+etc    |                |--|Router7|---|----|----------|Router8|---WAN-|
+       |                |  ---------   |    |          ---------
+       |                |              |    |
+       |                |              |    |
+       ------------------            [NTP] [DNS]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hardie                       Informational                      [Page 9]
+
+RFC 3258        Distributing Authoritative Name Servers       April 2002
+
+
+7. Editor's Address
+
+   Ted Hardie
+   Nominum, Inc.
+   2385 Bay Road.
+   Redwood City, CA 94063
+
+   Phone: 1.650.381.6226
+   EMail: Ted.Hardie@nominum.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hardie                       Informational                     [Page 10]
+
+RFC 3258        Distributing Authoritative Name Servers       April 2002
+
+
+8.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hardie                       Informational                     [Page 11]
+
diff --git a/doc/rfc/rfc3363.txt b/doc/rfc/rfc3363.txt
new file mode 100644
index 0000000..9d7a39c
--- /dev/null
+++ b/doc/rfc/rfc3363.txt
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+Network Working Group                                            R. Bush
+Request for Comments: 3363                                     A. Durand
+Updates: 2673, 2874                                              B. Fink
+Category: Informational                                   O. Gudmundsson
+                                                                 T. Hain
+                                                                 Editors
+                                                             August 2002
+
+
+            Representing Internet Protocol version 6 (IPv6)
+               Addresses in the Domain Name System (DNS)
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+
+Abstract
+
+   This document clarifies and updates the standards status of RFCs that
+   define direct and reverse map of IPv6 addresses in DNS.  This
+   document moves the A6 and Bit label specifications to experimental
+   status.
+
+1.  Introduction
+
+   The IETF had begun the process of standardizing two different address
+   formats for IPv6 addresses AAAA [RFC1886] and A6 [RFC2874] and both
+   are at proposed standard.  This had led to confusion and conflicts on
+   which one to deploy.  It is important for deployment that any
+   confusion in this area be cleared up, as there is a feeling in the
+   community that having more than one choice will lead to delays in the
+   deployment of IPv6.  The goal of this document is to clarify the
+   situation.
+
+   This document also discusses issues relating to the usage of Binary
+   Labels [RFC 2673] to support the reverse mapping of IPv6 addresses.
+
+   This document is based on extensive technical discussion on various
+   relevant working groups mailing lists and a joint DNSEXT and NGTRANS
+   meeting at the 51st IETF in August 2001.  This document attempts to
+   capture the sense of the discussions and reflect them in this
+   document to represent the consensus of the community.
+
+
+
+Bush, et. al.                Informational                      [Page 1]
+
+RFC 3363        Representation of IPv6 Addresses in DNS      August 2002
+
+
+   The main arguments and the issues are covered in a separate document
+   [RFC3364] that reflects the current understanding of the issues.
+   This document summarizes the outcome of these discussions.
+
+   The issue of the root of reverse IPv6 address map is outside the
+   scope of this document and is covered in a different document
+   [RFC3152].
+
+1.1 Standards Action Taken
+
+   This document changes the status of RFCs 2673 and 2874 from Proposed
+   Standard to Experimental.
+
+2.  IPv6 Addresses: AAAA RR vs A6 RR
+
+   Working group consensus as perceived by the chairs of the DNSEXT and
+   NGTRANS working groups is that:
+
+   a) AAAA records are preferable at the moment for production
+      deployment of IPv6, and
+
+   b) that A6 records have interesting properties that need to be better
+      understood before deployment.
+
+   c) It is not known if the benefits of A6 outweigh the costs and
+      risks.
+
+2.1 Rationale
+
+   There are several potential issues with A6 RRs that stem directly
+   from the feature that makes them different from AAAA RRs: the ability
+   to build up addresses via chaining.
+
+   Resolving a chain of A6 RRs involves resolving a series of what are
+   nearly-independent queries.  Each of these sub-queries takes some
+   non-zero amount of time, unless the answer happens to be in the
+   resolver's local cache already.  Other things being equal, we expect
+   that the time it takes to resolve an N-link chain of A6 RRs will be
+   roughly proportional to N.  What data we have suggests that users are
+   already impatient with the length of time it takes to resolve A RRs
+   in the IPv4 Internet, which suggests that users are not likely to be
+   patient with significantly longer delays in the IPv6 Internet, but
+   terminating queries prematurely is both a waste of resources and
+   another source of user frustration.  Thus, we are forced to conclude
+   that indiscriminate use of long A6 chains is likely to lead to
+   increased user frustration.
+
+
+
+
+
+Bush, et. al.                Informational                      [Page 2]
+
+RFC 3363        Representation of IPv6 Addresses in DNS      August 2002
+
+
+   The probability of failure during the process of resolving an N-link
+   A6 chain also appears to be roughly proportional to N, since each of
+   the queries involved in resolving an A6 chain has roughly the same
+   probability of failure as a single AAAA query.
+
+   Last, several of the most interesting potential applications for A6
+   RRs involve situations where the prefix name field in the A6 RR
+   points to a target that is not only outside the DNS zone containing
+   the A6 RR, but is administered by a different organization entirely.
+   While pointers out of zone are not a problem per se, experience both
+   with glue RRs and with PTR RRs in the IN-ADDR.ARPA tree suggests that
+   pointers to other organizations are often not maintained properly,
+   perhaps because they're less susceptible to automation than pointers
+   within a single organization would be.
+
+2.2 Recommended Standard Action
+
+   Based on the perceived consensus, this document recommends that RFC
+   1886 stay on standards track and be advanced, while moving RFC 2874
+   to Experimental status.
+
+3.  Bitlabels in the Reverse DNS Tree
+
+   RFC 2673 defines a new DNS label type.  This was the first new type
+   defined since RFC 1035 [RFC1035].  Since the development of 2673 it
+   has been learned that deployment of a new type is difficult since DNS
+   servers that do not support bitlabels reject queries containing bit
+   labels as being malformed.  The community has also indicated that
+   this new label type is not needed for mapping reverse addresses.
+
+3.1 Rationale
+
+   The hexadecimal text representation of IPv6 addresses appears to be
+   capable of expressing all of the delegation schemes that we expect to
+   be used in the DNS reverse tree.
+
+3.2 Recommended Standard Action
+
+   RFC 2673 standard status is to be changed from Proposed to
+   Experimental.  Future standardization of these documents is to be
+   done by the DNSEXT working group or its successor.
+
+
+
+
+
+
+
+
+
+
+Bush, et. al.                Informational                      [Page 3]
+
+RFC 3363        Representation of IPv6 Addresses in DNS      August 2002
+
+
+4.  DNAME in IPv6 Reverse Tree
+
+   The issues for DNAME in the reverse mapping tree appears to be
+   closely tied to the need to use fragmented A6 in the main tree: if
+   one is necessary, so is the other, and if one isn't necessary, the
+   other isn't either.  Therefore, in moving RFC 2874 to experimental,
+   the intent of this document is that use of DNAME RRs in the reverse
+   tree be deprecated.
+
+5.  Acknowledgments
+
+   This document is based on input from many members of the various IETF
+   working groups involved in this issues.  Special thanks go to the
+   people that prepared reading material for the joint DNSEXT and
+   NGTRANS working group meeting at the 51st IETF in London, Rob
+   Austein, Dan Bernstein, Matt Crawford, Jun-ichiro itojun Hagino,
+   Christian Huitema.  Number of other people have made number of
+   comments on mailing lists about this issue including Andrew W.
+   Barclay, Robert Elz, Johan Ihren, Edward Lewis, Bill Manning, Pekka
+   Savola, Paul Vixie.
+
+6.  Security Considerations
+
+   As this document specifies a course of action, there are no direct
+   security considerations.  There is an indirect security impact of the
+   choice, in that the relationship between A6 and DNSSEC is not well
+   understood throughout the community, while the choice of AAAA does
+   leads to a model for use of DNSSEC in IPv6 networks which parallels
+   current IPv4 practice.
+
+7.  IANA Considerations
+
+   None.
+
+Normative References
+
+   [RFC1035]  Mockapetris, P., "Domain Names - Implementation and
+              Specification", STD 13, RFC 1035, November 1987.
+
+   [RFC1886]  Thompson, S. and C. Huitema, "DNS Extensions to support IP
+              version 6", RFC 1886, December 1995.
+
+   [RFC2673]  Crawford, M., "Binary Labels in the Domain Name System",
+              RFC 2673, August 1999.
+
+   [RFC2874]  Crawford, M. and C. Huitema, "DNS Extensions to Support
+              IPv6 Address Aggregation and Renumbering", RFC 2874, July
+              2000.
+
+
+
+Bush, et. al.                Informational                      [Page 4]
+
+RFC 3363        Representation of IPv6 Addresses in DNS      August 2002
+
+
+   [RFC3152]  Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152
+              August 2001.
+
+Informative References
+
+   [RFC3364]  Austein, R., "Tradeoffs in Domain Name System (DNS)
+              Support for Internet Protocol version 6 (IPv6)", RFC 3364,
+              August 2002.
+
+Editors' Addresses
+
+   Randy Bush
+   EMail: randy@psg.com
+
+
+   Alain Durand
+   EMail: alain.durand@sun.com
+
+
+   Bob Fink
+   EMail: fink@es.net
+
+
+   Olafur Gudmundsson
+   EMail: ogud@ogud.com
+
+
+   Tony Hain
+   EMail: hain@tndh.net
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bush, et. al.                Informational                      [Page 5]
+
+RFC 3363        Representation of IPv6 Addresses in DNS      August 2002
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bush, et. al.                Informational                      [Page 6]
+
diff --git a/doc/rfc/rfc3364.txt b/doc/rfc/rfc3364.txt
new file mode 100644
index 0000000..189c0d2
--- /dev/null
+++ b/doc/rfc/rfc3364.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+Network Working Group                                         R. Austein
+Request for Comments: 3364                           Bourgeois Dilettant
+Updates: 2673, 2874                                          August 2002
+Category: Informational
+
+
+             Tradeoffs in Domain Name System (DNS) Support
+                 for Internet Protocol version 6 (IPv6)
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+
+Abstract
+
+   The IETF has two different proposals on the table for how to do DNS
+   support for IPv6, and has thus far failed to reach a clear consensus
+   on which approach is better.  This note attempts to examine the pros
+   and cons of each approach, in the hope of clarifying the debate so
+   that we can reach closure and move on.
+
+Introduction
+
+   RFC 1886 [RFC1886] specified straightforward mechanisms to support
+   IPv6 addresses in the DNS.  These mechanisms closely resemble the
+   mechanisms used to support IPv4, with a minor improvement to the
+   reverse mapping mechanism based on experience with CIDR.  RFC 1886 is
+   currently listed as a Proposed Standard.
+
+   RFC 2874 [RFC2874] specified enhanced mechanisms to support IPv6
+   addresses in the DNS.  These mechanisms provide new features that
+   make it possible for an IPv6 address stored in the DNS to be broken
+   up into multiple DNS resource records in ways that can reflect the
+   network topology underlying the address, thus making it possible for
+   the data stored in the DNS to reflect certain kinds of network
+   topology changes or routing architectures that are either impossible
+   or more difficult to represent without these mechanisms.  RFC 2874 is
+   also currently listed as a Proposed Standard.
+
+
+
+
+
+
+
+Austein                      Informational                      [Page 1]
+
+RFC 3364           Tradeoffs in DNS Support for IPv6         August 2002
+
+
+   Both of these Proposed Standards were the output of the IPNG Working
+   Group.  Both have been implemented, although implementation of
+   [RFC1886] is more widespread, both because it was specified earlier
+   and because it's simpler to implement.
+
+   There's little question that the mechanisms proposed in [RFC2874] are
+   more general than the mechanisms proposed in [RFC1886], and that
+   these enhanced mechanisms might be valuable if IPv6's evolution goes
+   in certain directions.  The questions are whether we really need the
+   more general mechanism, what new usage problems might come along with
+   the enhanced mechanisms, and what effect all this will have on IPv6
+   deployment.
+
+   The one thing on which there does seem to be widespread agreement is
+   that we should make up our minds about all this Real Soon Now.
+
+Main Advantages of Going with A6
+
+   While the A6 RR proposed in [RFC2874] is very general and provides a
+   superset of the functionality provided by the AAAA RR in [RFC1886],
+   many of the features of A6 can also be implemented with AAAA RRs via
+   preprocessing during zone file generation.
+
+   There is one specific area where A6 RRs provide something that cannot
+   be provided using AAAA RRs: A6 RRs can represent addresses in which a
+   prefix portion of the address can change without any action (or
+   perhaps even knowledge) by the parties controlling the DNS zone
+   containing the terminal portion (least significant bits) of the
+   address.  This includes both so-called "rapid renumbering" scenarios
+   (where an entire network's prefix may change very quickly) and
+   routing architectures such as the former "GSE" proposal [GSE] (where
+   the "routing goop" portion of an address may be subject to change
+   without warning).  A6 RRs do not completely remove the need to update
+   leaf zones during all renumbering events (for example, changing ISPs
+   would usually require a change to the upward delegation pointer), but
+   careful use of A6 RRs could keep the number of RRs that need to
+   change during such an event to a minimum.
+
+   Note that constructing AAAA RRs via preprocessing during zone file
+   generation requires exactly the sort of information that A6 RRs store
+   in the DNS.  This begs the question of where the hypothetical
+   preprocessor obtains that information if it's not getting it from the
+   DNS.
+
+   Note also that the A6 RR, when restricted to its zero-length-prefix
+   form ("A6 0"), is semantically equivalent to an AAAA RR (with one
+   "wasted" octet in the wire representation), so anything that can be
+   done with an AAAA RR can also be done with an A6 RR.
+
+
+
+Austein                      Informational                      [Page 2]
+
+RFC 3364           Tradeoffs in DNS Support for IPv6         August 2002
+
+
+Main Advantages of Going with AAAA
+
+   The AAAA RR proposed in [RFC1886], while providing only a subset of
+   the functionality provided by the A6 RR proposed in [RFC2874], has
+   two main points to recommend it:
+
+   - AAAA RRs are essentially identical (other than their length) to
+     IPv4's A RRs, so we have more than 15 years of experience to help
+     us predict the usage patterns, failure scenarios and so forth
+     associated with AAAA RRs.
+
+   - The AAAA RR is "optimized for read", in the sense that, by storing
+     a complete address rather than making the resolver fetch the
+     address in pieces, it minimizes the effort involved in fetching
+     addresses from the DNS (at the expense of increasing the effort
+     involved in injecting new data into the DNS).
+
+Less Compelling Arguments in Favor of A6
+
+   Since the A6 RR allows a zone administrator to write zone files whose
+   description of addresses maps to the underlying network topology, A6
+   RRs can be construed as a "better" way of representing addresses than
+   AAAA.  This may well be a useful capability, but in and of itself
+   it's more of an argument for better tools for zone administrators to
+   use when constructing zone files than a justification for changing
+   the resolution protocol used on the wire.
+
+Less Compelling Arguments in Favor of AAAA
+
+   Some of the pressure to go with AAAA instead of A6 appears to be
+   based on the wider deployment of AAAA.  Since it is possible to
+   construct transition tools (see discussion of AAAA synthesis, later
+   in this note), this does not appear to be a compelling argument if A6
+   provides features that we really need.
+
+   Another argument in favor of AAAA RRs over A6 RRs appears to be that
+   the A6 RR's advanced capabilities increase the number of ways in
+   which a zone administrator could build a non-working configuration.
+   While operational issues are certainly important, this is more of
+   argument that we need better tools for zone administrators than it is
+   a justification for turning away from A6 if A6 provides features that
+   we really need.
+
+
+
+
+
+
+
+
+
+Austein                      Informational                      [Page 3]
+
+RFC 3364           Tradeoffs in DNS Support for IPv6         August 2002
+
+
+Potential Problems with A6
+
+   The enhanced capabilities of the A6 RR, while interesting, are not in
+   themselves justification for choosing A6 if we don't really need
+   those capabilities.  The A6 RR is "optimized for write", in the sense
+   that, by making it possible to store fragmented IPv6 addresses in the
+   DNS, it makes it possible to reduce the effort that it takes to
+   inject new data into the DNS (at the expense of increasing the effort
+   involved in fetching data from the DNS).  This may be justified if we
+   expect the effort involved in maintaining AAAA-style DNS entries to
+   be prohibitive, but in general, we expect the DNS data to be read
+   more frequently than it is written, so we need to evaluate this
+   particular tradeoff very carefully.
+
+   There are also several potential issues with A6 RRs that stem
+   directly from the feature that makes them different from AAAA RRs:
+   the ability to build up address via chaining.
+
+   Resolving a chain of A6 RRs involves resolving a series of what are
+   almost independent queries, but not quite.  Each of these sub-queries
+   takes some non-zero amount of time, unless the answer happens to be
+   in the resolver's local cache already.  Assuming that resolving an
+   AAAA RR takes time T as a baseline, we can guess that, on the
+   average, it will take something approaching time N*T to resolve an
+   N-link chain of A6 RRs, although we would expect to see a fairly good
+   caching factor for the A6 fragments representing the more significant
+   bits of an address.  This leaves us with two choices, neither of
+   which is very good:  we can decrease the amount of time that the
+   resolver is willing to wait for each fragment, or we can increase the
+   amount of time that a resolver is willing to wait before returning
+   failure to a client.  What little data we have on this subject
+   suggests that users are already impatient with the length of time it
+   takes to resolve A RRs in the IPv4 Internet, which suggests that they
+   are not likely to be patient with significantly longer delays in the
+   IPv6 Internet.  At the same time, terminating queries prematurely is
+   both a waste of resources and another source of user frustration.
+   Thus, we are forced to conclude that indiscriminate use of long A6
+   chains is likely to lead to problems.
+
+   To make matters worse, the places where A6 RRs are likely to be most
+   critical for rapid renumbering or GSE-like routing are situations
+   where the prefix name field in the A6 RR points to a target that is
+   not only outside the DNS zone containing the A6 RR, but is
+   administered by a different organization (for example, in the case of
+   an end user's site, the prefix name will most likely point to a name
+   belonging to an ISP that provides connectivity for the site).  While
+   pointers out of zone are not a problem per se, pointers to other
+   organizations are somewhat more difficult to maintain and less
+
+
+
+Austein                      Informational                      [Page 4]
+
+RFC 3364           Tradeoffs in DNS Support for IPv6         August 2002
+
+
+   susceptible to automation than pointers within a single organization
+   would be.  Experience both with glue RRs and with PTR RRs in the IN-
+   ADDR.ARPA tree suggests that many zone administrators do not really
+   understand how to set up and maintain these pointers properly, and we
+   have no particular reason to believe that these zone administrators
+   will do a better job with A6 chains than they do today.  To be fair,
+   however, the alternative case of building AAAA RRs via preprocessing
+   before loading zones has many of the same problems; at best, one can
+   claim that using AAAA RRs for this purpose would allow DNS clients to
+   get the wrong answer somewhat more efficiently than with A6 RRs.
+
+   Finally, assuming near total ignorance of how likely a query is to
+   fail, the probability of failure with an N-link A6 chain would appear
+   to be roughly proportional to N, since each of the queries involved
+   in resolving an A6 chain would have the same probability of failure
+   as a single AAAA query.  Note again that this comment applies to
+   failures in the the process of resolving a query, not to the data
+   obtained via that process.  Arguably, in an ideal world, A6 RRs would
+   increase the probability of the answer a client (finally) gets being
+   right, assuming that nothing goes wrong in the query process, but we
+   have no real idea how to quantify that assumption at this point even
+   to the hand-wavey extent used elsewhere in this note.
+
+   One potential problem that has been raised in the past regarding A6
+   RRs turns out not to be a serious issue.  The A6 design includes the
+   possibility of there being more than one A6 RR matching the prefix
+   name portion of a leaf A6 RR.  That is, an A6 chain may not be a
+   simple linked list, it may in fact be a tree, where each branch
+   represents a possible prefix.  Some critics of A6 have been concerned
+   that this will lead to a wild expansion of queries, but this turns
+   out not to be a problem if a resolver simply follows the "bounded
+   work per query" rule described in RFC 1034 (page 35).  That rule
+   applies to all work resulting from attempts to process a query,
+   regardless of whether it's a simple query, a CNAME chain, an A6 tree,
+   or an infinite loop.  The client may not get back a useful answer in
+   cases where the zone has been configured badly, but a proper
+   implementation should not produce a query explosion as a result of
+   processing even the most perverse A6 tree, chain, or loop.
+
+Interactions with DNSSEC
+
+   One of the areas where AAAA and A6 RRs differ is in the precise
+   details of how they interact with DNSSEC.  The following comments
+   apply only to non-zero-prefix A6 RRs (A6 0 RRs, once again, are
+   semantically equivalent to AAAA RRs).
+
+
+
+
+
+
+Austein                      Informational                      [Page 5]
+
+RFC 3364           Tradeoffs in DNS Support for IPv6         August 2002
+
+
+   Other things being equal, the time it takes to re-sign all of the
+   addresses in a zone after a renumbering event is longer with AAAA RRs
+   than with A6 RRs (because each address record has to be re-signed
+   rather than just signing a common prefix A6 RR and a few A6 0 RRs
+   associated with the zone's name servers).  Note, however, that in
+   general this does not present a serious scaling problem, because the
+   re-signing is performed in the leaf zones.
+
+   Other things being equal, there's more work involved in verifying the
+   signatures received back for A6 RRs, because each address fragment
+   has a separate associated signature.  Similarly, a DNS message
+   containing a set of A6 address fragments and their associated
+   signatures will be larger than the equivalent packet with a single
+   AAAA (or A6 0) and a single associated signature.
+
+   Since AAAA RRs cannot really represent rapid renumbering or GSE-style
+   routing scenarios very well, it should not be surprising that DNSSEC
+   signatures of AAAA RRs are also somewhat problematic.  In cases where
+   the AAAA RRs would have to be changing very quickly to keep up with
+   prefix changes, the time required to re-sign the AAAA RRs may be
+   prohibitive.
+
+   Empirical testing by Bill Sommerfeld [Sommerfeld] suggests that
+   333MHz Celeron laptop with 128KB L2 cache and 64MB RAM running the
+   BIND-9 dnssec-signzone program under NetBSD can generate roughly 40
+   1024-bit RSA signatures per second.  Extrapolating from this,
+   assuming one A RR, one AAAA RR, and one NXT RR per host, this
+   suggests that it would take this laptop a few hours to sign a zone
+   listing 10**5 hosts, or about a day to sign a zone listing 10**6
+   hosts using AAAA RRs.
+
+   This suggests that the additional effort of re-signing a large zone
+   full of AAAA RRs during a re-numbering event, while noticeable, is
+   only likely to be prohibitive in the rapid renumbering case where
+   AAAA RRs don't work well anyway.
+
+Interactions with Dynamic Update
+
+   DNS dynamic update appears to work equally well for AAAA or A6 RRs,
+   with one minor exception: with A6 RRs, the dynamic update client
+   needs to know the prefix length and prefix name.  At present, no
+   mechanism exists to inform a dynamic update client of these values,
+   but presumably such a mechanism could be provided via an extension to
+   DHCP, or some other equivalent could be devised.
+
+
+
+
+
+
+
+Austein                      Informational                      [Page 6]
+
+RFC 3364           Tradeoffs in DNS Support for IPv6         August 2002
+
+
+Transition from AAAA to A6 Via AAAA Synthesis
+
+   While AAAA is at present more widely deployed than A6, it is possible
+   to transition from AAAA-aware DNS software to A6-aware DNS software.
+   A rough plan for this was presented at IETF-50 in Minneapolis and has
+   been discussed on the ipng mailing list.  So if the IETF concludes
+   that A6's enhanced capabilities are necessary, it should be possible
+   to transition from AAAA to A6.
+
+   The details of this transition have been left to a separate document,
+   but the general idea is that the resolver that is performing
+   iterative resolution on behalf of a DNS client program could
+   synthesize AAAA RRs representing the result of performing the
+   equivalent A6 queries.  Note that in this case it is not possible to
+   generate an equivalent DNSSEC signature for the AAAA RR, so clients
+   that care about performing DNSSEC validation for themselves would
+   have to issue A6 queries directly rather than relying on AAAA
+   synthesis.
+
+Bitlabels
+
+   While the differences between AAAA and A6 RRs have generated most of
+   the discussion to date, there are also two proposed mechanisms for
+   building the reverse mapping tree (the IPv6 equivalent of IPv4's IN-
+   ADDR.ARPA tree).
+
+   [RFC1886] proposes a mechanism very similar to the IN-ADDR.ARPA
+   mechanism used for IPv4 addresses: the RR name is the hexadecimal
+   representation of the IPv6 address, reversed and concatenated with a
+   well-known suffix, broken up with a dot between each hexadecimal
+   digit.  The resulting DNS names are somewhat tedious for humans to
+   type, but are very easy for programs to generate.  Making each
+   hexadecimal digit a separate label means that delegation on arbitrary
+   bit boundaries will result in a maximum of 16 NS RRsets per label
+   level; again, the mechanism is somewhat tedious for humans, but is
+   very easy to program.  As with IPv4's IN-ADDR.ARPA tree, the one
+   place where this scheme is weak is in handling delegations in the
+   least significant label; however, since there appears to be no real
+   need to delegate the least significant four bits of an IPv6 address,
+   this does not appear to be a serious restriction.
+
+   [RFC2874] proposed a radically different way of naming entries in the
+   reverse mapping tree: rather than using textual representations of
+   addresses, it proposes to use a new kind of DNS label (a "bit label")
+   to represent binary addresses directly in the DNS.  This has the
+   advantage of being significantly more compact than the textual
+   representation, and arguably might have been a better solution for
+   DNS to use for this purpose if it had been designed into the protocol
+
+
+
+Austein                      Informational                      [Page 7]
+
+RFC 3364           Tradeoffs in DNS Support for IPv6         August 2002
+
+
+   from the outset.  Unfortunately, experience to date suggests that
+   deploying a new DNS label type is very hard: all of the DNS name
+   servers that are authoritative for any portion of the name in
+   question must be upgraded before the new label type can be used, as
+   must any resolvers involved in the resolution process.  Any name
+   server that has not been upgraded to understand the new label type
+   will reject the query as being malformed.
+
+   Since the main benefit of the bit label approach appears to be an
+   ability that we don't really need (delegation in the least
+   significant four bits of an IPv6 address), and since the upgrade
+   problem is likely to render bit labels unusable until a significant
+   portion of the DNS code base has been upgraded, it is difficult to
+   escape the conclusion that the textual solution is good enough.
+
+DNAME RRs
+
+   [RFC2874] also proposes using DNAME RRs as a way of providing the
+   equivalent of A6's fragmented addresses in the reverse mapping tree.
+   That is, by using DNAME RRs, one can write zone files for the reverse
+   mapping tree that have the same ability to cope with rapid
+   renumbering or GSE-style routing that the A6 RR offers in the main
+   portion of the DNS tree.  Consequently, the need to use DNAME in the
+   reverse mapping tree appears to be closely tied to the need to use
+   fragmented A6 in the main tree: if one is necessary, so is the other,
+   and if one isn't necessary, the other isn't either.
+
+   Other uses have also been proposed for the DNAME RR, but since they
+   are outside the scope of the IPv6 address discussion, they will not
+   be addressed here.
+
+Recommendation
+
+   Distilling the above feature comparisons down to their key elements,
+   the important questions appear to be:
+
+   (a) Is IPv6 going to do rapid renumbering or GSE-like routing?
+
+   (b) Is the reverse mapping tree for IPv6 going to require delegation
+       in the least significant four bits of the address?
+
+   Question (a) appears to be the key to the debate.  This is really a
+   decision for the IPv6 community to make, not the DNS community.
+
+   Question (b) is also for the IPv6 community to make, but it seems
+   fairly obvious that the answer is "no".
+
+
+
+
+
+Austein                      Informational                      [Page 8]
+
+RFC 3364           Tradeoffs in DNS Support for IPv6         August 2002
+
+
+   Recommendations based on these questions:
+
+   (1) If the IPv6 working groups seriously intend to specify and deploy
+       rapid renumbering or GSE-like routing, we should transition to
+       using the A6 RR in the main tree and to using DNAME RRs as
+       necessary in the reverse tree.
+
+   (2) Otherwise, we should keep the simpler AAAA solution in the main
+       tree and should not use DNAME RRs in the reverse tree.
+
+   (3) In either case, the reverse tree should use the textual
+       representation described in [RFC1886] rather than the bit label
+       representation described in [RFC2874].
+
+   (4) If we do go to using A6 RRs in the main tree and to using DNAME
+       RRs in the reverse tree, we should write applicability statements
+       and implementation guidelines designed to discourage excessively
+       complex uses of these features; in general, any network that can
+       be described adequately using A6 0 RRs and without using DNAME
+       RRs should be described that way, and the enhanced features
+       should be used only when absolutely necessary, at least until we
+       have much more experience with them and have a better
+       understanding of their failure modes.
+
+Security Considerations
+
+   This note compares two mechanisms with similar security
+   characteristics, but there are a few security implications to the
+   choice between these two mechanisms:
+
+   (1) The two mechanisms have similar but not identical interactions
+       with DNSSEC.  Please see the section entitled "Interactions with
+       DNSSEC" (above) for a discussion of these issues.
+
+   (2) To the extent that operational complexity is the enemy of
+       security, the tradeoffs in operational complexity discussed
+       throughout this note have an impact on security.
+
+   (3) To the extent that protocol complexity is the enemy of security,
+       the additional protocol complexity of [RFC2874] as compared to
+       [RFC1886] has some impact on security.
+
+IANA Considerations
+
+   None, since all of these RR types have already been allocated.
+
+
+
+
+
+
+Austein                      Informational                      [Page 9]
+
+RFC 3364           Tradeoffs in DNS Support for IPv6         August 2002
+
+
+Acknowledgments
+
+   This note is based on a number of discussions both public and private
+   over a period of (at least) eight years, but particular thanks go to
+   Alain Durand, Bill Sommerfeld, Christian Huitema, Jun-ichiro itojun
+   Hagino, Mark Andrews, Matt Crawford, Olafur Gudmundsson, Randy Bush,
+   and Sue Thomson, none of whom are responsible for what the author did
+   with their ideas.
+
+References
+
+   [RFC1886]    Thomson, S. and C. Huitema, "DNS Extensions to support
+                IP version 6", RFC 1886, December 1995.
+
+   [RFC2874]    Crawford, M. and C. Huitema, "DNS Extensions to Support
+                IPv6 Address Aggregation and Renumbering", RFC 2874,
+                July 2000.
+
+   [Sommerfeld] Private message to the author from Bill Sommerfeld dated
+                21 March 2001, summarizing the result of experiments he
+                performed on a copy of the MIT.EDU zone.
+
+   [GSE]       "GSE" was an evolution of the so-called "8+8" proposal
+                discussed by the IPng working group in 1996 and 1997.
+                The GSE proposal itself was written up as an Internet-
+                Draft, which has long since expired.  Readers interested
+                in the details and history of GSE should review the IPng
+                working group's mailing list archives and minutes from
+                that period.
+
+Author's Address
+
+   Rob Austein
+
+   EMail: sra@hactrn.net
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Austein                      Informational                     [Page 10]
+
+RFC 3364           Tradeoffs in DNS Support for IPv6         August 2002
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Austein                      Informational                     [Page 11]
+
diff --git a/doc/rfc/rfc3425.txt b/doc/rfc/rfc3425.txt
new file mode 100644
index 0000000..707cafd
--- /dev/null
+++ b/doc/rfc/rfc3425.txt
@@ -0,0 +1,283 @@
+
+
+
+
+
+
+Network Working Group                                        D. Lawrence
+Request for Comments: 3425                                       Nominum
+Updates: 1035                                              November 2002
+Category: Standards Track
+
+
+                           Obsoleting IQUERY
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+
+Abstract
+
+   The IQUERY method of performing inverse DNS lookups, specified in RFC
+   1035, has not been generally implemented and has usually been
+   operationally disabled where it has been implemented.  Both reflect a
+   general view in the community that the concept was unwise and that
+   the widely-used alternate approach of using pointer (PTR) queries and
+   reverse-mapping records is preferable.  Consequently, this document
+   deprecates the IQUERY operation, declaring it entirely obsolete.
+   This document updates RFC 1035.
+
+1 - Introduction
+
+   As specified in RFC 1035 (section 6.4), the IQUERY operation for DNS
+   queries is used to look up the name(s) which are associated with the
+   given value.  The value being sought is provided in the query's
+   answer section and the response fills in the question section with
+   one or more 3-tuples of type, name and class.
+
+   As noted in [RFC1035], section 6.4.3, inverse query processing can
+   put quite an arduous burden on a server.  A server would need to
+   perform either an exhaustive search of its database or maintain a
+   separate database that is keyed by the values of the primary
+   database.  Both of these approaches could strain system resource use,
+   particularly for servers that are authoritative for millions of
+   names.
+
+
+
+
+
+Lawrence                    Standards Track                     [Page 1]
+
+RFC 3425                   Obsoleting IQUERY               November 2002
+
+
+   Response packets from these megaservers could be exceptionally large,
+   and easily run into megabyte sizes.  For example, using IQUERY to
+   find every domain that is delegated to one of the nameservers of a
+   large ISP could return tens of thousands of 3-tuples in the question
+   section.  This could easily be used to launch denial of service
+   attacks.
+
+   Operators of servers that do support IQUERY in some form (such as
+   very old BIND 4 servers) generally opt to disable it.  This is
+   largely due to bugs in insufficiently-exercised code, or concerns
+   about exposure of large blocks of names in their zones by probes such
+   as inverse MX queries.
+
+   IQUERY is also somewhat inherently crippled by being unable to tell a
+   requester where it needs to go to get the information that was
+   requested.  The answer is very specific to the single server that was
+   queried.  This is sometimes a handy diagnostic tool, but apparently
+   not enough so that server operators like to enable it, or request
+   implementation where it is lacking.
+
+   No known clients use IQUERY to provide any meaningful service.  The
+   only common reverse mapping support on the Internet, mapping address
+   records to names, is provided through the use of pointer (PTR)
+   records in the in-addr.arpa tree and has served the community well
+   for many years.
+
+   Based on all of these factors, this document recommends that the
+   IQUERY operation for DNS servers be officially obsoleted.
+
+2 - Requirements
+
+   The key word "SHOULD" in this document is to be interpreted as
+   described in BCP 14, RFC 2119, namely that there may exist valid
+   reasons to ignore a particular item, but the full implications must
+   be understood and carefully weighed before choosing a different
+   course.
+
+3 - Effect on RFC 1035
+
+   The effect of this document is to change the definition of opcode 1
+   from that originally defined in section 4.1.1 of RFC 1035, and to
+   entirely supersede section 6.4 (including subsections) of RFC 1035.
+
+   The definition of opcode 1 is hereby changed to:
+
+      "1               an inverse query (IQUERY) (obsolete)"
+
+
+
+
+
+Lawrence                    Standards Track                     [Page 2]
+
+RFC 3425                   Obsoleting IQUERY               November 2002
+
+
+   The text in section 6.4 of RFC 1035 is now considered obsolete.  The
+   following is an applicability statement regarding the IQUERY opcode:
+
+   Inverse queries using the IQUERY opcode were originally described as
+   the ability to look up the names that are associated with a
+   particular Resource Record (RR).  Their implementation was optional
+   and never achieved widespread use.  Therefore IQUERY is now obsolete,
+   and name servers SHOULD return a "Not Implemented" error when an
+   IQUERY request is received.
+
+4 - Security Considerations
+
+   Since this document obsoletes an operation that was once available,
+   it is conceivable that someone was using it as the basis of a
+   security policy.  However, since the most logical course for such a
+   policy to take in the face of a lack of positive response from a
+   server is to deny authentication/authorization, it is highly unlikely
+   that removing support for IQUERY will open any new security holes.
+
+   Note that if IQUERY is not obsoleted, securing the responses with DNS
+   Security (DNSSEC) is extremely difficult without out-on-the-fly
+   digital signing.
+
+5 - IANA Considerations
+
+   The IQUERY opcode of 1 should be permanently retired, not to be
+   assigned to any future opcode.
+
+6 - Acknowledgments
+
+   Olafur Gudmundsson instigated this action.  Matt Crawford, John
+   Klensin, Erik Nordmark and Keith Moore contributed some improved
+   wording in how to handle obsoleting functionality described by an
+   Internet Standard.
+
+7 - References
+
+   [RFC1035]  Mockapetris, P., "Domain Names - Implementation and
+              Specification", STD 13, RFC 1035, November 1987.
+
+   [RFC2026]  Bradner, S., "The Internet Standards Process -- Revision
+              3", BCP 9, RFC 2026, October 1996.
+
+   [RFC2119]  Bradner, S., "Key Words for Use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+
+
+
+
+
+Lawrence                    Standards Track                     [Page 3]
+
+RFC 3425                   Obsoleting IQUERY               November 2002
+
+
+8 - Author's Address
+
+   David C Lawrence
+   Nominum, Inc.
+   2385 Bay Rd
+   Redwood City CA 94063
+   USA
+
+   Phone: +1.650.779.6042
+   EMail: tale@nominum.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lawrence                    Standards Track                     [Page 4]
+
+RFC 3425                   Obsoleting IQUERY               November 2002
+
+
+9 - Full Copyright Statement
+
+   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lawrence                    Standards Track                     [Page 5]
+
diff --git a/doc/rfc/rfc3445.txt b/doc/rfc/rfc3445.txt
new file mode 100644
index 0000000..67f9b2d
--- /dev/null
+++ b/doc/rfc/rfc3445.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+Network Working Group                                          D. Massey
+Request for Comments: 3445                                       USC/ISI
+Updates: 2535                                                    S. Rose
+Category: Standards Track                                           NIST
+                                                           December 2002
+
+
+           Limiting the Scope of the KEY Resource Record (RR)
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+
+Abstract
+
+   This document limits the Domain Name System (DNS) KEY Resource Record
+   (RR) to only keys used by the Domain Name System Security Extensions
+   (DNSSEC).  The original KEY RR used sub-typing to store both DNSSEC
+   keys and arbitrary application keys.  Storing both DNSSEC and
+   application keys with the same record type is a mistake.  This
+   document removes application keys from the KEY record by redefining
+   the Protocol Octet field in the KEY RR Data.  As a result of removing
+   application keys, all but one of the flags in the KEY record become
+   unnecessary and are redefined.  Three existing application key sub-
+   types are changed to reserved, but the format of the KEY record is
+   not changed.  This document updates RFC 2535.
+
+1. Introduction
+
+   This document limits the scope of the KEY Resource Record (RR).  The
+   KEY RR was defined in [3] and used resource record sub-typing to hold
+   arbitrary public keys such as Email, IPSEC, DNSSEC, and TLS keys.
+   This document eliminates the existing Email, IPSEC, and TLS sub-types
+   and prohibits the introduction of new sub-types.  DNSSEC will be the
+   only allowable sub-type for the KEY RR (hence sub-typing is
+   essentially eliminated) and all but one of the KEY RR flags are also
+   eliminated.
+
+
+
+
+
+
+Massey & Rose               Standards Track                     [Page 1]
+
+RFC 3445         Limiting the KEY Resource Record (RR)     December 2002
+
+
+   Section 2 presents the motivation for restricting the KEY record and
+   Section 3 defines the revised KEY RR.  Sections 4 and 5 summarize the
+   changes from RFC 2535 and discuss backwards compatibility.  It is
+   important to note that this document restricts the use of the KEY RR
+   and simplifies the flags, but does not change the definition or use
+   of DNSSEC keys.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [1].
+
+2. Motivation for Restricting the KEY RR
+
+   The KEY RR RDATA [3] consists of Flags, a Protocol Octet, an
+   Algorithm type, and a Public Key.  The Protocol Octet identifies the
+   KEY RR sub-type.  DNSSEC public keys are stored in the KEY RR using a
+   Protocol Octet value of 3.  Email, IPSEC, and TLS keys were also
+   stored in the KEY RR and used Protocol Octet values of 1,2, and 4
+   (respectively).  Protocol Octet values 5-254 were available for
+   assignment by IANA and values were requested (but not assigned) for
+   applications such as SSH.
+
+   Any use of sub-typing has inherent limitations.  A resolver can not
+   specify the desired sub-type in a DNS query and most DNS operations
+   apply only to resource records sets.  For example, a resolver can not
+   directly request the DNSSEC subtype KEY RRs.  Instead, the resolver
+   has to request all KEY RRs associated with a DNS name and then search
+   the set for the desired DNSSEC sub-type.  DNSSEC signatures also
+   apply to the set of all KEY RRs associated with the DNS name,
+   regardless of sub-type.
+
+   In the case of the KEY RR, the inherent sub-type limitations are
+   exacerbated since the sub-type is used to distinguish between DNSSEC
+   keys and application keys.  DNSSEC keys and application keys differ
+   in virtually every respect and Section 2.1 discusses these
+   differences in more detail.  Combining these very different types of
+   keys into a single sub-typed resource record adds unnecessary
+   complexity and increases the potential for implementation and
+   deployment errors.  Limited experimental deployment has shown that
+   application keys stored in KEY RRs are problematic.
+
+   This document addresses these issues by removing all application keys
+   from the KEY RR.  Note that the scope of this document is strictly
+   limited to the KEY RR and this document does not endorse or restrict
+   the storage of application keys in other, yet undefined, resource
+   records.
+
+
+
+
+
+Massey & Rose               Standards Track                     [Page 2]
+
+RFC 3445         Limiting the KEY Resource Record (RR)     December 2002
+
+
+2.1 Differences Between DNSSEC and Application Keys
+
+   DNSSEC keys are an essential part of the DNSSEC protocol and are used
+   by both name servers and resolvers in order to perform DNS tasks.  A
+   DNS zone key, used to sign and authenticate RR sets, is the most
+   common example of a DNSSEC key.  SIG(0) [4] and TKEY [3]  also use
+   DNSSEC keys.
+
+   Application keys such as Email keys, IPSEC keys, and TLS keys are
+   simply another type of data.  These keys have no special meaning to a
+   name server or resolver.
+
+   The following table summarizes some of the differences between DNSSEC
+   keys and application keys:
+
+      1.  They serve different purposes.
+
+      2.  They are managed by different administrators.
+
+      3.  They are authenticated according to different rules.
+
+      4.  Nameservers use different rules when including them in
+          responses.
+
+      5.  Resolvers process them in different ways.
+
+      6.  Faults/key compromises have different consequences.
+
+   1.  The purpose of a DNSSEC key is to sign resource records
+   associated with a DNS zone (or generate DNS transaction signatures in
+   the case of SIG(0)/TKEY).  But the purpose of an application key is
+   specific to the application.  Application keys, such as PGP/email,
+   IPSEC, TLS, and SSH keys, are not a mandatory part of any zone and
+   the purpose and proper use of application keys is outside the scope
+   of DNS.
+
+   2.  DNSSEC keys are managed by DNS administrators, but application
+   keys are managed by application administrators.  The DNS zone
+   administrator determines the key lifetime, handles any suspected key
+   compromises, and manages any DNSSEC key changes.  Likewise, the
+   application administrator is responsible for the same functions for
+   the application keys related to the application.  For example, a user
+   typically manages her own PGP key and a server manages its own TLS
+   key.  Application key management tasks are outside the scope of DNS
+   administration.
+
+
+
+
+
+
+Massey & Rose               Standards Track                     [Page 3]
+
+RFC 3445         Limiting the KEY Resource Record (RR)     December 2002
+
+
+   3.  DNSSEC zone keys are used to authenticate application keys, but
+   by definition, application keys are not allowed to authenticate DNS
+   zone keys.  A DNS zone key is either configured as a trusted key or
+   authenticated by constructing a chain of trust in the DNS hierarchy.
+   To participate in the chain of trust, a DNS zone needs to exchange
+   zone key information with its parent zone [3].  Application keys are
+   not configured as trusted keys in the DNS and are never part of any
+   DNS chain of trust.  Application key data is not needed by the parent
+   and does not need to be exchanged with the parent zone for secure DNS
+   resolution to work.  A resolver considers an application key RRset as
+   authenticated DNS information if it has a valid signature from the
+   local DNS zone keys, but applications could impose additional
+   security requirements before the application key is accepted as
+   authentic for use with the application.
+
+   4.  It may be useful for nameservers to include DNS zone keys in the
+   additional section of a response, but application keys are typically
+   not useful unless they have been specifically requested.  For
+   example, it could be useful to include the example.com zone key along
+   with a response that contains the www.example.com A record and SIG
+   record.  A secure resolver will need the example.com zone key in
+   order to check the SIG and authenticate the www.example.com A record.
+   It is typically not useful to include the IPSEC, email, and TLS keys
+   along with the A record.  Note that by placing application keys in
+   the KEY record, a resolver would need the IPSEC, email, TLS, and
+   other key associated with example.com if the resolver intends to
+   authenticate the example.com zone key (since signatures only apply to
+   the entire KEY RR set).  Depending on the number of protocols
+   involved, the KEY RR set could grow unwieldy for resolvers, and DNS
+   administrators to manage.
+
+   5.  DNS zone keys require special handling by resolvers, but
+   application keys are treated the same as any other type of DNS data.
+   The DNSSEC keys are of no value to end applications, unless the
+   applications plan to do their own DNS authentication.  By definition,
+   secure resolvers are not allowed to use application keys as part of
+   the authentication process.  Application keys have no unique meaning
+   to resolvers and are only useful to the application requesting the
+   key.  Note that if sub-types are used to identify the application
+   key, then either the interface to the resolver needs to specify the
+   sub-type or the application needs to be able to accept all KEY RRs
+   and pick out the desired sub-type.
+
+   6.  A fault or compromise of a DNS zone key can lead to invalid or
+   forged DNS data, but a fault or compromise of an application key
+   should have no impact on other DNS data.  Incorrectly adding or
+   changing a DNS zone key can invalidate all of the DNS data in the
+   zone and in all of its subzones.  By using a compromised key, an
+
+
+
+Massey & Rose               Standards Track                     [Page 4]
+
+RFC 3445         Limiting the KEY Resource Record (RR)     December 2002
+
+
+   attacker can forge data from the effected zone and for any of its
+   sub-zones.  A fault or compromise of an application key has
+   implications for that application, but it should not have an impact
+   on the DNS.  Note that application key faults and key compromises can
+   have an impact on the entire DNS if the application key and DNS zone
+   keys are both stored in the KEY RR.
+
+   In summary, DNSSEC keys and application keys differ in most every
+   respect.  DNSSEC keys are an essential part of the DNS infrastructure
+   and require special handling by DNS administrators and DNS resolvers.
+   Application keys are simply another type of data and have no special
+   meaning to DNS administrators or resolvers.  These two different
+   types of data do not belong in the same resource record.
+
+3. Definition of the KEY RR
+
+   The KEY RR uses type 25 and is used as resource record for storing
+   DNSSEC keys.  The RDATA for a KEY RR consists of flags, a protocol
+   octet, the algorithm number octet, and the public key itself.  The
+   format is as follows:
+
+   ---------------------------------------------------------------------
+
+
+                        1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |              flags            |   protocol    |   algorithm   |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                                                               /
+   /                        public key                             /
+   /                                                               /
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                             KEY RR Format
+
+   ---------------------------------------------------------------------
+
+   In the flags field, all bits except bit 7 are reserved and MUST be
+   zero.  If Bit 7 (Zone bit) is set to 1, then the KEY is a DNS Zone
+   key.  If Bit 7 is set to 0, the KEY is not a zone key.  SIG(0)/TKEY
+   are examples of DNSSEC keys that are not zone keys.
+
+   The protocol field MUST be set to 3.
+
+   The algorithm and public key fields are not changed.
+
+
+
+
+
+Massey & Rose               Standards Track                     [Page 5]
+
+RFC 3445         Limiting the KEY Resource Record (RR)     December 2002
+
+
+4. Changes from RFC 2535 KEY RR
+
+   The KEY RDATA format is not changed.
+
+   All flags except for the zone key flag are eliminated:
+
+      The A/C bits (bits 0 and 1) are eliminated.  They MUST be set to 0
+      and MUST be ignored by the receiver.
+
+      The extended flags bit (bit 3) is eliminated.  It MUST be set to 0
+      and MUST be ignored by the receiver.
+
+      The host/user bit (bit 6) is eliminated.  It MUST be set to 0 and
+      MUST be ignored by the receiver.
+
+      The zone bit (bit 7) remains unchanged.
+
+      The signatory field (bits 12-15) are eliminated by [5].  They MUST
+      be set to 0 and MUST be ignored by the receiver.
+
+      Bits 2,4,5,8,9,10,11 remain unchanged.  They are reserved, MUST be
+      set to zero and MUST be ignored by the receiver.
+
+   Assignment of any future KEY RR Flag values requires a standards
+   action.
+
+   All Protocol Octet values except DNSSEC (3) are eliminated:
+
+      Value 1 (Email) is renamed to RESERVED.
+
+      Value 2 (IPSEC) is renamed to RESERVED.
+
+      Value 3 (DNSSEC) is unchanged.
+
+      Value 4 (TLS) is renamed to RESERVED.
+
+      Value 5-254 remains unchanged (reserved).
+
+      Value 255 (ANY) is renamed to RESERVED.
+
+   The authoritative data for a zone MUST NOT include any KEY records
+   with a protocol octet other than 3.  The registry maintained by IANA
+   for protocol values is closed for new assignments.
+
+   Name servers and resolvers SHOULD accept KEY RR sets that contain KEY
+   RRs with a value other than 3.  If out of date DNS zones contain
+   deprecated KEY RRs with a protocol octet value other than 3, then
+   simply dropping the deprecated KEY RRs from the KEY RR set would
+
+
+
+Massey & Rose               Standards Track                     [Page 6]
+
+RFC 3445         Limiting the KEY Resource Record (RR)     December 2002
+
+
+   invalidate any associated SIG record(s) and could create caching
+   consistency problems.  Note that KEY RRs with a protocol octet value
+   other than 3 MUST NOT be used to authenticate DNS data.
+
+   The algorithm and public key fields are not changed.
+
+5. Backward Compatibility
+
+   DNSSEC zone KEY RRs are not changed and remain backwards compatible.
+   A properly formatted RFC 2535 zone KEY would have all flag bits,
+   other than the Zone Bit (Bit 7), set to 0 and would have the Protocol
+   Octet set to 3.  This remains true under the restricted KEY.
+
+   DNSSEC non-zone KEY RRs (SIG(0)/TKEY keys) are backwards compatible,
+   but the distinction between host and user keys (flag bit 6) is lost.
+
+   No backwards compatibility is provided for application keys.  Any
+   Email, IPSEC, or TLS keys are now deprecated.  Storing application
+   keys in the KEY RR created problems such as keys at the apex and
+   large RR sets and some change in the definition and/or usage of the
+   KEY RR would have been required even if the approach described here
+   were not adopted.
+
+   Overall, existing nameservers and resolvers will continue to
+   correctly process KEY RRs with a sub-type of DNSSEC keys.
+
+6. Storing Application Keys in the DNS
+
+   The scope of this document is strictly limited to the KEY record.
+   This document prohibits storing application keys in the KEY record,
+   but it does not endorse or restrict the storing application keys in
+   other record types.  Other documents can describe how DNS handles
+   application keys.
+
+7. IANA Considerations
+
+   RFC 2535 created an IANA registry for DNS KEY RR Protocol Octet
+   values.  Values 1, 2, 3, 4, and 255 were assigned by RFC 2535 and
+   values 5-254 were made available for assignment by IANA.  This
+   document makes two sets of changes to this registry.
+
+   First, this document re-assigns DNS KEY RR Protocol Octet values 1,
+   2, 4, and 255 to "reserved".  DNS Key RR Protocol Octet Value 3
+   remains unchanged as "DNSSEC".
+
+
+
+
+
+
+
+Massey & Rose               Standards Track                     [Page 7]
+
+RFC 3445         Limiting the KEY Resource Record (RR)     December 2002
+
+
+   Second, new values are no longer available for assignment by IANA and
+   this document closes the IANA registry for DNS KEY RR Protocol Octet
+   Values.  Assignment of any future KEY RR Protocol Octet values
+   requires a standards action.
+
+8. Security Considerations
+
+   This document eliminates potential security problems that could arise
+   due to the coupling of DNS zone keys and application keys.  Prior to
+   the change described in this document, a correctly authenticated KEY
+   set could include both application keys and DNSSEC keys.  This
+   document restricts the KEY RR to DNS security usage only.  This is an
+   attempt to simplify the security model and make it less user-error
+   prone.  If one of the application keys is compromised, it could be
+   used as a false zone key to create false DNS signatures (SIG
+   records).  Resolvers that do not carefully check the KEY sub-type
+   could believe these false signatures and incorrectly authenticate DNS
+   data.  With this change, application keys cannot appear in an
+   authenticated KEY set and this vulnerability is eliminated.
+
+   The format and correct usage of DNSSEC keys is not changed by this
+   document and no new security considerations are introduced.
+
+9. Normative References
+
+   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", BCP 14, RFC 2119, March 1997.
+
+   [2]  Eastlake, D., "Domain Name System Security Extensions", RFC
+        2535, March 1999.
+
+   [3]  Eastlake, D., "Secret Key Establishment for DNS (TKEY RR)", RFC
+        2930, September 2000.
+
+   [4]  Eastlake, D., "DNS Request and Transaction Signatures
+        (SIG(0)s)", RFC 2931, September 2000.
+
+   [5]  Wellington, B., "Secure Domain Name System (DNS) Dynamic
+        Update", RFC 3007, November 2000.
+
+
+
+
+
+
+
+
+
+
+
+
+Massey & Rose               Standards Track                     [Page 8]
+
+RFC 3445         Limiting the KEY Resource Record (RR)     December 2002
+
+
+10. Authors' Addresses
+
+   Dan Massey
+   USC Information Sciences Institute
+   3811 N. Fairfax Drive
+   Arlington, VA  22203
+   USA
+
+   EMail: masseyd@isi.edu
+
+
+   Scott Rose
+   National Institute for Standards and Technology
+   100 Bureau Drive
+   Gaithersburg, MD  20899-3460
+   USA
+
+   EMail: scott.rose@nist.gov
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Massey & Rose               Standards Track                     [Page 9]
+
+RFC 3445         Limiting the KEY Resource Record (RR)     December 2002
+
+
+11.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Massey & Rose               Standards Track                    [Page 10]
+
diff --git a/doc/rfc/rfc3467.txt b/doc/rfc/rfc3467.txt
new file mode 100644
index 0000000..37ac7ec
--- /dev/null
+++ b/doc/rfc/rfc3467.txt
@@ -0,0 +1,1739 @@
+
+
+
+
+
+
+Network Working Group                                         J. Klensin
+Request for Comments: 3467                                 February 2003
+Category: Informational
+
+
+                  Role of the Domain Name System (DNS)
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+Abstract
+
+   This document reviews the original function and purpose of the domain
+   name system (DNS).  It contrasts that history with some of the
+   purposes for which the DNS has recently been applied and some of the
+   newer demands being placed upon it or suggested for it.  A framework
+   for an alternative to placing these additional stresses on the DNS is
+   then outlined.  This document and that framework are not a proposed
+   solution, only a strong suggestion that the time has come to begin
+   thinking more broadly about the problems we are encountering and
+   possible approaches to solving them.
+
+Table of Contents
+
+   1.  Introduction and History .....................................  2
+      1.1 Context for DNS Development ...............................  3
+      1.2 Review of the DNS and Its Role as Designed ................  4
+      1.3 The Web and User-visible Domain Names .....................  6
+      1.4 Internet Applications Protocols and Their Evolution .......  7
+   2.  Signs of DNS Overloading .....................................  8
+   3.  Searching, Directories, and the DNS .......................... 12
+      3.1 Overview  ................................................. 12
+      3.2 Some Details and Comments ................................. 14
+   4.  Internationalization ......................................... 15
+      4.1 ASCII Isn't Just Because of English ....................... 16
+      4.2 The "ASCII Encoding" Approaches ........................... 17
+      4.3 "Stringprep" and Its Complexities ......................... 17
+      4.4 The Unicode Stability Problem ............................. 19
+      4.5 Audiences, End Users, and the User Interface Problem ...... 20
+      4.6 Business Cards and Other Natural Uses of Natural Languages. 22
+      4.7 ASCII Encodings and the Roman Keyboard Assumption ......... 22
+
+
+
+Klensin                      Informational                      [Page 1]
+
+RFC 3467          Role of the Domain Name System (DNS)     February 2003
+
+
+      4.8 Intra-DNS Approaches for "Multilingual Names" ............. 23
+   5.  Search-based Systems: The Key Controversies .................. 23
+   6.  Security Considerations ...................................... 24
+   7.  References ................................................... 25
+      7.1 Normative References ...................................... 25
+      7.2 Explanatory and Informative References .................... 25
+   8.  Acknowledgements ............................................. 30
+   9.  Author's Address ............................................. 30
+   10. Full Copyright Statement ..................................... 31
+
+1. Introduction and History
+
+   The DNS was designed as a replacement for the older "host table"
+   system.  Both were intended to provide names for network resources at
+   a more abstract level than network (IP) addresses (see, e.g.,
+   [RFC625], [RFC811], [RFC819], [RFC830], [RFC882]).  In recent years,
+   the DNS has become a database of convenience for the Internet, with
+   many proposals to add new features.  Only some of these proposals
+   have been successful.  Often the main (or only) motivation for using
+   the DNS is because it exists and is widely deployed, not because its
+   existing structure, facilities, and content are appropriate for the
+   particular application of data involved.  This document reviews the
+   history of the DNS, including examination of some of those newer
+   applications.  It then argues that the overloading process is often
+   inappropriate.  Instead, it suggests that the DNS should be
+   supplemented by systems better matched to the intended applications
+   and outlines a framework and rationale for one such system.
+
+   Several of the comments that follow are somewhat revisionist.  Good
+   design and engineering often requires a level of intuition by the
+   designers about things that will be necessary in the future; the
+   reasons for some of these design decisions are not made explicit at
+   the time because no one is able to articulate them.  The discussion
+   below reconstructs some of the decisions about the Internet's primary
+   namespace (the "Class=IN" DNS) in the light of subsequent development
+   and experience.  In addition, the historical reasons for particular
+   decisions about the Internet were often severely underdocumented
+   contemporaneously and, not surprisingly, different participants have
+   different recollections about what happened and what was considered
+   important.  Consequently, the quasi-historical story below is just
+   one story.  There may be (indeed, almost certainly are) other stories
+   about how the DNS evolved to its present state, but those variants do
+   not invalidate the inferences and conclusions.
+
+   This document presumes a general understanding of the terminology of
+   RFC 1034 [RFC1034] or of any good DNS tutorial (see, e.g., [Albitz]).
+
+
+
+
+
+Klensin                      Informational                      [Page 2]
+
+RFC 3467          Role of the Domain Name System (DNS)     February 2003
+
+
+1.1  Context for DNS Development
+
+   During the entire post-startup-period life of the ARPANET and nearly
+   the first decade or so of operation of the Internet, the list of host
+   names and their mapping to and from addresses was maintained in a
+   frequently-updated "host table" [RFC625], [RFC811], [RFC952].  The
+   names themselves were restricted to a subset of ASCII [ASCII] chosen
+   to avoid ambiguities in printed form, to permit interoperation with
+   systems using other character codings (notably EBCDIC), and to avoid
+   the "national use" code positions of ISO 646 [IS646].  These
+   restrictions later became collectively known as the "LDH" rules for
+   "letter-digit-hyphen", the permitted characters.  The table was just
+   a list with a common format that was eventually agreed upon; sites
+   were expected to frequently obtain copies of, and install, new
+   versions.  The host tables themselves were introduced to:
+
+   o  Eliminate the requirement for people to remember host numbers
+      (addresses).  Despite apparent experience to the contrary in the
+      conventional telephone system, numeric numbering systems,
+      including the numeric host number strategy, did not (and do not)
+      work well for more than a (large) handful of hosts.
+
+   o  Provide stability when addresses changed.  Since addresses -- to
+      some degree in the ARPANET and more importantly in the
+      contemporary Internet -- are a function of network topology and
+      routing, they often had to be changed when connectivity or
+      topology changed.  The names could be kept stable even as
+      addresses changed.
+
+   o  Provide the capability to have multiple addresses associated with
+      a given host to reflect different types of connectivity and
+      topology.  Use of names, rather than explicit addresses, avoided
+      the requirement that would otherwise exist for users and other
+      hosts to track these multiple host numbers and addresses and the
+      topological considerations for selecting one over others.
+
+   After several years of using the host table approach, the community
+   concluded that model did not scale adequately and that it would not
+   adequately support new service variations.  A number of discussions
+   and meetings were held which drew several ideas and incomplete
+   proposals together.  The DNS was the result of that effort.  It
+   continued to evolve during the design and initial implementation
+   period, with a number of documents recording the changes (see
+   [RFC819], [RFC830], and [RFC1034]).
+
+
+
+
+
+
+
+Klensin                      Informational                      [Page 3]
+
+RFC 3467          Role of the Domain Name System (DNS)     February 2003
+
+
+   The goals for the DNS included:
+
+   o  Preservation of the capabilities of the host table arrangements
+      (especially unique, unambiguous, host names),
+
+   o  Provision for addition of additional services (e.g., the special
+      record types for electronic mail routing which quickly followed
+      introduction of the DNS), and
+
+   o  Creation of a robust, hierarchical, distributed, name lookup
+      system to accomplish the other goals.
+
+   The DNS design also permitted distribution of name administration,
+   rather than requiring that each host be entered into a single,
+   central, table by a central administration.
+
+1.2 Review of the DNS and Its Role as Designed
+
+   The DNS was designed to identify network resources.  Although there
+   was speculation about including, e.g., personal names and email
+   addresses, it was not designed primarily to identify people, brands,
+   etc.  At the same time, the system was designed with the flexibility
+   to accommodate new data types and structures, both through the
+   addition of new record types to the initial "INternet" class, and,
+   potentially, through the introduction of new classes.  Since the
+   appropriate identifiers and content of those future extensions could
+   not be anticipated, the design provided that these fields could
+   contain any (binary) information, not just the restricted text forms
+   of the host table.
+
+   However, the DNS, as it is actually used, is intimately tied to the
+   applications and application protocols that utilize it, often at a
+   fairly low level.
+
+   In particular, despite the ability of the protocols and data
+   structures themselves to accommodate any binary representation, DNS
+   names as used were historically not even unrestricted ASCII, but a
+   very restricted subset of it, a subset that derives from the original
+   host table naming rules.  Selection of that subset was driven in part
+   by human factors considerations, including a desire to eliminate
+   possible ambiguities in an international context.  Hence character
+   codes that had international variations in interpretation were
+   excluded, the underscore character and case distinctions were
+   eliminated as being confusing (in the underscore's case, with the
+   hyphen character) when written or read by people, and so on.  These
+   considerations appear to be very similar to those that resulted in
+   similarly restricted character sets being used as protocol elements
+   in many ITU and ISO protocols (cf. [X29]).
+
+
+
+Klensin                      Informational                      [Page 4]
+
+RFC 3467          Role of the Domain Name System (DNS)     February 2003
+
+
+   Another assumption was that there would be a high ratio of physical
+   hosts to second level domains and, more generally, that the system
+   would be deeply hierarchical, with most systems (and names) at the
+   third level or below and a very large percentage of the total names
+   representing physical hosts.  There are domains that follow this
+   model: many university and corporate domains use fairly deep
+   hierarchies, as do a few country-oriented top level domains
+   ("ccTLDs").  Historically, the "US." domain has been an excellent
+   example of the deeply hierarchical approach.  However, by 1998,
+   comparison of several efforts to survey the DNS showed a count of SOA
+   records that approached (and may have passed) the number of distinct
+   hosts.  Looked at differently, we appear to be moving toward a
+   situation in which the number of delegated domains on the Internet is
+   approaching or exceeding the number of hosts, or at least the number
+   of hosts able to provide services to others on the network.  This
+   presumably results from synonyms or aliases that map a great many
+   names onto a smaller number of hosts.  While experience up to this
+   time has shown that the DNS is robust enough -- given contemporary
+   machines as servers and current bandwidth norms -- to be able to
+   continue to operate reasonably well when those historical assumptions
+   are not met (e.g., with a flat, structure under ".COM" containing
+   well over ten million delegated subdomains [COMSIZE]), it is still
+   useful to remember that the system could have been designed to work
+   optimally with a flat structure (and very large zones) rather than a
+   deeply hierarchical one, and was not.
+
+   Similarly, despite some early speculation about entering people's
+   names and email addresses into the DNS directly (e.g., see
+   [RFC1034]), electronic mail addresses in the Internet have preserved
+   the original, pre-DNS, "user (or mailbox) at location" conceptual
+   format rather than a flatter or strictly dot-separated one.
+   Location, in that instance, is a reference to a host. The sole
+   exception, at least in the "IN" class, has been one field of the SOA
+   record.
+
+   Both the DNS architecture itself and the two-level (host name and
+   mailbox name) provisions for email and similar functions (e.g., see
+   the finger protocol [FINGER]), also anticipated a relatively high
+   ratio of users to actual hosts.  Despite the observation in RFC 1034
+   that the DNS was expected to grow to be proportional to the number of
+   users (section 2.3), it has never been clear that the DNS was
+   seriously designed for, or could, scale to the order of magnitude of
+   number of users (or, more recently, products or document objects),
+   rather than that of physical hosts.
+
+   Just as was the case for the host table before it, the DNS provided
+   critical uniqueness for names, and universal accessibility to them,
+   as part of overall "single internet" and "end to end" models (cf.
+
+
+
+Klensin                      Informational                      [Page 5]
+
+RFC 3467          Role of the Domain Name System (DNS)     February 2003
+
+
+   [RFC2826]).  However, there are many signs that, as new uses evolved
+   and original assumptions were abused (if not violated outright), the
+   system was being stretched to, or beyond, its practical limits.
+
+   The original design effort that led to the DNS included examination
+   of the directory technologies available at the time.  The design
+   group concluded that the DNS design, with its simplifying assumptions
+   and restricted capabilities, would be feasible to deploy and make
+   adequately robust, which the more comprehensive directory approaches
+   were not.  At the same time, some of the participants feared that the
+   limitations might cause future problems; this document essentially
+   takes the position that they were probably correct.  On the other
+   hand, directory technology and implementations have evolved
+   significantly in the ensuing years: it may be time to revisit the
+   assumptions, either in the context of the two- (or more) level
+   mechanism contemplated by the rest of this document or, even more
+   radically, as a path toward a DNS replacement.
+
+1.3 The Web and User-visible Domain Names
+
+   From the standpoint of the integrity of the domain name system -- and
+   scaling of the Internet, including optimal accessibility to content
+   -- the web design decision to use "A record" domain names directly in
+   URLs, rather than some system of indirection, has proven to be a
+   serious mistake in several respects.  Convenience of typing, and the
+   desire to make domain names out of easily-remembered product names,
+   has led to a flattening of the DNS, with many people now perceiving
+   that second-level names under COM (or in some countries, second- or
+   third-level names under the relevant ccTLD) are all that is
+   meaningful.  This perception has been reinforced by some domain name
+   registrars [REGISTRAR] who have been anxious to "sell" additional
+   names.  And, of course, the perception that one needed a second-level
+   (or even top-level) domain per product, rather than having names
+   associated with a (usually organizational) collection of network
+   resources, has led to a rapid acceleration in the number of names
+   being registered.  That acceleration has, in turn, clearly benefited
+   registrars charging on a per-name basis, "cybersquatters", and others
+   in the business of "selling" names, but it has not obviously
+   benefited the Internet as a whole.
+
+   This emphasis on second-level domain names has also created a problem
+   for the trademark community.  Since the Internet is international,
+   and names are being populated in a flat and unqualified space,
+   similarly-named entities are in conflict even if there would
+   ordinarily be no chance of confusing them in the marketplace.  The
+   problem appears to be unsolvable except by a choice between draconian
+   measures.  These might include significant changes to the legislation
+   and conventions that govern disputes over "names" and "marks".  Or
+
+
+
+Klensin                      Informational                      [Page 6]
+
+RFC 3467          Role of the Domain Name System (DNS)     February 2003
+
+
+   they might result in a situation in which the "rights" to a name are
+   typically not settled using the subtle and traditional product (or
+   industry) type and geopolitical scope rules of the trademark system.
+   Instead they have depended largely on political or economic power,
+   e.g., the organization with the greatest resources to invest in
+   defending (or attacking) names will ultimately win out.  The latter
+   raises not only important issues of equity, but also the risk of
+   backlash as the numerous small players are forced to relinquish names
+   they find attractive and to adopt less-desirable naming conventions.
+
+   Independent of these sociopolitical problems, content distribution
+   issues have made it clear that it should be possible for an
+   organization to have copies of data it wishes to make available
+   distributed around the network, with a user who asks for the
+   information by name getting the topologically-closest copy.  This is
+   not possible with simple, as-designed, use of the DNS: DNS names
+   identify target resources or, in the case of email "MX" records, a
+   preferentially-ordered list of resources "closest" to a target (not
+   to the source/user).  Several technologies (and, in some cases,
+   corresponding business models) have arisen to work around these
+   problems, including intercepting and altering DNS requests so as to
+   point to other locations.
+
+   Additional implications are still being discovered and evaluated.
+
+   Approaches that involve interception of DNS queries and rewriting of
+   DNS names (or otherwise altering the resolution process based on the
+   topological location of the user) seem, however, to risk disrupting
+   end-to-end applications in the general case and raise many of the
+   issues discussed by the IAB in [IAB-OPES].  These problems occur even
+   if the rewriting machinery is accompanied by additional workarounds
+   for particular applications.  For example, security associations and
+   applications that need to identify "the same host" often run into
+   problems if DNS names or other references are changed in the network
+   without participation of the applications that are trying to invoke
+   the associated services.
+
+1.4 Internet Applications Protocols and Their Evolution
+
+   At the applications level, few of the protocols in active,
+   widespread, use on the Internet reflect either contemporary knowledge
+   in computer science or human factors or experience accumulated
+   through deployment and use.  Instead, protocols tend to be deployed
+   at a just-past-prototype level, typically including the types of
+   expedient compromises typical with prototypes.  If they prove useful,
+   the nature of the network permits very rapid dissemination (i.e.,
+   they fill a vacuum, even if a vacuum that no one previously knew
+   existed).  But, once the vacuum is filled, the installed base
+
+
+
+Klensin                      Informational                      [Page 7]
+
+RFC 3467          Role of the Domain Name System (DNS)     February 2003
+
+
+   provides its own inertia: unless the design is so seriously faulty as
+   to prevent effective use (or there is a widely-perceived sense of
+   impending disaster unless the protocol is replaced), future
+   developments must maintain backward compatibility and workarounds for
+   problematic characteristics rather than benefiting from redesign in
+   the light of experience.  Applications that are "almost good enough"
+   prevent development and deployment of high-quality replacements.
+
+   The DNS is both an illustration of, and an exception to, parts of
+   this pessimistic interpretation. It was a second-generation
+   development, with the host table system being seen as at the end of
+   its useful life.  There was a serious attempt made to reflect the
+   computing state of the art at the time.  However, deployment was much
+   slower than expected (and very painful for many sites) and some fixed
+   (although relaxed several times) deadlines from a central network
+   administration were necessary for deployment to occur at all.
+   Replacing it now, in order to add functionality, while it continues
+   to perform its core functions at least reasonably well, would
+   presumably be extremely difficult.
+
+   There are many, perhaps obvious, examples of this.  Despite many
+   known deficiencies and weaknesses of definition, the "finger" and
+   "whois" [WHOIS] protocols have not been replaced (despite many
+   efforts to update or replace the latter [WHOIS-UPDATE]).  The Telnet
+   protocol and its many options drove out the SUPDUP [RFC734] one,
+   which was arguably much better designed for a diverse collection of
+   network hosts.  A number of efforts to replace the email or file
+   transfer protocols with models which their advocates considered much
+   better have failed.  And, more recently and below the applications
+   level, there is some reason to believe that this resistance to change
+   has been one of the factors impeding IPv6 deployment.
+
+2. Signs of DNS Overloading
+
+   Parts of the historical discussion above identify areas in which the
+   DNS has become overloaded (semantically if not in the mechanical
+   ability to resolve names).  Despite this overloading, it appears that
+   DNS performance and reliability are still within an acceptable range:
+   there is little evidence of serious performance degradation.  Recent
+   proposals and mechanisms to better respond to overloading and scaling
+   issues have all focused on patching or working around limitations
+   that develop when the DNS is utilized for out-of-design functions,
+   rather than on dramatic rethinking of either DNS design or those
+   uses.  The number of these issues that have arisen at much the same
+   time may argue for just that type of rethinking, and not just for
+   adding complexity and attempting to incrementally alter the design
+   (see, for example, the discussion of simplicity in section 2 of
+   [RFC3439]).
+
+
+
+Klensin                      Informational                      [Page 8]
+
+RFC 3467          Role of the Domain Name System (DNS)     February 2003
+
+
+   For example:
+
+   o  While technical approaches such as larger and higher-powered
+      servers and more bandwidth, and legal/political mechanisms such as
+      dispute resolution policies, have arguably kept the problems from
+      becoming critical, the DNS has not proven adequately responsive to
+      business and individual needs to describe or identify things (such
+      as product names and names of individuals) other than strict
+      network resources.
+
+   o  While stacks have been modified to better handle multiple
+      addresses on a physical interface and some protocols have been
+      extended to include DNS names for determining context, the DNS
+      does not deal especially well with many names associated with a
+      given host (e.g., web hosting facilities with multiple domains on
+      a server).
+
+   o  Efforts to add names deriving from languages or character sets
+      based on other than simple ASCII and English-like names (see
+      below), or even to utilize complex company or product names
+      without the use of hierarchy, have created apparent requirements
+      for names (labels) that are over 63 octets long.  This requirement
+      will undoubtedly increase over time; while there are workarounds
+      to accommodate longer names, they impose their own restrictions
+      and cause their own problems.
+
+   o  Increasing commercialization of the Internet, and visibility of
+      domain names that are assumed to match names of companies or
+      products, has turned the DNS and DNS names into a trademark
+      battleground.  The traditional trademark system in (at least) most
+      countries makes careful distinctions about fields of
+      applicability.  When the space is flattened, without
+      differentiation by either geography or industry sector, not only
+      are there likely conflicts between "Joe's Pizza" (of Boston) and
+      "Joe's Pizza" (of San Francisco) but between both and "Joe's Auto
+      Repair" (of Los Angeles).  All three would like to control
+      "Joes.com" (and would prefer, if it were permitted by DNS naming
+      rules, to also spell it as "Joe's.com" and have both resolve the
+      same way) and may claim trademark rights to do so, even though
+      conflict or confusion would not occur with traditional trademark
+      principles.
+
+   o  Many organizations wish to have different web sites under the same
+      URL and domain name.  Sometimes this is to create local variations
+      -- the Widget Company might want to present different material to
+      a UK user relative to a US one -- and sometimes it is to provide
+      higher performance by supplying information from the server
+      topologically closest to the user.  If the name resolution
+
+
+
+Klensin                      Informational                      [Page 9]
+
+RFC 3467          Role of the Domain Name System (DNS)     February 2003
+
+
+      mechanism is expected to provide this functionality, there are
+      three possible models (which might be combined):
+
+      -  supply information about multiple sites (or locations or
+         references).  Those sites would, in turn, provide information
+         associated with the name and sufficient site-specific
+         attributes to permit the application to make a sensible choice
+         of destination, or
+
+      -  accept client-site attributes and utilize them in the search
+         process, or
+
+      -  return different answers based on the location or identity of
+         the requestor.
+
+   While there are some tricks that can provide partial simulations of
+   these types of function, DNS responses cannot be reliably conditioned
+   in this way.
+
+   These, and similar, issues of performance or content choices can, of
+   course, be thought of as not involving the DNS at all.  For example,
+   the commonly-cited alternate approach of coupling these issues to
+   HTTP content negotiation (cf. [RFC2295]), requires that an HTTP
+   connection first be opened to some "common" or "primary" host so that
+   preferences can be negotiated and then the client redirected or sent
+   alternate data.  At least from the standpoint of improving
+   performance by accessing a "closer" location, both initially and
+   thereafter, this approach sacrifices the desired result before the
+   client initiates any action.  It could even be argued that some of
+   the characteristics of common content negotiation approaches are
+   workarounds for the non-optimal use of the DNS in web URLs.
+
+   o  Many existing and proposed systems for "finding things on the
+      Internet" require a true search capability in which near matches
+      can be reported to the user (or to some user agent with an
+      appropriate rule-set) and to which queries may be ambiguous or
+      fuzzy.  The DNS, by contrast, can accommodate only one set of
+      (quite rigid) matching rules.  Proposals to permit different rules
+      in different localities (e.g., matching rules that are TLD- or
+      zone-specific) help to identify the problem.  But they cannot be
+      applied directly to the DNS without either abandoning the desired
+      level of flexibility or isolating different parts of the Internet
+      from each other (or both).  Fuzzy or ambiguous searches are
+      desirable for resolution of names that might have spelling
+      variations and for names that can be resolved into different sets
+      of glyphs depending on context.  Especially when
+      internationalization is considered, variant name problems go
+      beyond simple differences in representation of a character or
+
+
+
+Klensin                      Informational                     [Page 10]
+
+RFC 3467          Role of the Domain Name System (DNS)     February 2003
+
+
+      ordering of a string.  Instead, avoiding user astonishment and
+      confusion requires consideration of relationships such as
+      languages that can be written with different alphabets, Kanji-
+      Hiragana relationships, Simplified and Traditional Chinese, etc.
+      See [Seng] for a discussion and suggestions for addressing a
+      subset of these issues in the context of characters based on
+      Chinese ones.  But that document essentially illustrates the
+      difficulty of providing the type of flexible matching that would
+      be anticipated by users; instead, it tries to protect against the
+      worst types of confusion (and opportunities for fraud).
+
+   o  The historical DNS, and applications that make assumptions about
+      how it works, impose significant risk (or forces technical kludges
+      and consequent odd restrictions), when one considers adding
+      mechanisms for use with various multi-character-set and
+      multilingual "internationalization" systems.  See the IAB's
+      discussion of some of these issues [RFC2825] for more information.
+
+   o  In order to provide proper functionality to the Internet, the DNS
+      must have a single unique root (the IAB provides more discussion
+      of this issue [RFC2826]).  There are many desires for local
+      treatment of names or character sets that cannot be accommodated
+      without either multiple roots (e.g., a separate root for
+      multilingual names, proposed at various times by MINC [MINC] and
+      others), or mechanisms that would have similar effects in terms of
+      Internet fragmentation and isolation.
+
+   o  For some purposes, it is desirable to be able to search not only
+      an index entry (labels or fully-qualified names in the DNS case),
+      but their values or targets (DNS data).  One might, for example,
+      want to locate all of the host (and virtual host) names which
+      cause mail to be directed to a given server via MX records.  The
+      DNS does not support this capability (see the discussion in
+      [IQUERY]) and it can be simulated only by extracting all of the
+      relevant records (perhaps by zone transfer if the source permits
+      doing so, but that permission is becoming less frequently
+      available) and then searching a file built from those records.
+
+   o  Finally, as additional types of personal or identifying
+      information are added to the DNS, issues arise with protection of
+      that information.  There are increasing calls to make different
+      information available based on the credentials and authorization
+      of the source of the inquiry.  As with information keyed to site
+      locations or proximity (as discussed above), the DNS protocols
+      make providing these differentiated services quite difficult if
+      not impossible.
+
+
+
+
+
+Klensin                      Informational                     [Page 11]
+
+RFC 3467          Role of the Domain Name System (DNS)     February 2003
+
+
+   In each of these cases, it is, or might be, possible to devise ways
+   to trick the DNS system into supporting mechanisms that were not
+   designed into it.  Several ingenious solutions have been proposed in
+   many of these areas already, and some have been deployed into the
+   marketplace with some success.  But the price of each of these
+   changes is added complexity and, with it, added risk of unexpected
+   and destabilizing problems.
+
+   Several of the above problems are addressed well by a good directory
+   system (supported by the LDAP protocol or some protocol more
+   precisely suited to these specific applications) or searching
+   environment (such as common web search engines) although not by the
+   DNS.  Given the difficulty of deploying new applications discussed
+   above, an important question is whether the tricks and kludges are
+   bad enough, or will become bad enough as usage grows, that new
+   solutions are needed and can be deployed.
+
+3. Searching, Directories, and the DNS
+
+3.1 Overview
+
+   The constraints of the DNS and the discussion above suggest the
+   introduction of an intermediate protocol mechanism, referred to below
+   as a "search layer" or "searchable system".  The terms "directory"
+   and "directory system" are used interchangeably with "searchable
+   system" in this document, although the latter is far more precise.
+   Search layer proposals would use a two (or more) stage lookup, not
+   unlike several of the proposals for internationalized names in the
+   DNS (see section 4), but all operations but the final one would
+   involve searching other systems, rather than looking up identifiers
+   in the DNS itself.  As explained below, this would permit relaxation
+   of several constraints, leading to a more capable and comprehensive
+   overall system.
+
+   Ultimately, many of the issues with domain names arise as the result
+   of efforts to use the DNS as a directory.  While, at the time this
+   document was written, sufficient pressure or demand had not occurred
+   to justify a change, it was already quite clear that, as a directory
+   system, the DNS is a good deal less than ideal.  This document
+   suggests that there actually is a requirement for a directory system,
+   and that the right solution to a searchable system requirement is a
+   searchable system, not a series of DNS patches, kludges, or
+   workarounds.
+
+
+
+
+
+
+
+
+Klensin                      Informational                     [Page 12]
+
+RFC 3467          Role of the Domain Name System (DNS)     February 2003
+
+
+   The following points illustrate particular aspects of this
+   conclusion.
+
+   o  A directory system would not require imposition of particular
+      length limits on names.
+
+   o  A directory system could permit explicit association of
+      attributes, e.g., language and country, with a name, without
+      having to utilize trick encodings to incorporate that information
+      in DNS labels (or creating artificial hierarchy for doing so).
+
+   o  There is considerable experience (albeit not much of it very
+      successful) in doing fuzzy and "sonex" (similar-sounding) matching
+      in directory systems.  Moreover, it is plausible to think about
+      different matching rules for different areas and sets of names so
+      that these can be adapted to local cultural requirements.
+      Specifically, it might be possible to have a single form of a name
+      in a directory, but to have great flexibility about what queries
+      matched that name (and even have different variations in different
+      areas).  Of course, the more flexibility that a system provides,
+      the greater the possibility of real or imagined trademark
+      conflicts.  But the opportunity would exist to design a directory
+      structure that dealt with those issues in an intelligent way,
+      while DNS constraints almost certainly make a general and
+      equitable DNS-only solution impossible.
+
+   o  If a directory system is used to translate to DNS names, and then
+      DNS names are looked up in the normal fashion, it may be possible
+      to relax several of the constraints that have been traditional
+      (and perhaps necessary) with the DNS.  For example, reverse-
+      mapping of addresses to directory names may not be a requirement
+      even if mapping of addresses to DNS names continues to be, since
+      the DNS name(s) would (continue to) uniquely identify the host.
+
+   o  Solutions to multilingual transcription problems that are common
+      in "normal life" (e.g., two-sided business cards to be sure that
+      recipients trying to contact a person can access romanized
+      spellings and numbers if the original language is not
+      comprehensible to them) can be easily handled in a directory
+      system by inserting both sets of entries.
+
+   o  A directory system could be designed that would return, not a
+      single name, but a set of names paired with network-locational
+      information or other context-establishing attributes.  This type
+      of information might be of considerable use in resolving the
+      "nearest (or best) server for a particular named resource"
+
+
+
+
+
+Klensin                      Informational                     [Page 13]
+
+RFC 3467          Role of the Domain Name System (DNS)     February 2003
+
+
+      problems that are a significant concern for organizations hosting
+      web and other sites that are accessed from a wide range of
+      locations and subnets.
+
+   o  Names bound to countries and languages might help to manage
+      trademark realities, while, as discussed in section 1.3 above, use
+      of the DNS in trademark-significant contexts tends to require
+      worldwide "flattening" of the trademark system.
+
+   Many of these issues are a consequence of another property of the
+   DNS:  names must be unique across the Internet.  The need to have a
+   system of unique identifiers is fairly obvious (see [RFC2826]).
+   However, if that requirement were to be eliminated in a search or
+   directory system that was visible to users instead of the DNS, many
+   difficult problems -- of both an engineering and a policy nature --
+   would be likely to vanish.
+
+3.2 Some Details and Comments
+
+   Almost any internationalization proposal for names that are in, or
+   map into, the DNS will require changing DNS resolver API calls
+   ("gethostbyname" or equivalent), or adding some pre-resolution
+   preparation mechanism, in almost all Internet applications -- whether
+   to cause the API to take a different character set (no matter how it
+   is then mapped into the bits used in the DNS or another system), to
+   accept or return more arguments with qualifying or identifying
+   information, or otherwise.  Once applications must be opened to make
+   such changes, it is a relatively small matter to switch from calling
+   into the DNS to calling a directory service and then the DNS (in many
+   situations, both actions could be accomplished in a single API call).
+
+   A directory approach can be consistent both with "flat" models and
+   multi-attribute ones.  The DNS requires strict hierarchies, limiting
+   its ability to differentiate among names by their properties.  By
+   contrast, modern directories can utilize independently-searched
+   attributes and other structured schema to provide flexibilities not
+   present in a strictly hierarchical system.
+
+   There is a strong historical argument for a single directory
+   structure (implying a need for mechanisms for registration,
+   delegation, etc.).  But a single structure is not a strict
+   requirement, especially if in-depth case analysis and design work
+   leads to the conclusion that reverse-mapping to directory names is
+   not a requirement (see section 5).  If a single structure is not
+   needed, then, unlike the DNS, there would be no requirement for a
+   global organization to authorize or delegate operation of portions of
+   the structure.
+
+
+
+
+Klensin                      Informational                     [Page 14]
+
+RFC 3467          Role of the Domain Name System (DNS)     February 2003
+
+
+   The "no single structure" concept could be taken further by moving
+   away from simple "names" in favor of, e.g., multiattribute,
+   multihierarchical, faceted systems in which most of the facets use
+   restricted vocabularies.  (These terms are fairly standard in the
+   information retrieval and classification system literature, see,
+   e.g., [IS5127].)  Such systems could be designed to avoid the need
+   for procedures to ensure uniqueness across, or even within, providers
+   and databases of the faceted entities for which the search is to be
+   performed.  (See [DNS-Search] for further discussion.)
+
+   While the discussion above includes very general comments about
+   attributes, it appears that only a very small number of attributes
+   would be needed.  The list would almost certainly include country and
+   language for internationalization purposes.  It might require
+   "charset" if we cannot agree on a character set and encoding,
+   although there are strong arguments for simply using ISO 10646 (also
+   known as Unicode or "UCS" (for Universal Character Set) [UNICODE],
+   [IS10646] coding in interchange.  Trademark issues might motivate
+   "commercial" and "non-commercial" (or other) attributes if they would
+   be helpful in bypassing trademark problems.  And applications to
+   resource location, such as those contemplated for Uniform Resource
+   Identifiers (URIs) [RFC2396, RFC3305] or the Service Location
+   Protocol [RFC2608], might argue for a few other attributes (as
+   outlined above).
+
+4.  Internationalization
+
+   Much of the thinking underlying this document was driven by
+   considerations of internationalizing the DNS or, more specifically,
+   providing access to the functions of the DNS from languages and
+   naming systems that cannot be accurately expressed in the traditional
+   DNS subset of ASCII.  Much of the relevant work was done in the
+   IETF's "Internationalized Domain Names" Working Group (IDN-WG),
+   although this document also draws on extensive parallel discussions
+   in other forums.  This section contains an evaluation of what was
+   learned as an "internationalized DNS" or "multilingual DNS" was
+   explored and suggests future steps based on that evaluation.
+
+   When the IDN-WG was initiated, it was obvious to several of the
+   participants that its first important task was an undocumented one:
+   to increase the understanding of the complexities of the problem
+   sufficiently that naive solutions could be rejected and people could
+   go to work on the harder problems.  The IDN-WG clearly accomplished
+   that task. The beliefs that the problems were simple, and in the
+   corresponding simplistic approaches and their promises of quick and
+   painless deployment, effectively disappeared as the WG's efforts
+   matured.
+
+
+
+
+Klensin                      Informational                     [Page 15]
+
+RFC 3467          Role of the Domain Name System (DNS)     February 2003
+
+
+   Some of the lessons learned from increased understanding and the
+   dissipation of naive beliefs should be taken as cautions by the wider
+   community: the problems are not simple. Specifically, extracting
+   small elements for solution rather than looking at whole systems, may
+   result in obscuring the problems but not solving any problem that is
+   worth the trouble.
+
+4.1 ASCII Isn't Just Because of English
+
+   The hostname rules chosen in the mid-70s weren't just "ASCII because
+   English uses ASCII", although that was a starting point.  We have
+   discovered that almost every other script (and even ASCII if we
+   permit the rest of the characters specified in the ISO 646
+   International Reference Version) is more complex than hostname-
+   restricted-ASCII (the "LDH" form, see section 1.1).  And ASCII isn't
+   sufficient to completely represent English -- there are several words
+   in the language that are correctly spelled only with characters or
+   diacritical marks that do not appear in ASCII.  With a broader
+   selection of scripts, in some examples, case mapping works from one
+   case to the other but is not reversible.  In others, there are
+   conventions about alternate ways to represent characters (in the
+   language, not [only] in character coding) that work most of the time,
+   but not always.  And there are issues in coding, with Unicode/10646
+   providing different ways to represent the same character
+   ("character", rather than "glyph", is used deliberately here).  And,
+   in still others, there are questions as to whether two glyphs
+   "match", which may be a distance-function question, not one with a
+   binary answer.  The IETF approach to these problems is to require
+   pre-matching canonicalization (see the "stringprep" discussion
+   below).
+
+   The IETF has resisted the temptations to either try to specify an
+   entirely new coded character set, or to pick and choose Unicode/10646
+   characters on a per-character basis rather than by using well-defined
+   blocks.  While it may appear that a character set designed to meet
+   Internet-specific needs would be very attractive, the IETF has never
+   had the expertise, resources, and representation from critically-
+   important communities to actually take on that job.  Perhaps more
+   important, a new effort might have chosen to make some of the many
+   complex tradeoffs differently than the Unicode committee did,
+   producing a code with somewhat different characteristics.  But there
+   is no evidence that doing so would produce a code with fewer problems
+   and side-effects.  It is much more likely that making tradeoffs
+   differently would simply result in a different set of problems, which
+   would be equally or more difficult.
+
+
+
+
+
+
+Klensin                      Informational                     [Page 16]
+
+RFC 3467          Role of the Domain Name System (DNS)     February 2003
+
+
+4.2 The "ASCII Encoding" Approaches
+
+   While the DNS can handle arbitrary binary strings without known
+   internal problems (see [RFC2181]), some restrictions are imposed by
+   the requirement that text be interpreted in a case-independent way
+   ([RFC1034], [RFC1035]).  More important, most internet applications
+   assume the hostname-restricted "LDH" syntax that is specified in the
+   host table RFCs and as "prudent" in RFC 1035.  If those assumptions
+   are not met, many conforming implementations of those applications
+   may exhibit behavior that would surprise implementors and users.  To
+   avoid these potential problems, IETF internationalization work has
+   focused on "ASCII-Compatible Encodings" (ACE).  These encodings
+   preserve the LDH conventions in the DNS itself.  Implementations of
+   applications that have not been upgraded utilize the encoded forms,
+   while newer ones can be written to recognize the special codings and
+   map them into non-ASCII characters. These approaches are, however,
+   not problem-free even if human interface issues are ignored.  Among
+   other issues, they rely on what is ultimately a heuristic to
+   determine whether a DNS label is to be considered as an
+   internationalized name (i.e., encoded Unicode) or interpreted as an
+   actual LDH name in its own right.  And, while all determinations of
+   whether a particular query matches a stored object are traditionally
+   made by DNS servers, the ACE systems, when combined with the
+   complexities of international scripts and names, require that much of
+   the matching work be separated into a separate, client-side,
+   canonicalization or "preparation" process before the DNS matching
+   mechanisms are invoked [STRINGPREP].
+
+4.3 "Stringprep" and Its Complexities
+
+   As outlined above, the model for avoiding problems associated with
+   putting non-ASCII names in the DNS and elsewhere evolved into the
+   principle that strings are to be placed into the DNS only after being
+   passed through a string preparation function that eliminates or
+   rejects spurious character codes, maps some characters onto others,
+   performs some sequence canonicalization, and generally creates forms
+   that can be accurately compared.  The impact of this process on
+   hostname-restricted ASCII (i.e., "LDH") strings is trivial and
+   essentially adds only overhead.  For other scripts, the impact is, of
+   necessity, quite significant.
+
+   Although the general notion underlying stringprep is simple, the many
+   details are quite subtle and the associated tradeoffs are complex. A
+   design team worked on it for months, with considerable effort placed
+   into clarifying and fine-tuning the protocol and tables.  Despite
+   general agreement that the IETF would avoid getting into the business
+   of defining character sets, character codings, and the associated
+   conventions, the group several times considered and rejected special
+
+
+
+Klensin                      Informational                     [Page 17]
+
+RFC 3467          Role of the Domain Name System (DNS)     February 2003
+
+
+   treatment of code positions to more nearly match the distinctions
+   made by Unicode with user perceptions about similarities and
+   differences between characters.  But there were intense temptations
+   (and pressures) to incorporate language-specific or country-specific
+   rules.  Those temptations, even when resisted, were indicative of
+   parts of the ongoing controversy or of the basic unsuitability of the
+   DNS for fully internationalized names that are visible,
+   comprehensible, and predictable for end users.
+
+   There have also been controversies about how far one should go in
+   these processes of preparation and transformation and, ultimately,
+   about the validity of various analogies.  For example, each of the
+   following operations has been claimed to be similar to case-mapping
+   in ASCII:
+
+   o  stripping of vowels in Arabic or Hebrew
+
+   o  matching of "look-alike" characters such as upper-case Alpha in
+      Greek and upper-case A in Roman-based alphabets
+
+   o  matching of Traditional and Simplified Chinese characters that
+      represent the same words,
+
+   o  matching of Serbo-Croatian words whether written in Roman-derived
+      or Cyrillic characters
+
+   A decision to support any of these operations would have implications
+   for other scripts or languages and would increase the overall
+   complexity of the process.  For example, unless language-specific
+   information is somehow available, performing matching between
+   Traditional and Simplified Chinese has impacts on Japanese and Korean
+   uses of the same "traditional" characters (e.g., it would not be
+   appropriate to map Kanji into Simplified Chinese).
+
+   Even were the IDN-WG's other work to have been abandoned completely
+   or if it were to fail in the marketplace, the stringprep and nameprep
+   work will continue to be extremely useful, both in identifying issues
+   and problem code points and in providing a reasonable set of basic
+   rules.  Where problems remain, they are arguably not with nameprep,
+   but with the DNS-imposed requirement that its results, as with all
+   other parts of the matching and comparison process, yield a binary
+   "match or no match" answer, rather than, e.g., a value on a
+   similarity scale that can be evaluated by the user or by user-driven
+   heuristic functions.
+
+
+
+
+
+
+
+Klensin                      Informational                     [Page 18]
+
+RFC 3467          Role of the Domain Name System (DNS)     February 2003
+
+
+4.4 The Unicode Stability Problem
+
+   ISO 10646 basically defines only code points, and not rules for using
+   or comparing the characters.  This is part of a long-standing
+   tradition with the work of what is now ISO/IEC JTC1/SC2: they have
+   performed code point assignments and have typically treated the ways
+   in which characters are used as beyond their scope.  Consequently,
+   they have not dealt effectively with the broader range of
+   internationalization issues.  By contrast, the Unicode Technical
+   Committee (UTC) has defined, in annexes and technical reports (see,
+   e.g., [UTR15]), some additional rules for canonicalization and
+   comparison.  Many of those rules and conventions have been factored
+   into the "stringprep" and "nameprep" work, but it is not
+   straightforward to make or define them in a fashion that is
+   sufficiently precise and permanent to be relied on by the DNS.
+
+   Perhaps more important, the discussions leading to nameprep also
+   identified several areas in which the UTC definitions are inadequate,
+   at least without additional information, to make matching precise and
+   unambiguous.  In some of these cases, the Unicode Standard permits
+   several alternate approaches, none of which are an exact and obvious
+   match to DNS needs.  That has left these sensitive choices up to
+   IETF, which lacks sufficient in-depth expertise, much less any
+   mechanism for deciding to optimize one language at the expense of
+   another.
+
+   For example, it is tempting to define some rules on the basis of
+   membership in particular scripts, or for punctuation characters, but
+   there is no precise definition of what characters belong to which
+   script or which ones are, or are not, punctuation.  The existence of
+   these areas of vagueness raises two issues: whether trying to do
+   precise matching at the character set level is actually possible
+   (addressed below) and whether driving toward more precision could
+   create issues that cause instability in the implementation and
+   resolution models for the DNS.
+
+   The Unicode definition also evolves.  Version 3.2 appeared shortly
+   after work on this document was initiated.  It added some characters
+   and functionality and included a few minor incompatible code point
+   changes.  IETF has secured an agreement about constraints on future
+   changes, but it remains to be seen how that agreement will work out
+   in practice.  The prognosis actually appears poor at this stage,
+   since UTC chose to ballot a recent possible change which should have
+   been prohibited by the agreement (the outcome of the ballot is not
+   relevant, only that the ballot was issued rather than having the
+   result be a foregone conclusion).  However, some members of the
+   community consider some of the changes between Unicode 3.0 and 3.1
+   and between 3.1 and 3.2, as well as this recent ballot, to be
+
+
+
+Klensin                      Informational                     [Page 19]
+
+RFC 3467          Role of the Domain Name System (DNS)     February 2003
+
+
+   evidence of instability and that these instabilities are better
+   handled in a system that can be more flexible about handling of
+   characters, scripts, and ancillary information than the DNS.
+
+   In addition, because the systems implications of internationalization
+   are considered out of scope in SC2, ISO/IEC JTC1 has assigned some of
+   those issues to its SC22/WG20 (the Internationalization working group
+   within the subcommittee that deals with programming languages,
+   systems, and environments).  WG20 has historically dealt with
+   internationalization issues thoughtfully and in depth, but its status
+   has several times been in doubt in recent years.  However, assignment
+   of these matters to WG20 increases the risk of eventual ISO
+   internationalization standards that specify different behavior than
+   the UTC specifications.
+
+4.5 Audiences, End Users, and the User Interface Problem
+
+   Part of what has "caused" the DNS internationalization problem, as
+   well as the DNS trademark problem and several others, is that we have
+   stopped thinking about "identifiers for objects" -- which normal
+   people are not expected to see -- and started thinking about "names"
+   -- strings that are expected not only to be readable, but to have
+   linguistically-sensible and culturally-dependent meaning to non-
+   specialist users.
+
+   Within the IETF, the IDN-WG, and sometimes other groups, avoided
+   addressing the implications of that transition by taking "outside our
+   scope -- someone else's problem" approaches or by suggesting that
+   people will just become accustomed to whatever conventions are
+   adopted.  The realities of user and vendor behavior suggest that
+   these approaches will not serve the Internet community well in the
+   long term:
+
+   o  If we want to make it a problem in a different part of the user
+      interface structure, we need to figure out where it goes in order
+      to have proof of concept of our solution.  Unlike vendors whose
+      sole [business] model is the selling or registering of names, the
+      IETF must produce solutions that actually work, in the
+      applications context as seen by the end user.
+
+   o  The principle that "they will get used to our conventions and
+      adapt" is fine if we are writing rules for programming languages
+      or an API.  But the conventions under discussion are not part of a
+      semi-mathematical system, they are deeply ingrained in culture.
+      No matter how often an English-speaking American is told that the
+      Internet requires that the correct spelling of "colour" be used,
+      he or she isn't going to be convinced. Getting a French-speaker in
+      Lyon to use exactly the same lexical conventions as a French-
+
+
+
+Klensin                      Informational                     [Page 20]
+
+RFC 3467          Role of the Domain Name System (DNS)     February 2003
+
+
+      speaker in Quebec in order to accommodate the decisions of the
+      IETF or of a registrar or registry is just not likely.  "Montreal"
+      is either a misspelling or an anglicization of a similar word with
+      an acute accent mark over the "e" (i.e., using the Unicode
+      character U+00E9 or one of its equivalents). But global agreement
+      on a rule that will determine whether the two forms should match
+      -- and that won't astonish end users and speakers of one language
+      or the other -- is as unlikely as agreement on whether
+      "misspelling" or "anglicization" is the greater travesty.
+
+   More generally, it is not clear that the outcome of any conceivable
+   nameprep-like process is going to be good enough for practical,
+   user-level, use.  In the use of human languages by humans, there are
+   many cases in which things that do not match are nonetheless
+   interpreted as matching.  The Norwegian/Danish character that appears
+   in U+00F8 (visually, a lower case 'o' overstruck with a forward
+   slash) and the "o-umlaut" German character that appears in U+00F6
+   (visually, a lower case 'o' with diaeresis (or umlaut)) are clearly
+   different and no matching program should yield an "equal" comparison.
+   But they are more similar to each other than either of them is to,
+   e.g., "e".  Humans are able to mentally make the correction in
+   context, and do so easily, and they can be surprised if computers
+   cannot do so.  Worse, there is a Swedish character whose appearance
+   is identical to the German o-umlaut, and which shares code point
+   U+00F6, but that, if the languages are known and the sounds of the
+   letters or meanings of words including the character are considered,
+   actually should match the Norwegian/Danish use of U+00F8.
+
+   This text uses examples in Roman scripts because it is being written
+   in English and those examples are relatively easy to render.  But one
+   of the important lessons of the discussions about domain name
+   internationalization in recent years is that problems similar to
+   those described above exist in almost every language and script.
+   Each one has its idiosyncrasies, and each set of idiosyncracies is
+   tied to common usage and cultural issues that are very familiar in
+   the relevant group, and often deeply held as cultural values.  As
+   long as a schoolchild in the US can get a bad grade on a spelling
+   test for using a perfectly valid British spelling, or one in France
+   or Germany can get a poor grade for leaving off a diacritical mark,
+   there are issues with the relevant language.  Similarly, if children
+   in Egypt or Israel are taught that it is acceptable to write a word
+   with or without vowels or stress marks, but that, if those marks are
+   included, they must be the correct ones, or a user in Korea is
+   potentially offended or astonished by out-of-order sequences of Jamo,
+   systems based on character-at-a-time processing and simplistic
+   matching, with no contextual information, are not going to satisfy
+   user needs.
+
+
+
+
+Klensin                      Informational                     [Page 21]
+
+RFC 3467          Role of the Domain Name System (DNS)     February 2003
+
+
+   Users are demanding solutions that deal with language and culture.
+   Systems of identifier symbol-strings that serve specialists or
+   computers are, at best, a solution to a rather different (and, at the
+   time this document was written, somewhat ill-defined), problem.  The
+   recent efforts have made it ever more clear that, if we ignore the
+   distinction between the user requirements and narrowly-defined
+   identifiers, we are solving an insufficient problem.  And,
+   conversely, the approaches that have been proposed to approximate
+   solutions to the user requirement may be far more complex than simple
+   identifiers require.
+
+4.6 Business Cards and Other Natural Uses of Natural Languages
+
+   Over the last few centuries, local conventions have been established
+   in various parts of the world for dealing with multilingual
+   situations.  It may be helpful to examine some of these.  For
+   example, if one visits a country where the language is different from
+   ones own, business cards are often printed on two sides, one side in
+   each language.  The conventions are not completely consistent and the
+   technique assumes that recipients will be tolerant. Translations of
+   names or places are attempted in some situations and transliterations
+   in others.  Since it is widely understood that exact translations or
+   transliterations are often not possible, people typically smile at
+   errors, appreciate the effort, and move on.
+
+   The DNS situation differs from these practices in at least two ways.
+   Since a global solution is required, the business card would need a
+   number of sides approximating the number of languages in the world,
+   which is probably impossible without violating laws of physics.  More
+   important, the opportunities for tolerance don't exist:  the DNS
+   requires a exact match or the lookup fails.
+
+4.7 ASCII Encodings and the Roman Keyboard Assumption
+
+   Part of the argument for ACE-based solutions is that they provide an
+   escape for multilingual environments when applications have not been
+   upgraded.  When an older application encounters an ACE-based name,
+   the assumption is that the (admittedly ugly) ASCII-coded string will
+   be displayed and can be typed in.  This argument is reasonable from
+   the standpoint of mixtures of Roman-based alphabets, but may not be
+   relevant if user-level systems and devices are involved that do not
+   support the entry of Roman-based characters or which cannot
+   conveniently render such characters.  Such systems are few in the
+   world today, but the number can reasonably be expected to rise as the
+   Internet is increasingly used by populations whose primary concern is
+   with local issues, local information, and local languages.  It is,
+
+
+
+
+
+Klensin                      Informational                     [Page 22]
+
+RFC 3467          Role of the Domain Name System (DNS)     February 2003
+
+
+   for example, fairly easy to imagine populations who use Arabic or
+   Thai scripts and who do not have routine access to scripts or input
+   devices based on Roman-derived alphabets.
+
+4.8 Intra-DNS Approaches for "Multilingual Names"
+
+   It appears, from the cases above and others, that none of the intra-
+   DNS-based solutions for "multilingual names" are workable.  They rest
+   on too many assumptions that do not appear to be feasible -- that
+   people will adapt deeply-entrenched language habits to conventions
+   laid down to make the lives of computers easy; that we can make
+   "freeze it now, no need for changes in these areas" decisions about
+   Unicode and nameprep; that ACE will smooth over applications
+   problems, even in environments without the ability to key or render
+   Roman-based glyphs (or where user experience is such that such glyphs
+   cannot easily be distinguished from each other); that the Unicode
+   Consortium will never decide to repair an error in a way that creates
+   a risk of DNS incompatibility; that we can either deploy EDNS
+   [RFC2671] or that long names are not really important; that Japanese
+   and Chinese computer users (and others) will either give up their
+   local or IS 2022-based character coding solutions (for which addition
+   of a large fraction of a million new code points to Unicode is almost
+   certainly a necessary, but probably not sufficient, condition) or
+   build leakproof and completely accurate boundary conversion
+   mechanisms; that out of band or contextual information will always be
+   sufficient for the "map glyph onto script" problem; and so on.  In
+   each case, it is likely that about 80% or 90% of cases will work
+   satisfactorily, but it is unlikely that such partial solutions will
+   be good enough.  For example, suppose someone can spell her name 90%
+   correctly, or a company name is matched correctly 80% of the time but
+   the other 20% of attempts identify a competitor: are either likely to
+   be considered adequate?
+
+5. Search-based Systems: The Key Controversies
+
+   For many years, a common response to requirements to locate people or
+   resources on the Internet has been to invoke the term "directory".
+   While an in-depth analysis of the reasons would require a separate
+   document, the history of failure of these invocations has given
+   "directory" efforts a bad reputation.  The effort proposed here is
+   different from those predecessors for several reasons, perhaps the
+   most important of which is that it focuses on a fairly-well-
+   understood set of problems and needs, rather than on finding uses for
+   a particular technology.
+
+   As suggested in some of the text above, it is an open question as to
+   whether the needs of the community would be best served by a single
+   (even if functionally, and perhaps administratively, distributed)
+
+
+
+Klensin                      Informational                     [Page 23]
+
+RFC 3467          Role of the Domain Name System (DNS)     February 2003
+
+
+   directory with universal applicability, a single directory that
+   supports locally-tailored search (and, most important, matching)
+   functions, or multiple, locally-determined, directories.  Each has
+   its attractions.  Any but the first would essentially prevent
+   reverse-mapping (determination of the user-visible name of the host
+   or resource from target information such as an address or DNS name).
+   But reverse mapping has become less useful over the years --at least
+   to users -- as more and more names have been associated with many
+   host addresses and as CIDR [CIDR] has proven problematic for mapping
+   smaller address blocks to meaningful names.
+
+   Locally-tailored searches and mappings would permit national
+   variations on interpretation of which strings matched which other
+   ones, an arrangement that is especially important when different
+   localities apply different rules to, e.g., matching of characters
+   with and without diacriticals.  But, of course, this implies that a
+   URL may evaluate properly or not depending on either settings on a
+   client machine or the network connectivity of the user.  That is not,
+   in general, a desirable situation, since it implies that users could
+   not, in the general case, share URLs (or other host references) and
+   that a particular user might not be able to carry references from one
+   host or location to another.
+
+   And, of course, completely separate directories would permit
+   translation and transliteration functions to be embedded in the
+   directory, giving much of the Internet a different appearance
+   depending on which directory was chosen.  The attractions of this are
+   obvious, but, unless things were very carefully designed to preserve
+   uniqueness and precise identities at the right points (which may or
+   may not be possible), such a system would have many of the
+   difficulties associated with multiple DNS roots.
+
+   Finally, a system of separate directories and databases, if coupled
+   with removal of the DNS-imposed requirement for unique names, would
+   largely eliminate the need for a single worldwide authority to manage
+   the top of the naming hierarchy.
+
+6.  Security Considerations
+
+   The set of proposals implied by this document suggests an interesting
+   set of security issues (i.e., nothing important is ever easy).  A
+   directory system used for locating network resources would presumably
+   need to be as carefully protected against unauthorized changes as the
+   DNS itself.  There also might be new opportunities for problems in an
+   arrangement involving two or more (sub)layers, especially if such a
+   system were designed without central authority or uniqueness of
+   names.  It is uncertain how much greater those risks would be as
+   compared to a DNS lookup sequence that involved looking up one name,
+
+
+
+Klensin                      Informational                     [Page 24]
+
+RFC 3467          Role of the Domain Name System (DNS)     February 2003
+
+
+   getting back information, and then doing additional lookups
+   potentially in different subtrees.  That multistage lookup will often
+   be the case with, e.g., NAPTR records [RFC 2915] unless additional
+   restrictions are imposed.  But additional steps, systems, and
+   databases almost certainly involve some additional risks of
+   compromise.
+
+7.  References
+
+7.1 Normative References
+
+   None
+
+7.2 Explanatory and Informative References
+
+   [Albitz]       Any of the editions of Albitz, P. and C. Liu, DNS and
+                  BIND, O'Reilly and Associates, 1992, 1997, 1998, 2001.
+
+   [ASCII]        American National Standards Institute (formerly United
+                  States of America Standards Institute), X3.4, 1968,
+                  "USA Code for Information Interchange". ANSI X3.4-1968
+                  has been replaced by newer versions with slight
+                  modifications, but the 1968 version remains definitive
+                  for the Internet.  Some time after ASCII was first
+                  formulated as a standard, ISO adopted international
+                  standard 646, which uses ASCII as a base.  IS 646
+                  actually contained two code tables: an "International
+                  Reference Version" (often referenced as ISO 646-IRV)
+                  which was essentially identical to the ASCII of the
+                  time, and a "Basic Version" (ISO 646-BV), which
+                  designates a number of character positions for
+                  national use.
+
+   [CIDR]         Fuller, V., Li, T., Yu, J. and K. Varadhan, "Classless
+                  Inter-Domain Routing (CIDR): an Address Assignment and
+                  Aggregation Strategy", RFC 1519, September 1993.
+
+                  Eidnes, H., de Groot, G. and P. Vixie, "Classless IN-
+                  ADDR.ARPA delegation", RFC 2317, March 1998.
+
+   [COM-SIZE]     Size information supplied by Verisign Global Registry
+                  Services (the zone administrator, or "registry
+                  operator", for COM, see [REGISTRAR], below) to ICANN,
+                  third quarter 2002.
+
+   [DNS-Search]   Klensin, J., "A Search-based access model for the
+                  DNS", Work in Progress.
+
+
+
+
+Klensin                      Informational                     [Page 25]
+
+RFC 3467          Role of the Domain Name System (DNS)     February 2003
+
+
+   [FINGER]       Zimmerman, D., "The Finger User Information Protocol",
+                  RFC 1288, December 1991.
+
+                  Harrenstien, K., "NAME/FINGER Protocol", RFC 742,
+                  December 1977.
+
+   [IAB-OPES]     Floyd, S. and L. Daigle, "IAB Architectural and Policy
+                  Considerations for Open Pluggable Edge Services", RFC
+                  3238, January 2002.
+
+   [IQUERY]       Lawrence, D., "Obsoleting IQUERY", RFC 3425, November
+                  2002.
+
+   [IS646]        ISO/IEC 646:1991 Information technology -- ISO 7-bit
+                  coded character set for information interchange
+
+   [IS10646]      ISO/IEC 10646-1:2000 Information technology --
+                  Universal Multiple-Octet Coded Character Set (UCS) --
+                  Part 1: Architecture and Basic Multilingual Plane and
+                  ISO/IEC 10646-2:2001 Information technology --
+                  Universal Multiple-Octet Coded Character Set (UCS) --
+                  Part 2: Supplementary Planes
+
+   [MINC]         The Multilingual Internet Names Consortium,
+                  http://www.minc.org/ has been an early advocate for
+                  the importance of expansion of DNS names to
+                  accommodate non-ASCII characters.  Some of their
+                  specific proposals, while helping people to understand
+                  the problems better, were not compatible with the
+                  design of the DNS.
+
+   [NAPTR]        Mealling, M. and R. Daniel, "The Naming Authority
+                  Pointer (NAPTR) DNS Resource Record", RFC 2915,
+                  September 2000.
+
+                  Mealling, M., "Dynamic Delegation Discovery System
+                  (DDDS) Part One: The Comprehensive DDDS", RFC 3401,
+                  October 2002.
+
+                  Mealling, M., "Dynamic Delegation Discovery System
+                  (DDDS) Part Two: The Algorithm", RFC 3402, October
+                  2002.
+
+                  Mealling, M., "Dynamic Delegation Discovery System
+                  (DDDS) Part Three: The Domain Name System (DNS)
+                  Database", RFC 3403, October 2002.
+
+
+
+
+
+Klensin                      Informational                     [Page 26]
+
+RFC 3467          Role of the Domain Name System (DNS)     February 2003
+
+
+   [REGISTRAR]    In an early stage of the process that created the
+                  Internet Corporation for Assigned Names and Numbers
+                  (ICANN), a "Green Paper" was released by the US
+                  Government.   That paper introduced new terminology
+                  and some concepts not needed by traditional DNS
+                  operations.  The term "registry" was applied to the
+                  actual operator and database holder of a domain
+                  (typically at the top level, since the Green Paper was
+                  little concerned with anything else), while
+                  organizations that marketed names and made them
+                  available to "registrants" were known as "registrars".
+                  In the classic DNS model, the function of "zone
+                  administrator" encompassed both registry and registrar
+                  roles, although that model did not anticipate a
+                  commercial market in names.
+
+   [RFC625]       Kudlick, M. and E. Feinler, "On-line hostnames
+                  service", RFC 625, March 1974.
+
+   [RFC734]       Crispin, M., "SUPDUP Protocol", RFC 734, October 1977.
+
+   [RFC811]       Harrenstien, K., White, V. and E. Feinler, "Hostnames
+                  Server", RFC 811, March 1982.
+
+   [RFC819]       Su, Z. and J. Postel, "Domain naming convention for
+                  Internet user applications", RFC 819, August 1982.
+
+   [RFC830]       Su, Z., "Distributed system for Internet name
+                  service", RFC 830, October 1982.
+
+   [RFC882]       Mockapetris, P., "Domain names: Concepts and
+                  facilities", RFC 882, November 1983.
+
+   [RFC883]       Mockapetris, P., "Domain names: Implementation
+                  specification", RFC 883, November 1983.
+
+   [RFC952]       Harrenstien, K, Stahl, M. and E. Feinler, "DoD
+                  Internet host table specification", RFC 952, October
+                  1985.
+
+   [RFC953]       Harrenstien, K., Stahl, M. and E. Feinler, "HOSTNAME
+                  SERVER", RFC 953, October 1985.
+
+   [RFC1034]      Mockapetris, P., "Domain names, Concepts and
+                  facilities", STD 13, RFC 1034, November 1987.
+
+
+
+
+
+
+Klensin                      Informational                     [Page 27]
+
+RFC 3467          Role of the Domain Name System (DNS)     February 2003
+
+
+   [RFC1035]      Mockapetris, P., "Domain names - implementation and
+                  specification", STD 13, RFC 1035, November 1987.
+
+   [RFC1591]      Postel, J., "Domain Name System Structure and
+                  Delegation", RFC 1591, March 1994.
+
+   [RFC2181]      Elz, R. and  R. Bush, "Clarifications to the DNS
+                  Specification", RFC 2181, July 1997.
+
+   [RFC2295]      Holtman, K. and A. Mutz, "Transparent Content
+                  Negotiation in HTTP", RFC 2295, March 1998
+
+   [RFC2396]      Berners-Lee, T., Fielding, R. and L. Masinter,
+                  "Uniform Resource Identifiers (URI): Generic Syntax",
+                  RFC 2396, August 1998.
+
+   [RFC2608]      Guttman, E., Perkins, C., Veizades, J. and M. Day,
+                  "Service Location Protocol, Version 2", RFC 2608, June
+                  1999.
+
+   [RFC2671]      Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
+                  2671, August 1999.
+
+   [RFC2825]      IAB, Daigle, L., Ed., "A Tangled Web: Issues of I18N,
+                  Domain Names, and the Other Internet protocols", RFC
+                  2825, May 2000.
+
+   [RFC2826]      IAB, "IAB Technical Comment on the Unique DNS Root",
+                  RFC 2826, May 2000.
+
+   [RFC2972]      Popp, N., Mealling, M., Masinter, L. and K. Sollins,
+                  "Context and Goals for Common Name Resolution", RFC
+                  2972, October 2000.
+
+   [RFC3305]      Mealling, M. and R. Denenberg, Eds., "Report from the
+                  Joint W3C/IETF URI Planning Interest Group: Uniform
+                  Resource Identifiers (URIs), URLs, and Uniform
+                  Resource Names (URNs):  Clarifications and
+                  Recommendations", RFC 3305, August 2002.
+
+   [RFC3439]      Bush, R. and D. Meyer, "Some Internet Architectural
+                  Guidelines and Philosophy", RFC 3439, December 2002.
+
+   [Seng]         Seng, J., et al., Eds., "Internationalized Domain
+                  Names:  Registration and Administration Guideline for
+                  Chinese, Japanese, and Korean", Work in Progress.
+
+
+
+
+
+Klensin                      Informational                     [Page 28]
+
+RFC 3467          Role of the Domain Name System (DNS)     February 2003
+
+
+   [STRINGPREP]   Hoffman, P. and M. Blanchet, "Preparation of
+                  Internationalized Strings (stringprep)", RFC 3454,
+                  December 2002.
+
+                  The particular profile used for placing
+                  internationalized strings in the DNS is called
+                  "nameprep", described in Hoffman, P. and M. Blanchet,
+                  "Nameprep: A Stringprep Profile for Internationalized
+                  Domain Names", Work in Progress.
+
+   [TELNET]       Postel, J. and J. Reynolds, "Telnet Protocol
+                  Specification", STD 8, RFC 854, May 1983.
+
+                  Postel, J. and J. Reynolds, "Telnet Option
+                  Specifications", STD 8, RFC 855, May 1983.
+
+   [UNICODE]      The Unicode Consortium, The Unicode Standard, Version
+                  3.0, Addison-Wesley: Reading, MA, 2000.  Update to
+                  version 3.1, 2001.  Update to version 3.2, 2002.
+
+   [UTR15]        Davis, M. and M. Duerst, "Unicode Standard Annex #15:
+                  Unicode Normalization Forms", Unicode Consortium,
+                  March 2002.  An integral part of The Unicode Standard,
+                  Version 3.1.1.  Available at
+                  (http://www.unicode.org/reports/tr15/tr15-21.html).
+
+   [WHOIS]        Harrenstien, K, Stahl, M. and E. Feinler,
+                  "NICNAME/WHOIS", RFC 954, October 1985.
+
+   [WHOIS-UPDATE] Gargano, J. and K. Weiss, "Whois and Network
+                  Information Lookup Service, Whois++", RFC 1834, August
+                  1995.
+
+                  Weider, C., Fullton, J. and S. Spero, "Architecture of
+                  the Whois++ Index Service", RFC 1913, February 1996.
+
+                  Williamson, S., Kosters, M., Blacka, D., Singh, J. and
+                  K. Zeilstra, "Referral Whois (RWhois) Protocol V1.5",
+                  RFC 2167, June 1997;
+
+                  Daigle, L. and P. Faltstrom, "The
+                  application/whoispp-query Content-Type", RFC 2957,
+                  October 2000.
+
+                  Daigle, L. and P. Falstrom, "The application/whoispp-
+                  response Content-type", RFC 2958, October 2000.
+
+
+
+
+
+Klensin                      Informational                     [Page 29]
+
+RFC 3467          Role of the Domain Name System (DNS)     February 2003
+
+
+   [X29]          International Telecommuncations Union, "Recommendation
+                  X.29: Procedures for the exchange of control
+                  information and user data between a Packet
+                  Assembly/Disassembly (PAD) facility and a packet mode
+                  DTE or another PAD", December 1997.
+
+8. Acknowledgements
+
+   Many people have contributed to versions of this document or the
+   thinking that went into it.  The author would particularly like to
+   thank Harald Alvestrand, Rob Austein, Bob Braden, Vinton Cerf, Matt
+   Crawford, Leslie Daigle, Patrik Faltstrom, Eric A. Hall, Ted Hardie,
+   Paul Hoffman, Erik Nordmark, and Zita Wenzel for making specific
+   suggestions and/or challenging the assumptions and presentation of
+   earlier versions and suggesting ways to improve them.
+
+9. Author's Address
+
+   John C. Klensin
+   1770 Massachusetts Ave, #322
+   Cambridge, MA 02140
+
+   EMail: klensin+srch@jck.com
+
+   A mailing list has been initiated for discussion of the topics
+   discussed in this document, and closely-related issues, at
+   ietf-irnss@lists.elistx.com.  See http://lists.elistx.com/archives/
+   for subscription and archival information.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Klensin                      Informational                     [Page 30]
+
+RFC 3467          Role of the Domain Name System (DNS)     February 2003
+
+
+10. Full Copyright Statement
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Klensin                      Informational                     [Page 31]
+
diff --git a/doc/rfc/rfc3490.txt b/doc/rfc/rfc3490.txt
new file mode 100644
index 0000000..d2e0b3b
--- /dev/null
+++ b/doc/rfc/rfc3490.txt
@@ -0,0 +1,1235 @@
+
+
+
+
+
+
+Network Working Group                                       P. Faltstrom
+Request for Comments: 3490                                         Cisco
+Category: Standards Track                                     P. Hoffman
+                                                              IMC & VPNC
+                                                             A. Costello
+                                                             UC Berkeley
+                                                              March 2003
+
+
+         Internationalizing Domain Names in Applications (IDNA)
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+Abstract
+
+   Until now, there has been no standard method for domain names to use
+   characters outside the ASCII repertoire.  This document defines
+   internationalized domain names (IDNs) and a mechanism called
+   Internationalizing Domain Names in Applications (IDNA) for handling
+   them in a standard fashion.  IDNs use characters drawn from a large
+   repertoire (Unicode), but IDNA allows the non-ASCII characters to be
+   represented using only the ASCII characters already allowed in so-
+   called host names today.  This backward-compatible representation is
+   required in existing protocols like DNS, so that IDNs can be
+   introduced with no changes to the existing infrastructure.  IDNA is
+   only meant for processing domain names, not free text.
+
+Table of Contents
+
+   1. Introduction..................................................  2
+      1.1 Problem Statement.........................................  3
+      1.2 Limitations of IDNA.......................................  3
+      1.3 Brief overview for application developers.................  4
+   2. Terminology...................................................  5
+   3. Requirements and applicability................................  7
+      3.1 Requirements..............................................  7
+      3.2 Applicability.............................................  8
+         3.2.1. DNS resource records................................  8
+
+
+
+Faltstrom, et al.           Standards Track                     [Page 1]
+
+RFC 3490                          IDNA                        March 2003
+
+
+         3.2.2. Non-domain-name data types stored in domain names...  9
+   4. Conversion operations.........................................  9
+      4.1 ToASCII................................................... 10
+      4.2 ToUnicode................................................. 11
+   5. ACE prefix.................................................... 12
+   6. Implications for typical applications using DNS............... 13
+      6.1 Entry and display in applications......................... 14
+      6.2 Applications and resolver libraries....................... 15
+      6.3 DNS servers............................................... 15
+      6.4 Avoiding exposing users to the raw ACE encoding........... 16
+      6.5  DNSSEC authentication of IDN domain names................ 16
+   7. Name server considerations.................................... 17
+   8. Root server considerations.................................... 17
+   9. References.................................................... 18
+      9.1 Normative References...................................... 18
+      9.2 Informative References.................................... 18
+   10. Security Considerations...................................... 19
+   11. IANA Considerations.......................................... 20
+   12. Authors' Addresses........................................... 21
+   13. Full Copyright Statement..................................... 22
+
+1. Introduction
+
+   IDNA works by allowing applications to use certain ASCII name labels
+   (beginning with a special prefix) to represent non-ASCII name labels.
+   Lower-layer protocols need not be aware of this; therefore IDNA does
+   not depend on changes to any infrastructure.  In particular, IDNA
+   does not depend on any changes to DNS servers, resolvers, or protocol
+   elements, because the ASCII name service provided by the existing DNS
+   is entirely sufficient for IDNA.
+
+   This document does not require any applications to conform to IDNA,
+   but applications can elect to use IDNA in order to support IDN while
+   maintaining interoperability with existing infrastructure.  If an
+   application wants to use non-ASCII characters in domain names, IDNA
+   is the only currently-defined option.  Adding IDNA support to an
+   existing application entails changes to the application only, and
+   leaves room for flexibility in the user interface.
+
+   A great deal of the discussion of IDN solutions has focused on
+   transition issues and how IDN will work in a world where not all of
+   the components have been updated.  Proposals that were not chosen by
+   the IDN Working Group would depend on user applications, resolvers,
+   and DNS servers being updated in order for a user to use an
+   internationalized domain name.  Rather than rely on widespread
+   updating of all components, IDNA depends on updates to user
+   applications only; no changes are needed to the DNS protocol or any
+   DNS servers or the resolvers on user's computers.
+
+
+
+Faltstrom, et al.           Standards Track                     [Page 2]
+
+RFC 3490                          IDNA                        March 2003
+
+
+1.1 Problem Statement
+
+   The IDNA specification solves the problem of extending the repertoire
+   of characters that can be used in domain names to include the Unicode
+   repertoire (with some restrictions).
+
+   IDNA does not extend the service offered by DNS to the applications.
+   Instead, the applications (and, by implication, the users) continue
+   to see an exact-match lookup service.  Either there is a single
+   exactly-matching name or there is no match.  This model has served
+   the existing applications well, but it requires, with or without
+   internationalized domain names, that users know the exact spelling of
+   the domain names that the users type into applications such as web
+   browsers and mail user agents.  The introduction of the larger
+   repertoire of characters potentially makes the set of misspellings
+   larger, especially given that in some cases the same appearance, for
+   example on a business card, might visually match several Unicode code
+   points or several sequences of code points.
+
+   IDNA allows the graceful introduction of IDNs not only by avoiding
+   upgrades to existing infrastructure (such as DNS servers and mail
+   transport agents), but also by allowing some rudimentary use of IDNs
+   in applications by using the ASCII representation of the non-ASCII
+   name labels.  While such names are very user-unfriendly to read and
+   type, and hence are not suitable for user input, they allow (for
+   instance) replying to email and clicking on URLs even though the
+   domain name displayed is incomprehensible to the user.  In order to
+   allow user-friendly input and output of the IDNs, the applications
+   need to be modified to conform to this specification.
+
+   IDNA uses the Unicode character repertoire, which avoids the
+   significant delays that would be inherent in waiting for a different
+   and specific character set be defined for IDN purposes by some other
+   standards developing organization.
+
+1.2 Limitations of IDNA
+
+   The IDNA protocol does not solve all linguistic issues with users
+   inputting names in different scripts.  Many important language-based
+   and script-based mappings are not covered in IDNA and need to be
+   handled outside the protocol.  For example, names that are entered in
+   a mix of traditional and simplified Chinese characters will not be
+   mapped to a single canonical name.  Another example is Scandinavian
+   names that are entered with U+00F6 (LATIN SMALL LETTER O WITH
+   DIAERESIS) will not be mapped to U+00F8 (LATIN SMALL LETTER O WITH
+   STROKE).
+
+
+
+
+
+Faltstrom, et al.           Standards Track                     [Page 3]
+
+RFC 3490                          IDNA                        March 2003
+
+
+   An example of an important issue that is not considered in detail in
+   IDNA is how to provide a high probability that a user who is entering
+   a domain name based on visual information (such as from a business
+   card or billboard) or aural information (such as from a telephone or
+   radio) would correctly enter the IDN.  Similar issues exist for ASCII
+   domain names, for example the possible visual confusion between the
+   letter 'O' and the digit zero, but the introduction of the larger
+   repertoire of characters creates more opportunities of similar
+   looking and similar sounding names.  Note that this is a complex
+   issue relating to languages, input methods on computers, and so on.
+   Furthermore, the kind of matching and searching necessary for a high
+   probability of success would not fit the role of the DNS and its
+   exact matching function.
+
+1.3 Brief overview for application developers
+
+   Applications can use IDNA to support internationalized domain names
+   anywhere that ASCII domain names are already supported, including DNS
+   master files and resolver interfaces.  (Applications can also define
+   protocols and interfaces that support IDNs directly using non-ASCII
+   representations.  IDNA does not prescribe any particular
+   representation for new protocols, but it still defines which names
+   are valid and how they are compared.)
+
+   The IDNA protocol is contained completely within applications.  It is
+   not a client-server or peer-to-peer protocol: everything is done
+   inside the application itself.  When used with a DNS resolver
+   library, IDNA is inserted as a "shim" between the application and the
+   resolver library.  When used for writing names into a DNS zone, IDNA
+   is used just before the name is committed to the zone.
+
+   There are two operations described in section 4 of this document:
+
+   -  The ToASCII operation is used before sending an IDN to something
+      that expects ASCII names (such as a resolver) or writing an IDN
+      into a place that expects ASCII names (such as a DNS master file).
+
+   -  The ToUnicode operation is used when displaying names to users,
+      for example names obtained from a DNS zone.
+
+   It is important to note that the ToASCII operation can fail.  If it
+   fails when processing a domain name, that domain name cannot be used
+   as an internationalized domain name and the application has to have
+   some method of dealing with this failure.
+
+   IDNA requires that implementations process input strings with
+   Nameprep [NAMEPREP], which is a profile of Stringprep [STRINGPREP],
+   and then with Punycode [PUNYCODE].  Implementations of IDNA MUST
+
+
+
+Faltstrom, et al.           Standards Track                     [Page 4]
+
+RFC 3490                          IDNA                        March 2003
+
+
+   fully implement Nameprep and Punycode; neither Nameprep nor Punycode
+   are optional.
+
+2. Terminology
+
+   The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED",
+   and "MAY" in this document are to be interpreted as described in BCP
+   14, RFC 2119 [RFC2119].
+
+   A code point is an integer value associated with a character in a
+   coded character set.
+
+   Unicode [UNICODE] is a coded character set containing tens of
+   thousands of characters.  A single Unicode code point is denoted by
+   "U+" followed by four to six hexadecimal digits, while a range of
+   Unicode code points is denoted by two hexadecimal numbers separated
+   by "..", with no prefixes.
+
+   ASCII means US-ASCII [USASCII], a coded character set containing 128
+   characters associated with code points in the range 0..7F.  Unicode
+   is an extension of ASCII: it includes all the ASCII characters and
+   associates them with the same code points.
+
+   The term "LDH code points" is defined in this document to mean the
+   code points associated with ASCII letters, digits, and the hyphen-
+   minus; that is, U+002D, 30..39, 41..5A, and 61..7A. "LDH" is an
+   abbreviation for "letters, digits, hyphen".
+
+   [STD13] talks about "domain names" and "host names", but many people
+   use the terms interchangeably.  Further, because [STD13] was not
+   terribly clear, many people who are sure they know the exact
+   definitions of each of these terms disagree on the definitions.  In
+   this document the term "domain name" is used in general.  This
+   document explicitly cites [STD3] whenever referring to the host name
+   syntax restrictions defined therein.
+
+   A label is an individual part of a domain name.  Labels are usually
+   shown separated by dots; for example, the domain name
+   "www.example.com" is composed of three labels: "www", "example", and
+   "com".  (The zero-length root label described in [STD13], which can
+   be explicit as in "www.example.com." or implicit as in
+   "www.example.com", is not considered a label in this specification.)
+   IDNA extends the set of usable characters in labels that are text.
+   For the rest of this document, the term "label" is shorthand for
+   "text label", and "every label" means "every text label".
+
+
+
+
+
+
+Faltstrom, et al.           Standards Track                     [Page 5]
+
+RFC 3490                          IDNA                        March 2003
+
+
+   An "internationalized label" is a label to which the ToASCII
+   operation (see section 4) can be applied without failing (with the
+   UseSTD3ASCIIRules flag unset).  This implies that every ASCII label
+   that satisfies the [STD13] length restriction is an internationalized
+   label.  Therefore the term "internationalized label" is a
+   generalization, embracing both old ASCII labels and new non-ASCII
+   labels.  Although most Unicode characters can appear in
+   internationalized labels, ToASCII will fail for some input strings,
+   and such strings are not valid internationalized labels.
+
+   An "internationalized domain name" (IDN) is a domain name in which
+   every label is an internationalized label.  This implies that every
+   ASCII domain name is an IDN (which implies that it is possible for a
+   name to be an IDN without it containing any non-ASCII characters).
+   This document does not attempt to define an "internationalized host
+   name".  Just as has been the case with ASCII names, some DNS zone
+   administrators may impose restrictions, beyond those imposed by DNS
+   or IDNA, on the characters or strings that may be registered as
+   labels in their zones.  Such restrictions have no impact on the
+   syntax or semantics of DNS protocol messages; a query for a name that
+   matches no records will yield the same response regardless of the
+   reason why it is not in the zone.  Clients issuing queries or
+   interpreting responses cannot be assumed to have any knowledge of
+   zone-specific restrictions or conventions.
+
+   In IDNA, equivalence of labels is defined in terms of the ToASCII
+   operation, which constructs an ASCII form for a given label, whether
+   or not the label was already an ASCII label.  Labels are defined to
+   be equivalent if and only if their ASCII forms produced by ToASCII
+   match using a case-insensitive ASCII comparison.  ASCII labels
+   already have a notion of equivalence: upper case and lower case are
+   considered equivalent.  The IDNA notion of equivalence is an
+   extension of that older notion.  Equivalent labels in IDNA are
+   treated as alternate forms of the same label, just as "foo" and "Foo"
+   are treated as alternate forms of the same label.
+
+   To allow internationalized labels to be handled by existing
+   applications, IDNA uses an "ACE label" (ACE stands for ASCII
+   Compatible Encoding).  An ACE label is an internationalized label
+   that can be rendered in ASCII and is equivalent to an
+   internationalized label that cannot be rendered in ASCII.  Given any
+   internationalized label that cannot be rendered in ASCII, the ToASCII
+   operation will convert it to an equivalent ACE label (whereas an
+   ASCII label will be left unaltered by ToASCII).  ACE labels are
+   unsuitable for display to users.  The ToUnicode operation will
+   convert any label to an equivalent non-ACE label.  In fact, an ACE
+   label is formally defined to be any label that the ToUnicode
+   operation would alter (whereas non-ACE labels are left unaltered by
+
+
+
+Faltstrom, et al.           Standards Track                     [Page 6]
+
+RFC 3490                          IDNA                        March 2003
+
+
+   ToUnicode).  Every ACE label begins with the ACE prefix specified in
+   section 5.  The ToASCII and ToUnicode operations are specified in
+   section 4.
+
+   The "ACE prefix" is defined in this document to be a string of ASCII
+   characters that appears at the beginning of every ACE label.  It is
+   specified in section 5.
+
+   A "domain name slot" is defined in this document to be a protocol
+   element or a function argument or a return value (and so on)
+   explicitly designated for carrying a domain name.  Examples of domain
+   name slots include: the QNAME field of a DNS query; the name argument
+   of the gethostbyname() library function; the part of an email address
+   following the at-sign (@) in the From: field of an email message
+   header; and the host portion of the URI in the src attribute of an
+   HTML <IMG> tag.  General text that just happens to contain a domain
+   name is not a domain name slot; for example, a domain name appearing
+   in the plain text body of an email message is not occupying a domain
+   name slot.
+
+   An "IDN-aware domain name slot" is defined in this document to be a
+   domain name slot explicitly designated for carrying an
+   internationalized domain name as defined in this document.  The
+   designation may be static (for example, in the specification of the
+   protocol or interface) or dynamic (for example, as a result of
+   negotiation in an interactive session).
+
+   An "IDN-unaware domain name slot" is defined in this document to be
+   any domain name slot that is not an IDN-aware domain name slot.
+   Obviously, this includes any domain name slot whose specification
+   predates IDNA.
+
+3. Requirements and applicability
+
+3.1 Requirements
+
+   IDNA conformance means adherence to the following four requirements:
+
+   1) Whenever dots are used as label separators, the following
+      characters MUST be recognized as dots: U+002E (full stop), U+3002
+      (ideographic full stop), U+FF0E (fullwidth full stop), U+FF61
+      (halfwidth ideographic full stop).
+
+   2) Whenever a domain name is put into an IDN-unaware domain name slot
+      (see section 2), it MUST contain only ASCII characters.  Given an
+      internationalized domain name (IDN), an equivalent domain name
+      satisfying this requirement can be obtained by applying the
+
+
+
+
+Faltstrom, et al.           Standards Track                     [Page 7]
+
+RFC 3490                          IDNA                        March 2003
+
+
+      ToASCII operation (see section 4) to each label and, if dots are
+      used as label separators, changing all the label separators to
+      U+002E.
+
+   3) ACE labels obtained from domain name slots SHOULD be hidden from
+      users when it is known that the environment can handle the non-ACE
+      form, except when the ACE form is explicitly requested.  When it
+      is not known whether or not the environment can handle the non-ACE
+      form, the application MAY use the non-ACE form (which might fail,
+      such as by not being displayed properly), or it MAY use the ACE
+      form (which will look unintelligle to the user).  Given an
+      internationalized domain name, an equivalent domain name
+      containing no ACE labels can be obtained by applying the ToUnicode
+      operation (see section 4) to each label.  When requirements 2 and
+      3 both apply, requirement 2 takes precedence.
+
+   4) Whenever two labels are compared, they MUST be considered to match
+      if and only if they are equivalent, that is, their ASCII forms
+      (obtained by applying ToASCII) match using a case-insensitive
+      ASCII comparison.  Whenever two names are compared, they MUST be
+      considered to match if and only if their corresponding labels
+      match, regardless of whether the names use the same forms of label
+      separators.
+
+3.2 Applicability
+
+   IDNA is applicable to all domain names in all domain name slots
+   except where it is explicitly excluded.
+
+   This implies that IDNA is applicable to many protocols that predate
+   IDNA.  Note that IDNs occupying domain name slots in those protocols
+   MUST be in ASCII form (see section 3.1, requirement 2).
+
+3.2.1. DNS resource records
+
+   IDNA does not apply to domain names in the NAME and RDATA fields of
+   DNS resource records whose CLASS is not IN.  This exclusion applies
+   to every non-IN class, present and future, except where future
+   standards override this exclusion by explicitly inviting the use of
+   IDNA.
+
+   There are currently no other exclusions on the applicability of IDNA
+   to DNS resource records; it depends entirely on the CLASS, and not on
+   the TYPE.  This will remain true, even as new types are defined,
+   unless there is a compelling reason for a new type to complicate
+   matters by imposing type-specific rules.
+
+
+
+
+
+Faltstrom, et al.           Standards Track                     [Page 8]
+
+RFC 3490                          IDNA                        March 2003
+
+
+3.2.2. Non-domain-name data types stored in domain names
+
+   Although IDNA enables the representation of non-ASCII characters in
+   domain names, that does not imply that IDNA enables the
+   representation of non-ASCII characters in other data types that are
+   stored in domain names.  For example, an email address local part is
+   sometimes stored in a domain label (hostmaster@example.com would be
+   represented as hostmaster.example.com in the RDATA field of an SOA
+   record).  IDNA does not update the existing email standards, which
+   allow only ASCII characters in local parts.  Therefore, unless the
+   email standards are revised to invite the use of IDNA for local
+   parts, a domain label that holds the local part of an email address
+   SHOULD NOT begin with the ACE prefix, and even if it does, it is to
+   be interpreted literally as a local part that happens to begin with
+   the ACE prefix.
+
+4. Conversion operations
+
+   An application converts a domain name put into an IDN-unaware slot or
+   displayed to a user.  This section specifies the steps to perform in
+   the conversion, and the ToASCII and ToUnicode operations.
+
+   The input to ToASCII or ToUnicode is a single label that is a
+   sequence of Unicode code points (remember that all ASCII code points
+   are also Unicode code points).  If a domain name is represented using
+   a character set other than Unicode or US-ASCII, it will first need to
+   be transcoded to Unicode.
+
+   Starting from a whole domain name, the steps that an application
+   takes to do the conversions are:
+
+   1) Decide whether the domain name is a "stored string" or a "query
+      string" as described in [STRINGPREP].  If this conversion follows
+      the "queries" rule from [STRINGPREP], set the flag called
+      "AllowUnassigned".
+
+   2) Split the domain name into individual labels as described in
+      section 3.1.  The labels do not include the separator.
+
+   3) For each label, decide whether or not to enforce the restrictions
+      on ASCII characters in host names [STD3].  (Applications already
+      faced this choice before the introduction of IDNA, and can
+      continue to make the decision the same way they always have; IDNA
+      makes no new recommendations regarding this choice.)  If the
+      restrictions are to be enforced, set the flag called
+      "UseSTD3ASCIIRules" for that label.
+
+
+
+
+
+Faltstrom, et al.           Standards Track                     [Page 9]
+
+RFC 3490                          IDNA                        March 2003
+
+
+   4) Process each label with either the ToASCII or the ToUnicode
+      operation as appropriate.  Typically, you use the ToASCII
+      operation if you are about to put the name into an IDN-unaware
+      slot, and you use the ToUnicode operation if you are displaying
+      the name to a user; section 3.1 gives greater detail on the
+      applicable requirements.
+
+   5) If ToASCII was applied in step 4 and dots are used as label
+      separators, change all the label separators to U+002E (full stop).
+
+   The following two subsections define the ToASCII and ToUnicode
+   operations that are used in step 4.
+
+   This description of the protocol uses specific procedure names, names
+   of flags, and so on, in order to facilitate the specification of the
+   protocol.  These names, as well as the actual steps of the
+   procedures, are not required of an implementation.  In fact, any
+   implementation which has the same external behavior as specified in
+   this document conforms to this specification.
+
+4.1 ToASCII
+
+   The ToASCII operation takes a sequence of Unicode code points that
+   make up one label and transforms it into a sequence of code points in
+   the ASCII range (0..7F).  If ToASCII succeeds, the original sequence
+   and the resulting sequence are equivalent labels.
+
+   It is important to note that the ToASCII operation can fail.  ToASCII
+   fails if any step of it fails.  If any step of the ToASCII operation
+   fails on any label in a domain name, that domain name MUST NOT be
+   used as an internationalized domain name.  The method for dealing
+   with this failure is application-specific.
+
+   The inputs to ToASCII are a sequence of code points, the
+   AllowUnassigned flag, and the UseSTD3ASCIIRules flag.  The output of
+   ToASCII is either a sequence of ASCII code points or a failure
+   condition.
+
+   ToASCII never alters a sequence of code points that are all in the
+   ASCII range to begin with (although it could fail).  Applying the
+   ToASCII operation multiple times has exactly the same effect as
+   applying it just once.
+
+   ToASCII consists of the following steps:
+
+   1. If the sequence contains any code points outside the ASCII range
+      (0..7F) then proceed to step 2, otherwise skip to step 3.
+
+
+
+
+Faltstrom, et al.           Standards Track                    [Page 10]
+
+RFC 3490                          IDNA                        March 2003
+
+
+   2. Perform the steps specified in [NAMEPREP] and fail if there is an
+      error.  The AllowUnassigned flag is used in [NAMEPREP].
+
+   3. If the UseSTD3ASCIIRules flag is set, then perform these checks:
+
+     (a) Verify the absence of non-LDH ASCII code points; that is, the
+         absence of 0..2C, 2E..2F, 3A..40, 5B..60, and 7B..7F.
+
+     (b) Verify the absence of leading and trailing hyphen-minus; that
+         is, the absence of U+002D at the beginning and end of the
+         sequence.
+
+   4. If the sequence contains any code points outside the ASCII range
+      (0..7F) then proceed to step 5, otherwise skip to step 8.
+
+   5. Verify that the sequence does NOT begin with the ACE prefix.
+
+   6. Encode the sequence using the encoding algorithm in [PUNYCODE] and
+      fail if there is an error.
+
+   7. Prepend the ACE prefix.
+
+   8. Verify that the number of code points is in the range 1 to 63
+      inclusive.
+
+4.2 ToUnicode
+
+   The ToUnicode operation takes a sequence of Unicode code points that
+   make up one label and returns a sequence of Unicode code points.  If
+   the input sequence is a label in ACE form, then the result is an
+   equivalent internationalized label that is not in ACE form, otherwise
+   the original sequence is returned unaltered.
+
+   ToUnicode never fails.  If any step fails, then the original input
+   sequence is returned immediately in that step.
+
+   The ToUnicode output never contains more code points than its input.
+   Note that the number of octets needed to represent a sequence of code
+   points depends on the particular character encoding used.
+
+   The inputs to ToUnicode are a sequence of code points, the
+   AllowUnassigned flag, and the UseSTD3ASCIIRules flag.  The output of
+   ToUnicode is always a sequence of Unicode code points.
+
+   1. If all code points in the sequence are in the ASCII range (0..7F)
+      then skip to step 3.
+
+
+
+
+
+Faltstrom, et al.           Standards Track                    [Page 11]
+
+RFC 3490                          IDNA                        March 2003
+
+
+   2. Perform the steps specified in [NAMEPREP] and fail if there is an
+      error.  (If step 3 of ToASCII is also performed here, it will not
+      affect the overall behavior of ToUnicode, but it is not
+      necessary.)  The AllowUnassigned flag is used in [NAMEPREP].
+
+   3. Verify that the sequence begins with the ACE prefix, and save a
+      copy of the sequence.
+
+   4. Remove the ACE prefix.
+
+   5. Decode the sequence using the decoding algorithm in [PUNYCODE] and
+      fail if there is an error.  Save a copy of the result of this
+      step.
+
+   6. Apply ToASCII.
+
+   7. Verify that the result of step 6 matches the saved copy from step
+      3, using a case-insensitive ASCII comparison.
+
+   8. Return the saved copy from step 5.
+
+5. ACE prefix
+
+   The ACE prefix, used in the conversion operations (section 4), is two
+   alphanumeric ASCII characters followed by two hyphen-minuses.  It
+   cannot be any of the prefixes already used in earlier documents,
+   which includes the following: "bl--", "bq--", "dq--", "lq--", "mq--",
+   "ra--", "wq--" and "zq--".  The ToASCII and ToUnicode operations MUST
+   recognize the ACE prefix in a case-insensitive manner.
+
+   The ACE prefix for IDNA is "xn--" or any capitalization thereof.
+
+   This means that an ACE label might be "xn--de-jg4avhby1noc0d", where
+   "de-jg4avhby1noc0d" is the part of the ACE label that is generated by
+   the encoding steps in [PUNYCODE].
+
+   While all ACE labels begin with the ACE prefix, not all labels
+   beginning with the ACE prefix are necessarily ACE labels.  Non-ACE
+   labels that begin with the ACE prefix will confuse users and SHOULD
+   NOT be allowed in DNS zones.
+
+
+
+
+
+
+
+
+
+
+
+Faltstrom, et al.           Standards Track                    [Page 12]
+
+RFC 3490                          IDNA                        March 2003
+
+
+6. Implications for typical applications using DNS
+
+   In IDNA, applications perform the processing needed to input
+   internationalized domain names from users, display internationalized
+   domain names to users, and process the inputs and outputs from DNS
+   and other protocols that carry domain names.
+
+   The components and interfaces between them can be represented
+   pictorially as:
+
+                    +------+
+                    | User |
+                    +------+
+                       ^
+                       | Input and display: local interface methods
+                       | (pen, keyboard, glowing phosphorus, ...)
+   +-------------------|-------------------------------+
+   |                   v                               |
+   |          +-----------------------------+          |
+   |          |        Application          |          |
+   |          |   (ToASCII and ToUnicode    |          |
+   |          |      operations may be      |          |
+   |          |        called here)         |          |
+   |          +-----------------------------+          |
+   |                   ^        ^                      | End system
+   |                   |        |                      |
+   | Call to resolver: |        | Application-specific |
+   |              ACE  |        | protocol:            |
+   |                   v        | ACE unless the       |
+   |           +----------+     | protocol is updated  |
+   |           | Resolver |     | to handle other      |
+   |           +----------+     | encodings            |
+   |                 ^          |                      |
+   +-----------------|----------|----------------------+
+       DNS protocol: |          |
+                 ACE |          |
+                     v          v
+          +-------------+    +---------------------+
+          | DNS servers |    | Application servers |
+          +-------------+    +---------------------+
+
+   The box labeled "Application" is where the application splits a
+   domain name into labels, sets the appropriate flags, and performs the
+   ToASCII and ToUnicode operations.  This is described in section 4.
+
+
+
+
+
+
+
+Faltstrom, et al.           Standards Track                    [Page 13]
+
+RFC 3490                          IDNA                        March 2003
+
+
+6.1 Entry and display in applications
+
+   Applications can accept domain names using any character set or sets
+   desired by the application developer, and can display domain names in
+   any charset.  That is, the IDNA protocol does not affect the
+   interface between users and applications.
+
+   An IDNA-aware application can accept and display internationalized
+   domain names in two formats: the internationalized character set(s)
+   supported by the application, and as an ACE label.  ACE labels that
+   are displayed or input MUST always include the ACE prefix.
+   Applications MAY allow input and display of ACE labels, but are not
+   encouraged to do so except as an interface for special purposes,
+   possibly for debugging, or to cope with display limitations as
+   described in section 6.4..  ACE encoding is opaque and ugly, and
+   should thus only be exposed to users who absolutely need it.  Because
+   name labels encoded as ACE name labels can be rendered either as the
+   encoded ASCII characters or the proper decoded characters, the
+   application MAY have an option for the user to select the preferred
+   method of display; if it does, rendering the ACE SHOULD NOT be the
+   default.
+
+   Domain names are often stored and transported in many places.  For
+   example, they are part of documents such as mail messages and web
+   pages.  They are transported in many parts of many protocols, such as
+   both the control commands and the RFC 2822 body parts of SMTP, and
+   the headers and the body content in HTTP.  It is important to
+   remember that domain names appear both in domain name slots and in
+   the content that is passed over protocols.
+
+   In protocols and document formats that define how to handle
+   specification or negotiation of charsets, labels can be encoded in
+   any charset allowed by the protocol or document format.  If a
+   protocol or document format only allows one charset, the labels MUST
+   be given in that charset.
+
+   In any place where a protocol or document format allows transmission
+   of the characters in internationalized labels, internationalized
+   labels SHOULD be transmitted using whatever character encoding and
+   escape mechanism that the protocol or document format uses at that
+   place.
+
+   All protocols that use domain name slots already have the capacity
+   for handling domain names in the ASCII charset.  Thus, ACE labels
+   (internationalized labels that have been processed with the ToASCII
+   operation) can inherently be handled by those protocols.
+
+
+
+
+
+Faltstrom, et al.           Standards Track                    [Page 14]
+
+RFC 3490                          IDNA                        March 2003
+
+
+6.2 Applications and resolver libraries
+
+   Applications normally use functions in the operating system when they
+   resolve DNS queries.  Those functions in the operating system are
+   often called "the resolver library", and the applications communicate
+   with the resolver libraries through a programming interface (API).
+
+   Because these resolver libraries today expect only domain names in
+   ASCII, applications MUST prepare labels that are passed to the
+   resolver library using the ToASCII operation.  Labels received from
+   the resolver library contain only ASCII characters; internationalized
+   labels that cannot be represented directly in ASCII use the ACE form.
+   ACE labels always include the ACE prefix.
+
+   An operating system might have a set of libraries for performing the
+   ToASCII operation.  The input to such a library might be in one or
+   more charsets that are used in applications (UTF-8 and UTF-16 are
+   likely candidates for almost any operating system, and script-
+   specific charsets are likely for localized operating systems).
+
+   IDNA-aware applications MUST be able to work with both non-
+   internationalized labels (those that conform to [STD13] and [STD3])
+   and internationalized labels.
+
+   It is expected that new versions of the resolver libraries in the
+   future will be able to accept domain names in other charsets than
+   ASCII, and application developers might one day pass not only domain
+   names in Unicode, but also in local script to a new API for the
+   resolver libraries in the operating system.  Thus the ToASCII and
+   ToUnicode operations might be performed inside these new versions of
+   the resolver libraries.
+
+   Domain names passed to resolvers or put into the question section of
+   DNS requests follow the rules for "queries" from [STRINGPREP].
+
+6.3 DNS servers
+
+   Domain names stored in zones follow the rules for "stored strings"
+   from [STRINGPREP].
+
+   For internationalized labels that cannot be represented directly in
+   ASCII, DNS servers MUST use the ACE form produced by the ToASCII
+   operation.  All IDNs served by DNS servers MUST contain only ASCII
+   characters.
+
+   If a signaling system which makes negotiation possible between old
+   and new DNS clients and servers is standardized in the future, the
+   encoding of the query in the DNS protocol itself can be changed from
+
+
+
+Faltstrom, et al.           Standards Track                    [Page 15]
+
+RFC 3490                          IDNA                        March 2003
+
+
+   ACE to something else, such as UTF-8.  The question whether or not
+   this should be used is, however, a separate problem and is not
+   discussed in this memo.
+
+6.4 Avoiding exposing users to the raw ACE encoding
+
+   Any application that might show the user a domain name obtained from
+   a domain name slot, such as from gethostbyaddr or part of a mail
+   header, will need to be updated if it is to prevent users from seeing
+   the ACE.
+
+   If an application decodes an ACE name using ToUnicode but cannot show
+   all of the characters in the decoded name, such as if the name
+   contains characters that the output system cannot display, the
+   application SHOULD show the name in ACE format (which always includes
+   the ACE prefix) instead of displaying the name with the replacement
+   character (U+FFFD).  This is to make it easier for the user to
+   transfer the name correctly to other programs.  Programs that by
+   default show the ACE form when they cannot show all the characters in
+   a name label SHOULD also have a mechanism to show the name that is
+   produced by the ToUnicode operation with as many characters as
+   possible and replacement characters in the positions where characters
+   cannot be displayed.
+
+   The ToUnicode operation does not alter labels that are not valid ACE
+   labels, even if they begin with the ACE prefix.  After ToUnicode has
+   been applied, if a label still begins with the ACE prefix, then it is
+   not a valid ACE label, and is not equivalent to any of the
+   intermediate Unicode strings constructed by ToUnicode.
+
+6.5  DNSSEC authentication of IDN domain names
+
+   DNS Security [RFC2535] is a method for supplying cryptographic
+   verification information along with DNS messages.  Public Key
+   Cryptography is used in conjunction with digital signatures to
+   provide a means for a requester of domain information to authenticate
+   the source of the data.  This ensures that it can be traced back to a
+   trusted source, either directly, or via a chain of trust linking the
+   source of the information to the top of the DNS hierarchy.
+
+   IDNA specifies that all internationalized domain names served by DNS
+   servers that cannot be represented directly in ASCII must use the ACE
+   form produced by the ToASCII operation.  This operation must be
+   performed prior to a zone being signed by the private key for that
+   zone.  Because of this ordering, it is important to recognize that
+   DNSSEC authenticates the ASCII domain name, not the Unicode form or
+
+
+
+
+
+Faltstrom, et al.           Standards Track                    [Page 16]
+
+RFC 3490                          IDNA                        March 2003
+
+
+   the mapping between the Unicode form and the ASCII form.  In the
+   presence of DNSSEC, this is the name that MUST be signed in the zone
+   and MUST be validated against.
+
+   One consequence of this for sites deploying IDNA in the presence of
+   DNSSEC is that any special purpose proxies or forwarders used to
+   transform user input into IDNs must be earlier in the resolution flow
+   than DNSSEC authenticating nameservers for DNSSEC to work.
+
+7. Name server considerations
+
+   Existing DNS servers do not know the IDNA rules for handling non-
+   ASCII forms of IDNs, and therefore need to be shielded from them.
+   All existing channels through which names can enter a DNS server
+   database (for example, master files [STD13] and DNS update messages
+   [RFC2136]) are IDN-unaware because they predate IDNA, and therefore
+   requirement 2 of section 3.1 of this document provides the needed
+   shielding, by ensuring that internationalized domain names entering
+   DNS server databases through such channels have already been
+   converted to their equivalent ASCII forms.
+
+   It is imperative that there be only one ASCII encoding for a
+   particular domain name.  Because of the design of the ToASCII and
+   ToUnicode operations, there are no ACE labels that decode to ASCII
+   labels, and therefore name servers cannot contain multiple ASCII
+   encodings of the same domain name.
+
+   [RFC2181] explicitly allows domain labels to contain octets beyond
+   the ASCII range (0..7F), and this document does not change that.
+   Note, however, that there is no defined interpretation of octets
+   80..FF as characters.  If labels containing these octets are returned
+   to applications, unpredictable behavior could result.  The ASCII form
+   defined by ToASCII is the only standard representation for
+   internationalized labels in the current DNS protocol.
+
+8. Root server considerations
+
+   IDNs are likely to be somewhat longer than current domain names, so
+   the bandwidth needed by the root servers is likely to go up by a
+   small amount.  Also, queries and responses for IDNs will probably be
+   somewhat longer than typical queries today, so more queries and
+   responses may be forced to go to TCP instead of UDP.
+
+
+
+
+
+
+
+
+
+Faltstrom, et al.           Standards Track                    [Page 17]
+
+RFC 3490                          IDNA                        March 2003
+
+
+9. References
+
+9.1 Normative References
+
+   [RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate
+                Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [STRINGPREP] Hoffman, P. and M. Blanchet, "Preparation of
+                Internationalized Strings ("stringprep")", RFC 3454,
+                December 2002.
+
+   [NAMEPREP]   Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep
+                Profile for Internationalized Domain Names (IDN)", RFC
+                3491, March 2003.
+
+   [PUNYCODE]   Costello, A., "Punycode: A Bootstring encoding of
+                Unicode for use with Internationalized Domain Names in
+                Applications (IDNA)", RFC 3492, March 2003.
+
+   [STD3]       Braden, R., "Requirements for Internet Hosts --
+                Communication Layers", STD 3, RFC 1122, and
+                "Requirements for Internet Hosts -- Application and
+                Support", STD 3, RFC 1123, October 1989.
+
+   [STD13]      Mockapetris, P., "Domain names - concepts and
+                facilities", STD 13, RFC 1034 and "Domain names -
+                implementation and specification", STD 13, RFC 1035,
+                November 1987.
+
+9.2 Informative References
+
+   [RFC2535]    Eastlake, D., "Domain Name System Security Extensions",
+                RFC 2535, March 1999.
+
+   [RFC2181]    Elz, R. and R. Bush, "Clarifications to the DNS
+                Specification", RFC 2181, July 1997.
+
+   [UAX9]       Unicode Standard Annex #9, The Bidirectional Algorithm,
+                <http://www.unicode.org/unicode/reports/tr9/>.
+
+   [UNICODE]    The Unicode Consortium. The Unicode Standard, Version
+                3.2.0 is defined by The Unicode Standard, Version 3.0
+                (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5),
+                as amended by the Unicode Standard Annex #27: Unicode
+                3.1 (http://www.unicode.org/reports/tr27/) and by the
+                Unicode Standard Annex #28: Unicode 3.2
+                (http://www.unicode.org/reports/tr28/).
+
+
+
+
+Faltstrom, et al.           Standards Track                    [Page 18]
+
+RFC 3490                          IDNA                        March 2003
+
+
+   [USASCII]    Cerf, V., "ASCII format for Network Interchange", RFC
+                20, October 1969.
+
+10. Security Considerations
+
+   Security on the Internet partly relies on the DNS.  Thus, any change
+   to the characteristics of the DNS can change the security of much of
+   the Internet.
+
+   This memo describes an algorithm which encodes characters that are
+   not valid according to STD3 and STD13 into octet values that are
+   valid.  No security issues such as string length increases or new
+   allowed values are introduced by the encoding process or the use of
+   these encoded values, apart from those introduced by the ACE encoding
+   itself.
+
+   Domain names are used by users to identify and connect to Internet
+   servers.  The security of the Internet is compromised if a user
+   entering a single internationalized name is connected to different
+   servers based on different interpretations of the internationalized
+   domain name.
+
+   When systems use local character sets other than ASCII and Unicode,
+   this specification leaves the the problem of transcoding between the
+   local character set and Unicode up to the application.  If different
+   applications (or different versions of one application) implement
+   different transcoding rules, they could interpret the same name
+   differently and contact different servers.  This problem is not
+   solved by security protocols like TLS that do not take local
+   character sets into account.
+
+   Because this document normatively refers to [NAMEPREP], [PUNYCODE],
+   and [STRINGPREP], it includes the security considerations from those
+   documents as well.
+
+   If or when this specification is updated to use a more recent Unicode
+   normalization table, the new normalization table will need to be
+   compared with the old to spot backwards incompatible changes.  If
+   there are such changes, they will need to be handled somehow, or
+   there will be security as well as operational implications.  Methods
+   to handle the conflicts could include keeping the old normalization,
+   or taking care of the conflicting characters by operational means, or
+   some other method.
+
+   Implementations MUST NOT use more recent normalization tables than
+   the one referenced from this document, even though more recent tables
+   may be provided by operating systems.  If an application is unsure of
+   which version of the normalization tables are in the operating
+
+
+
+Faltstrom, et al.           Standards Track                    [Page 19]
+
+RFC 3490                          IDNA                        March 2003
+
+
+   system, the application needs to include the normalization tables
+   itself.  Using normalization tables other than the one referenced
+   from this specification could have security and operational
+   implications.
+
+   To help prevent confusion between characters that are visually
+   similar, it is suggested that implementations provide visual
+   indications where a domain name contains multiple scripts.  Such
+   mechanisms can also be used to show when a name contains a mixture of
+   simplified and traditional Chinese characters, or to distinguish zero
+   and one from O and l.  DNS zone adminstrators may impose restrictions
+   (subject to the limitations in section 2) that try to minimize
+   homographs.
+
+   Domain names (or portions of them) are sometimes compared against a
+   set of privileged or anti-privileged domains.  In such situations it
+   is especially important that the comparisons be done properly, as
+   specified in section 3.1 requirement 4.  For labels already in ASCII
+   form, the proper comparison reduces to the same case-insensitive
+   ASCII comparison that has always been used for ASCII labels.
+
+   The introduction of IDNA means that any existing labels that start
+   with the ACE prefix and would be altered by ToUnicode will
+   automatically be ACE labels, and will be considered equivalent to
+   non-ASCII labels, whether or not that was the intent of the zone
+   adminstrator or registrant.
+
+11. IANA Considerations
+
+   IANA has assigned the ACE prefix in consultation with the IESG.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Faltstrom, et al.           Standards Track                    [Page 20]
+
+RFC 3490                          IDNA                        March 2003
+
+
+12. Authors' Addresses
+
+   Patrik Faltstrom
+   Cisco Systems
+   Arstaangsvagen 31 J
+   S-117 43 Stockholm  Sweden
+
+   EMail: paf@cisco.com
+
+
+   Paul Hoffman
+   Internet Mail Consortium and VPN Consortium
+   127 Segre Place
+   Santa Cruz, CA  95060  USA
+
+   EMail: phoffman@imc.org
+
+
+   Adam M. Costello
+   University of California, Berkeley
+
+   URL: http://www.nicemice.net/amc/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Faltstrom, et al.           Standards Track                    [Page 21]
+
+RFC 3490                          IDNA                        March 2003
+
+
+13. Full Copyright Statement
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Faltstrom, et al.           Standards Track                    [Page 22]
+
diff --git a/doc/rfc/rfc3491.txt b/doc/rfc/rfc3491.txt
new file mode 100644
index 0000000..dbc86c7
--- /dev/null
+++ b/doc/rfc/rfc3491.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Network Working Group                                         P. Hoffman
+Request for Comments: 3491                                    IMC & VPNC
+Category: Standards Track                                    M. Blanchet
+                                                                Viagenie
+                                                              March 2003
+
+
+                   Nameprep: A Stringprep Profile for
+                  Internationalized Domain Names (IDN)
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+Abstract
+
+   This document describes how to prepare internationalized domain name
+   (IDN) labels in order to increase the likelihood that name input and
+   name comparison work in ways that make sense for typical users
+   throughout the world.  This profile of the stringprep protocol is
+   used as part of a suite of on-the-wire protocols for
+   internationalizing the Domain Name System (DNS).
+
+1. Introduction
+
+   This document specifies processing rules that will allow users to
+   enter internationalized domain names (IDNs) into applications and
+   have the highest chance of getting the content of the strings
+   correct.  It is a profile of stringprep [STRINGPREP].  These
+   processing rules are only intended for internationalized domain
+   names, not for arbitrary text.
+
+   This profile defines the following, as required by [STRINGPREP].
+
+   -  The intended applicability of the profile: internationalized
+      domain names processed by IDNA.
+
+   -  The character repertoire that is the input and output to
+      stringprep:  Unicode 3.2, specified in section 2.
+
+
+
+
+Hoffman & Blanchet          Standards Track                     [Page 1]
+
+RFC 3491                      IDN Nameprep                    March 2003
+
+
+   -  The mappings used: specified in section 3.
+
+   -  The Unicode normalization used: specified in section 4.
+
+   -  The characters that are prohibited as output: specified in section
+      5.
+
+   -  Bidirectional character handling: specified in section 6.
+
+1.1 Interaction of protocol parts
+
+   Nameprep is used by the IDNA [IDNA] protocol for preparing domain
+   names; it is not designed for any other purpose.  It is explicitly
+   not designed for processing arbitrary free text and SHOULD NOT be
+   used for that purpose.  Nameprep is a profile of Stringprep
+   [STRINGPREP].  Implementations of Nameprep MUST fully implement
+   Stringprep.
+
+   Nameprep is used to process domain name labels, not domain names.
+   IDNA calls nameprep for each label in a domain name, not for the
+   whole domain name.
+
+1.2 Terminology
+
+   The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
+   in this document are to be interpreted as described in BCP 14, RFC
+   2119 [RFC2119].
+
+2. Character Repertoire
+
+   This profile uses Unicode 3.2, as defined in [STRINGPREP] Appendix A.
+
+3. Mapping
+
+   This profile specifies mapping using the following tables from
+   [STRINGPREP]:
+
+   Table B.1
+   Table B.2
+
+4. Normalization
+
+   This profile specifies using Unicode normalization form KC, as
+   described in [STRINGPREP].
+
+
+
+
+
+
+
+Hoffman & Blanchet          Standards Track                     [Page 2]
+
+RFC 3491                      IDN Nameprep                    March 2003
+
+
+5. Prohibited Output
+
+   This profile specifies prohibiting using the following tables from
+   [STRINGPREP]:
+
+   Table C.1.2
+   Table C.2.2
+   Table C.3
+   Table C.4
+   Table C.5
+   Table C.6
+   Table C.7
+   Table C.8
+   Table C.9
+
+   IMPORTANT NOTE: This profile MUST be used with the IDNA protocol.
+   The IDNA protocol has additional prohibitions that are checked
+   outside of this profile.
+
+6. Bidirectional characters
+
+   This profile specifies checking bidirectional strings as described in
+   [STRINGPREP] section 6.
+
+7. Unassigned Code Points in Internationalized Domain Names
+
+   If the processing in [IDNA] specifies that a list of unassigned code
+   points be used, the system uses table A.1 from [STRINGPREP] as its
+   list of unassigned code points.
+
+8. References
+
+8.1 Normative References
+
+   [RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate
+                Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [STRINGPREP] Hoffman, P. and M. Blanchet, "Preparation of
+                Internationalized Strings ("stringprep")", RFC 3454,
+                December 2002.
+
+   [IDNA]       Faltstrom, P., Hoffman, P. and A. Costello,
+                "Internationalizing Domain Names in Applications
+                (IDNA)", RFC 3490, March 2003.
+
+
+
+
+
+
+
+Hoffman & Blanchet          Standards Track                     [Page 3]
+
+RFC 3491                      IDN Nameprep                    March 2003
+
+
+8.2 Informative references
+
+   [STD13]      Mockapetris, P., "Domain names - concepts and
+                facilities", STD 13, RFC 1034, and "Domain names -
+                implementation and specification", STD 13, RFC 1035,
+                November 1987.
+
+9. Security Considerations
+
+   The Unicode and ISO/IEC 10646 repertoires have many characters that
+   look similar.  In many cases, users of security protocols might do
+   visual matching, such as when comparing the names of trusted third
+   parties.  Because it is impossible to map similar-looking characters
+   without a great deal of context such as knowing the fonts used,
+   stringprep does nothing to map similar-looking characters together
+   nor to prohibit some characters because they look like others.
+
+   Security on the Internet partly relies on the DNS.  Thus, any change
+   to the characteristics of the DNS can change the security of much of
+   the Internet.
+
+   Domain names are used by users to connect to Internet servers.  The
+   security of the Internet would be compromised if a user entering a
+   single internationalized name could be connected to different servers
+   based on different interpretations of the internationalized domain
+   name.
+
+   Current applications might assume that the characters allowed in
+   domain names will always be the same as they are in [STD13].  This
+   document vastly increases the number of characters available in
+   domain names.  Every program that uses "special" characters in
+   conjunction with domain names may be vulnerable to attack based on
+   the new characters allowed by this specification.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hoffman & Blanchet          Standards Track                     [Page 4]
+
+RFC 3491                      IDN Nameprep                    March 2003
+
+
+10. IANA Considerations
+
+   This is a profile of stringprep.  It has been registered by the IANA
+   in the stringprep profile registry
+   (www.iana.org/assignments/stringprep-profiles).
+
+      Name of this profile:
+         Nameprep
+
+      RFC in which the profile is defined:
+         This document.
+
+      Indicator whether or not this is the newest version of the
+      profile:
+         This is the first version of Nameprep.
+
+11. Acknowledgements
+
+   Many people from the IETF IDN Working Group and the Unicode Technical
+   Committee contributed ideas that went into this document.
+
+   The IDN Nameprep design team made many useful changes to the
+   document.  That team and its advisors include:
+
+      Asmus Freytag
+      Cathy Wissink
+      Francois Yergeau
+      James Seng
+      Marc Blanchet
+      Mark Davis
+      Martin Duerst
+      Patrik Faltstrom
+      Paul Hoffman
+
+   Additional significant improvements were proposed by:
+
+      Jonathan Rosenne
+      Kent Karlsson
+      Scott Hollenbeck
+      Dave Crocker
+      Erik Nordmark
+      Matitiahu Allouche
+
+
+
+
+
+
+
+
+
+Hoffman & Blanchet          Standards Track                     [Page 5]
+
+RFC 3491                      IDN Nameprep                    March 2003
+
+
+12. Authors' Addresses
+
+   Paul Hoffman
+   Internet Mail Consortium and VPN Consortium
+   127 Segre Place
+   Santa Cruz, CA  95060 USA
+
+   EMail: paul.hoffman@imc.org and paul.hoffman@vpnc.org
+
+
+   Marc Blanchet
+   Viagenie inc.
+   2875 boul. Laurier, bur. 300
+   Ste-Foy, Quebec, Canada, G1V 2M2
+
+   EMail: Marc.Blanchet@viagenie.qc.ca
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hoffman & Blanchet          Standards Track                     [Page 6]
+
+RFC 3491                      IDN Nameprep                    March 2003
+
+
+13.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hoffman & Blanchet          Standards Track                     [Page 7]
+
diff --git a/doc/rfc/rfc3492.txt b/doc/rfc/rfc3492.txt
new file mode 100644
index 0000000..e72ad81
--- /dev/null
+++ b/doc/rfc/rfc3492.txt
@@ -0,0 +1,1963 @@
+
+
+
+
+
+
+Network Working Group                                        A. Costello
+Request for Comments: 3492                 Univ. of California, Berkeley
+Category: Standards Track                                     March 2003
+
+
+              Punycode: A Bootstring encoding of Unicode
+       for Internationalized Domain Names in Applications (IDNA)
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+Abstract
+
+   Punycode is a simple and efficient transfer encoding syntax designed
+   for use with Internationalized Domain Names in Applications (IDNA).
+   It uniquely and reversibly transforms a Unicode string into an ASCII
+   string.  ASCII characters in the Unicode string are represented
+   literally, and non-ASCII characters are represented by ASCII
+   characters that are allowed in host name labels (letters, digits, and
+   hyphens).  This document defines a general algorithm called
+   Bootstring that allows a string of basic code points to uniquely
+   represent any string of code points drawn from a larger set.
+   Punycode is an instance of Bootstring that uses particular parameter
+   values specified by this document, appropriate for IDNA.
+
+Table of Contents
+
+   1. Introduction...............................................2
+       1.1 Features..............................................2
+       1.2 Interaction of protocol parts.........................3
+   2. Terminology................................................3
+   3. Bootstring description.....................................4
+       3.1 Basic code point segregation..........................4
+       3.2 Insertion unsort coding...............................4
+       3.3 Generalized variable-length integers..................5
+       3.4 Bias adaptation.......................................7
+   4. Bootstring parameters......................................8
+   5. Parameter values for Punycode..............................8
+   6. Bootstring algorithms......................................9
+
+
+
+Costello                    Standards Track                     [Page 1]
+
+RFC 3492                     IDNA Punycode                    March 2003
+
+
+       6.1 Bias adaptation function.............................10
+       6.2 Decoding procedure...................................11
+       6.3 Encoding procedure...................................12
+       6.4 Overflow handling....................................13
+   7. Punycode examples.........................................14
+       7.1 Sample strings.......................................14
+       7.2 Decoding traces......................................17
+       7.3 Encoding traces......................................19
+   8. Security Considerations...................................20
+   9. References................................................21
+       9.1 Normative References.................................21
+       9.2 Informative References...............................21
+   A. Mixed-case annotation.....................................22
+   B. Disclaimer and license....................................22
+   C. Punycode sample implementation............................23
+   Author's Address.............................................34
+   Full Copyright Statement.....................................35
+
+1. Introduction
+
+   [IDNA] describes an architecture for supporting internationalized
+   domain names.  Labels containing non-ASCII characters can be
+   represented by ACE labels, which begin with a special ACE prefix and
+   contain only ASCII characters.  The remainder of the label after the
+   prefix is a Punycode encoding of a Unicode string satisfying certain
+   constraints.  For the details of the prefix and constraints, see
+   [IDNA] and [NAMEPREP].
+
+   Punycode is an instance of a more general algorithm called
+   Bootstring, which allows strings composed from a small set of "basic"
+   code points to uniquely represent any string of code points drawn
+   from a larger set.  Punycode is Bootstring with particular parameter
+   values appropriate for IDNA.
+
+1.1 Features
+
+   Bootstring has been designed to have the following features:
+
+   *  Completeness:  Every extended string (sequence of arbitrary code
+      points) can be represented by a basic string (sequence of basic
+      code points).  Restrictions on what strings are allowed, and on
+      length, can be imposed by higher layers.
+
+   *  Uniqueness:  There is at most one basic string that represents a
+      given extended string.
+
+   *  Reversibility:  Any extended string mapped to a basic string can
+      be recovered from that basic string.
+
+
+
+Costello                    Standards Track                     [Page 2]
+
+RFC 3492                     IDNA Punycode                    March 2003
+
+
+   *  Efficient encoding:  The ratio of basic string length to extended
+      string length is small.  This is important in the context of
+      domain names because RFC 1034 [RFC1034] restricts the length of a
+      domain label to 63 characters.
+
+   *  Simplicity:  The encoding and decoding algorithms are reasonably
+      simple to implement.  The goals of efficiency and simplicity are
+      at odds; Bootstring aims at a good balance between them.
+
+   *  Readability:  Basic code points appearing in the extended string
+      are represented as themselves in the basic string (although the
+      main purpose is to improve efficiency, not readability).
+
+   Punycode can also support an additional feature that is not used by
+   the ToASCII and ToUnicode operations of [IDNA].  When extended
+   strings are case-folded prior to encoding, the basic string can use
+   mixed case to tell how to convert the folded string into a mixed-case
+   string.  See appendix A "Mixed-case annotation".
+
+1.2 Interaction of protocol parts
+
+   Punycode is used by the IDNA protocol [IDNA] for converting domain
+   labels into ASCII; it is not designed for any other purpose.  It is
+   explicitly not designed for processing arbitrary free text.
+
+2. Terminology
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in BCP 14, RFC 2119
+   [RFC2119].
+
+   A code point is an integral value associated with a character in a
+   coded character set.
+
+   As in the Unicode Standard [UNICODE], Unicode code points are denoted
+   by "U+" followed by four to six hexadecimal digits, while a range of
+   code points is denoted by two hexadecimal numbers separated by "..",
+   with no prefixes.
+
+   The operators div and mod perform integer division; (x div y) is the
+   quotient of x divided by y, discarding the remainder, and (x mod y)
+   is the remainder, so (x div y) * y + (x mod y) == x.  Bootstring uses
+   these operators only with nonnegative operands, so the quotient and
+   remainder are always nonnegative.
+
+   The break statement jumps out of the innermost loop (as in C).
+
+
+
+
+Costello                    Standards Track                     [Page 3]
+
+RFC 3492                     IDNA Punycode                    March 2003
+
+
+   An overflow is an attempt to compute a value that exceeds the maximum
+   value of an integer variable.
+
+3. Bootstring description
+
+   Bootstring represents an arbitrary sequence of code points (the
+   "extended string") as a sequence of basic code points (the "basic
+   string").  This section describes the representation.  Section 6
+   "Bootstring algorithms" presents the algorithms as pseudocode.
+   Sections 7.1 "Decoding traces" and 7.2 "Encoding traces" trace the
+   algorithms for sample inputs.
+
+   The following sections describe the four techniques used in
+   Bootstring.  "Basic code point segregation" is a very simple and
+   efficient encoding for basic code points occurring in the extended
+   string: they are simply copied all at once.  "Insertion unsort
+   coding" encodes the non-basic code points as deltas, and processes
+   the code points in numerical order rather than in order of
+   appearance, which typically results in smaller deltas.  The deltas
+   are represented as "generalized variable-length integers", which use
+   basic code points to represent nonnegative integers.  The parameters
+   of this integer representation are dynamically adjusted using "bias
+   adaptation", to improve efficiency when consecutive deltas have
+   similar magnitudes.
+
+3.1 Basic code point segregation
+
+   All basic code points appearing in the extended string are
+   represented literally at the beginning of the basic string, in their
+   original order, followed by a delimiter if (and only if) the number
+   of basic code points is nonzero.  The delimiter is a particular basic
+   code point, which never appears in the remainder of the basic string.
+   The decoder can therefore find the end of the literal portion (if
+   there is one) by scanning for the last delimiter.
+
+3.2 Insertion unsort coding
+
+   The remainder of the basic string (after the last delimiter if there
+   is one) represents a sequence of nonnegative integral deltas as
+   generalized variable-length integers, described in section 3.3.  The
+   meaning of the deltas is best understood in terms of the decoder.
+
+   The decoder builds the extended string incrementally.  Initially, the
+   extended string is a copy of the literal portion of the basic string
+   (excluding the last delimiter).  The decoder inserts non-basic code
+   points, one for each delta, into the extended string, ultimately
+   arriving at the final decoded string.
+
+
+
+
+Costello                    Standards Track                     [Page 4]
+
+RFC 3492                     IDNA Punycode                    March 2003
+
+
+   At the heart of this process is a state machine with two state
+   variables: an index i and a counter n.  The index i refers to a
+   position in the extended string; it ranges from 0 (the first
+   position) to the current length of the extended string (which refers
+   to a potential position beyond the current end).  If the current
+   state is <n,i>, the next state is <n,i+1> if i is less than the
+   length of the extended string, or <n+1,0> if i equals the length of
+   the extended string.  In other words, each state change causes i to
+   increment, wrapping around to zero if necessary, and n counts the
+   number of wrap-arounds.
+
+   Notice that the state always advances monotonically (there is no way
+   for the decoder to return to an earlier state).  At each state, an
+   insertion is either performed or not performed.  At most one
+   insertion is performed in a given state.  An insertion inserts the
+   value of n at position i in the extended string.  The deltas are a
+   run-length encoding of this sequence of events: they are the lengths
+   of the runs of non-insertion states preceeding the insertion states.
+   Hence, for each delta, the decoder performs delta state changes, then
+   an insertion, and then one more state change.  (An implementation
+   need not perform each state change individually, but can instead use
+   division and remainder calculations to compute the next insertion
+   state directly.)  It is an error if the inserted code point is a
+   basic code point (because basic code points were supposed to be
+   segregated as described in section 3.1).
+
+   The encoder's main task is to derive the sequence of deltas that will
+   cause the decoder to construct the desired string.  It can do this by
+   repeatedly scanning the extended string for the next code point that
+   the decoder would need to insert, and counting the number of state
+   changes the decoder would need to perform, mindful of the fact that
+   the decoder's extended string will include only those code points
+   that have already been inserted.  Section 6.3 "Encoding procedure"
+   gives a precise algorithm.
+
+3.3 Generalized variable-length integers
+
+   In a conventional integer representation the base is the number of
+   distinct symbols for digits, whose values are 0 through base-1.  Let
+   digit_0 denote the least significant digit, digit_1 the next least
+   significant, and so on.  The value represented is the sum over j of
+   digit_j * w(j), where w(j) = base^j is the weight (scale factor) for
+   position j.  For example, in the base 8 integer 437, the digits are
+   7, 3, and 4, and the weights are 1, 8, and 64, so the value is 7 +
+   3*8 + 4*64 = 287.  This representation has two disadvantages:  First,
+   there are multiple encodings of each value (because there can be
+   extra zeros in the most significant positions), which is inconvenient
+
+
+
+
+Costello                    Standards Track                     [Page 5]
+
+RFC 3492                     IDNA Punycode                    March 2003
+
+
+   when unique encodings are needed.  Second, the integer is not self-
+   delimiting, so if multiple integers are concatenated the boundaries
+   between them are lost.
+
+   The generalized variable-length representation solves these two
+   problems.  The digit values are still 0 through base-1, but now the
+   integer is self-delimiting by means of thresholds t(j), each of which
+   is in the range 0 through base-1.  Exactly one digit, the most
+   significant, satisfies digit_j < t(j).  Therefore, if several
+   integers are concatenated, it is easy to separate them, starting with
+   the first if they are little-endian (least significant digit first),
+   or starting with the last if they are big-endian (most significant
+   digit first).  As before, the value is the sum over j of digit_j *
+   w(j), but the weights are different:
+
+      w(0) = 1
+      w(j) = w(j-1) * (base - t(j-1)) for j > 0
+
+   For example, consider the little-endian sequence of base 8 digits
+   734251...  Suppose the thresholds are 2, 3, 5, 5, 5, 5...  This
+   implies that the weights are 1, 1*(8-2) = 6, 6*(8-3) = 30, 30*(8-5) =
+   90, 90*(8-5) = 270, and so on.  7 is not less than 2, and 3 is not
+   less than 3, but 4 is less than 5, so 4 is the last digit.  The value
+   of 734 is 7*1 + 3*6 + 4*30 = 145.  The next integer is 251, with
+   value 2*1 + 5*6 + 1*30 = 62.  Decoding this representation is very
+   similar to decoding a conventional integer:  Start with a current
+   value of N = 0 and a weight w = 1.  Fetch the next digit d and
+   increase N by d * w.  If d is less than the current threshold (t)
+   then stop, otherwise increase w by a factor of (base - t), update t
+   for the next position, and repeat.
+
+   Encoding this representation is similar to encoding a conventional
+   integer:  If N < t then output one digit for N and stop, otherwise
+   output the digit for t + ((N - t) mod (base - t)), then replace N
+   with (N - t) div (base - t), update t for the next position, and
+   repeat.
+
+   For any particular set of values of t(j), there is exactly one
+   generalized variable-length representation of each nonnegative
+   integral value.
+
+   Bootstring uses little-endian ordering so that the deltas can be
+   separated starting with the first.  The t(j) values are defined in
+   terms of the constants base, tmin, and tmax, and a state variable
+   called bias:
+
+      t(j) = base * (j + 1) - bias,
+      clamped to the range tmin through tmax
+
+
+
+Costello                    Standards Track                     [Page 6]
+
+RFC 3492                     IDNA Punycode                    March 2003
+
+
+   The clamping means that if the formula yields a value less than tmin
+   or greater than tmax, then t(j) = tmin or tmax, respectively.  (In
+   the pseudocode in section 6 "Bootstring algorithms", the expression
+   base * (j + 1) is denoted by k for performance reasons.)  These t(j)
+   values cause the representation to favor integers within a particular
+   range determined by the bias.
+
+3.4 Bias adaptation
+
+   After each delta is encoded or decoded, bias is set for the next
+   delta as follows:
+
+   1. Delta is scaled in order to avoid overflow in the next step:
+
+         let delta = delta div 2
+
+      But when this is the very first delta, the divisor is not 2, but
+      instead a constant called damp.  This compensates for the fact
+      that the second delta is usually much smaller than the first.
+
+   2. Delta is increased to compensate for the fact that the next delta
+      will be inserting into a longer string:
+
+         let delta = delta + (delta div numpoints)
+
+      numpoints is the total number of code points encoded/decoded so
+      far (including the one corresponding to this delta itself, and
+      including the basic code points).
+
+   3. Delta is repeatedly divided until it falls within a threshold, to
+      predict the minimum number of digits needed to represent the next
+      delta:
+
+         while delta > ((base - tmin) * tmax) div 2
+         do let delta = delta div (base - tmin)
+
+   4. The bias is set:
+
+         let bias =
+           (base * the number of divisions performed in step 3) +
+           (((base - tmin + 1) * delta) div (delta + skew))
+
+      The motivation for this procedure is that the current delta
+      provides a hint about the likely size of the next delta, and so
+      t(j) is set to tmax for the more significant digits starting with
+      the one expected to be last, tmin for the less significant digits
+      up through the one expected to be third-last, and somewhere
+      between tmin and tmax for the digit expected to be second-last
+
+
+
+Costello                    Standards Track                     [Page 7]
+
+RFC 3492                     IDNA Punycode                    March 2003
+
+
+      (balancing the hope of the expected-last digit being unnecessary
+      against the danger of it being insufficient).
+
+4. Bootstring parameters
+
+   Given a set of basic code points, one needs to be designated as the
+   delimiter.  The base cannot be greater than the number of
+   distinguishable basic code points remaining.  The digit-values in the
+   range 0 through base-1 need to be associated with distinct non-
+   delimiter basic code points.  In some cases multiple code points need
+   to have the same digit-value; for example, uppercase and lowercase
+   versions of the same letter need to be equivalent if basic strings
+   are case-insensitive.
+
+   The initial value of n cannot be greater than the minimum non-basic
+   code point that could appear in extended strings.
+
+   The remaining five parameters (tmin, tmax, skew, damp, and the
+   initial value of bias) need to satisfy the following constraints:
+
+      0 <= tmin <= tmax <= base-1
+      skew >= 1
+      damp >= 2
+      initial_bias mod base <= base - tmin
+
+   Provided the constraints are satisfied, these five parameters affect
+   efficiency but not correctness.  They are best chosen empirically.
+
+   If support for mixed-case annotation is desired (see appendix A),
+   make sure that the code points corresponding to 0 through tmax-1 all
+   have both uppercase and lowercase forms.
+
+5. Parameter values for Punycode
+
+   Punycode uses the following Bootstring parameter values:
+
+      base         = 36
+      tmin         = 1
+      tmax         = 26
+      skew         = 38
+      damp         = 700
+      initial_bias = 72
+      initial_n    = 128 = 0x80
+
+   Although the only restriction Punycode imposes on the input integers
+   is that they be nonnegative, these parameters are especially designed
+   to work well with Unicode [UNICODE] code points, which are integers
+   in the range 0..10FFFF (but not D800..DFFF, which are reserved for
+
+
+
+Costello                    Standards Track                     [Page 8]
+
+RFC 3492                     IDNA Punycode                    March 2003
+
+
+   use by the UTF-16 encoding of Unicode).  The basic code points are
+   the ASCII [ASCII] code points (0..7F), of which U+002D (-) is the
+   delimiter, and some of the others have digit-values as follows:
+
+      code points    digit-values
+      ------------   ----------------------
+      41..5A (A-Z) =  0 to 25, respectively
+      61..7A (a-z) =  0 to 25, respectively
+      30..39 (0-9) = 26 to 35, respectively
+
+   Using hyphen-minus as the delimiter implies that the encoded string
+   can end with a hyphen-minus only if the Unicode string consists
+   entirely of basic code points, but IDNA forbids such strings from
+   being encoded.  The encoded string can begin with a hyphen-minus, but
+   IDNA prepends a prefix.  Therefore IDNA using Punycode conforms to
+   the RFC 952 rule that host name labels neither begin nor end with a
+   hyphen-minus [RFC952].
+
+   A decoder MUST recognize the letters in both uppercase and lowercase
+   forms (including mixtures of both forms).  An encoder SHOULD output
+   only uppercase forms or only lowercase forms, unless it uses mixed-
+   case annotation (see appendix A).
+
+   Presumably most users will not manually write or type encoded strings
+   (as opposed to cutting and pasting them), but those who do will need
+   to be alert to the potential visual ambiguity between the following
+   sets of characters:
+
+      G 6
+      I l 1
+      O 0
+      S 5
+      U V
+      Z 2
+
+   Such ambiguities are usually resolved by context, but in a Punycode
+   encoded string there is no context apparent to humans.
+
+6. Bootstring algorithms
+
+   Some parts of the pseudocode can be omitted if the parameters satisfy
+   certain conditions (for which Punycode qualifies).  These parts are
+   enclosed in {braces}, and notes immediately following the pseudocode
+   explain the conditions under which they can be omitted.
+
+
+
+
+
+
+
+Costello                    Standards Track                     [Page 9]
+
+RFC 3492                     IDNA Punycode                    March 2003
+
+
+   Formally, code points are integers, and hence the pseudocode assumes
+   that arithmetic operations can be performed directly on code points.
+   In some programming languages, explicit conversion between code
+   points and integers might be necessary.
+
+6.1 Bias adaptation function
+
+   function adapt(delta,numpoints,firsttime):
+     if firsttime then let delta = delta div damp
+     else let delta = delta div 2
+     let delta = delta + (delta div numpoints)
+     let k = 0
+     while delta > ((base - tmin) * tmax) div 2 do begin
+       let delta = delta div (base - tmin)
+       let k = k + base
+     end
+     return k + (((base - tmin + 1) * delta) div (delta + skew))
+
+   It does not matter whether the modifications to delta and k inside
+   adapt() affect variables of the same name inside the
+   encoding/decoding procedures, because after calling adapt() the
+   caller does not read those variables before overwriting them.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Costello                    Standards Track                    [Page 10]
+
+RFC 3492                     IDNA Punycode                    March 2003
+
+
+6.2 Decoding procedure
+
+   let n = initial_n
+   let i = 0
+   let bias = initial_bias
+   let output = an empty string indexed from 0
+   consume all code points before the last delimiter (if there is one)
+     and copy them to output, fail on any non-basic code point
+   if more than zero code points were consumed then consume one more
+     (which will be the last delimiter)
+   while the input is not exhausted do begin
+     let oldi = i
+     let w = 1
+     for k = base to infinity in steps of base do begin
+       consume a code point, or fail if there was none to consume
+       let digit = the code point's digit-value, fail if it has none
+       let i = i + digit * w, fail on overflow
+       let t = tmin if k <= bias {+ tmin}, or
+               tmax if k >= bias + tmax, or k - bias otherwise
+       if digit < t then break
+       let w = w * (base - t), fail on overflow
+     end
+     let bias = adapt(i - oldi, length(output) + 1, test oldi is 0?)
+     let n = n + i div (length(output) + 1), fail on overflow
+     let i = i mod (length(output) + 1)
+     {if n is a basic code point then fail}
+     insert n into output at position i
+     increment i
+   end
+
+   The full statement enclosed in braces (checking whether n is a basic
+   code point) can be omitted if initial_n exceeds all basic code points
+   (which is true for Punycode), because n is never less than initial_n.
+
+   In the assignment of t, where t is clamped to the range tmin through
+   tmax, "+ tmin" can always be omitted.  This makes the clamping
+   calculation incorrect when bias < k < bias + tmin, but that cannot
+   happen because of the way bias is computed and because of the
+   constraints on the parameters.
+
+   Because the decoder state can only advance monotonically, and there
+   is only one representation of any delta, there is therefore only one
+   encoded string that can represent a given sequence of integers.  The
+   only error conditions are invalid code points, unexpected end-of-
+   input, overflow, and basic code points encoded using deltas instead
+   of appearing literally.  If the decoder fails on these errors as
+   shown above, then it cannot produce the same output for two distinct
+   inputs.  Without this property it would have been necessary to re-
+
+
+
+Costello                    Standards Track                    [Page 11]
+
+RFC 3492                     IDNA Punycode                    March 2003
+
+
+   encode the output and verify that it matches the input in order to
+   guarantee the uniqueness of the encoding.
+
+6.3 Encoding procedure
+
+   let n = initial_n
+   let delta = 0
+   let bias = initial_bias
+   let h = b = the number of basic code points in the input
+   copy them to the output in order, followed by a delimiter if b > 0
+   {if the input contains a non-basic code point < n then fail}
+   while h < length(input) do begin
+     let m = the minimum {non-basic} code point >= n in the input
+     let delta = delta + (m - n) * (h + 1), fail on overflow
+     let n = m
+     for each code point c in the input (in order) do begin
+       if c < n {or c is basic} then increment delta, fail on overflow
+       if c == n then begin
+         let q = delta
+         for k = base to infinity in steps of base do begin
+           let t = tmin if k <= bias {+ tmin}, or
+                   tmax if k >= bias + tmax, or k - bias otherwise
+           if q < t then break
+           output the code point for digit t + ((q - t) mod (base - t))
+           let q = (q - t) div (base - t)
+         end
+         output the code point for digit q
+         let bias = adapt(delta, h + 1, test h equals b?)
+         let delta = 0
+         increment h
+       end
+     end
+     increment delta and n
+   end
+
+   The full statement enclosed in braces (checking whether the input
+   contains a non-basic code point less than n) can be omitted if all
+   code points less than initial_n are basic code points (which is true
+   for Punycode if code points are unsigned).
+
+   The brace-enclosed conditions "non-basic" and "or c is basic" can be
+   omitted if initial_n exceeds all basic code points (which is true for
+   Punycode), because the code point being tested is never less than
+   initial_n.
+
+   In the assignment of t, where t is clamped to the range tmin through
+   tmax, "+ tmin" can always be omitted.  This makes the clamping
+   calculation incorrect when bias < k < bias + tmin, but that cannot
+
+
+
+Costello                    Standards Track                    [Page 12]
+
+RFC 3492                     IDNA Punycode                    March 2003
+
+
+   happen because of the way bias is computed and because of the
+   constraints on the parameters.
+
+   The checks for overflow are necessary to avoid producing invalid
+   output when the input contains very large values or is very long.
+
+   The increment of delta at the bottom of the outer loop cannot
+   overflow because delta < length(input) before the increment, and
+   length(input) is already assumed to be representable.  The increment
+   of n could overflow, but only if h == length(input), in which case
+   the procedure is finished anyway.
+
+6.4 Overflow handling
+
+   For IDNA, 26-bit unsigned integers are sufficient to handle all valid
+   IDNA labels without overflow, because any string that needed a 27-bit
+   delta would have to exceed either the code point limit (0..10FFFF) or
+   the label length limit (63 characters).  However, overflow handling
+   is necessary because the inputs are not necessarily valid IDNA
+   labels.
+
+   If the programming language does not provide overflow detection, the
+   following technique can be used.  Suppose A, B, and C are
+   representable nonnegative integers and C is nonzero.  Then A + B
+   overflows if and only if B > maxint - A, and A + (B * C) overflows if
+   and only if B > (maxint - A) div C, where maxint is the greatest
+   integer for which maxint + 1 cannot be represented.  Refer to
+   appendix C "Punycode sample implementation" for demonstrations of
+   this technique in the C language.
+
+   The decoding and encoding algorithms shown in sections 6.2 and 6.3
+   handle overflow by detecting it whenever it happens.  Another
+   approach is to enforce limits on the inputs that prevent overflow
+   from happening.  For example, if the encoder were to verify that no
+   input code points exceed M and that the input length does not exceed
+   L, then no delta could ever exceed (M - initial_n) * (L + 1), and
+   hence no overflow could occur if integer variables were capable of
+   representing values that large.  This prevention approach would
+   impose more restrictions on the input than the detection approach
+   does, but might be considered simpler in some programming languages.
+
+   In theory, the decoder could use an analogous approach, limiting the
+   number of digits in a variable-length integer (that is, limiting the
+   number of iterations in the innermost loop).  However, the number of
+   digits that suffice to represent a given delta can sometimes
+   represent much larger deltas (because of the adaptation), and hence
+   this approach would probably need integers wider than 32 bits.
+
+
+
+
+Costello                    Standards Track                    [Page 13]
+
+RFC 3492                     IDNA Punycode                    March 2003
+
+
+   Yet another approach for the decoder is to allow overflow to occur,
+   but to check the final output string by re-encoding it and comparing
+   to the decoder input.  If and only if they do not match (using a
+   case-insensitive ASCII comparison) overflow has occurred.  This
+   delayed-detection approach would not impose any more restrictions on
+   the input than the immediate-detection approach does, and might be
+   considered simpler in some programming languages.
+
+   In fact, if the decoder is used only inside the IDNA ToUnicode
+   operation [IDNA], then it need not check for overflow at all, because
+   ToUnicode performs a higher level re-encoding and comparison, and a
+   mismatch has the same consequence as if the Punycode decoder had
+   failed.
+
+7. Punycode examples
+
+7.1 Sample strings
+
+   In the Punycode encodings below, the ACE prefix is not shown.
+   Backslashes show where line breaks have been inserted in strings too
+   long for one line.
+
+   The first several examples are all translations of the sentence "Why
+   can't they just speak in <language>?" (courtesy of Michael Kaplan's
+   "provincial" page [PROVINCIAL]).  Word breaks and punctuation have
+   been removed, as is often done in domain names.
+
+   (A) Arabic (Egyptian):
+       u+0644 u+064A u+0647 u+0645 u+0627 u+0628 u+062A u+0643 u+0644
+       u+0645 u+0648 u+0634 u+0639 u+0631 u+0628 u+064A u+061F
+       Punycode: egbpdaj6bu4bxfgehfvwxn
+
+   (B) Chinese (simplified):
+       u+4ED6 u+4EEC u+4E3A u+4EC0 u+4E48 u+4E0D u+8BF4 u+4E2D u+6587
+       Punycode: ihqwcrb4cv8a8dqg056pqjye
+
+   (C) Chinese (traditional):
+       u+4ED6 u+5011 u+7232 u+4EC0 u+9EBD u+4E0D u+8AAA u+4E2D u+6587
+       Punycode: ihqwctvzc91f659drss3x8bo0yb
+
+   (D) Czech: Pro<ccaron>prost<ecaron>nemluv<iacute><ccaron>esky
+       U+0050 u+0072 u+006F u+010D u+0070 u+0072 u+006F u+0073 u+0074
+       u+011B u+006E u+0065 u+006D u+006C u+0075 u+0076 u+00ED u+010D
+       u+0065 u+0073 u+006B u+0079
+       Punycode: Proprostnemluvesky-uyb24dma41a
+
+
+
+
+
+
+Costello                    Standards Track                    [Page 14]
+
+RFC 3492                     IDNA Punycode                    March 2003
+
+
+   (E) Hebrew:
+       u+05DC u+05DE u+05D4 u+05D4 u+05DD u+05E4 u+05E9 u+05D5 u+05D8
+       u+05DC u+05D0 u+05DE u+05D3 u+05D1 u+05E8 u+05D9 u+05DD u+05E2
+       u+05D1 u+05E8 u+05D9 u+05EA
+       Punycode: 4dbcagdahymbxekheh6e0a7fei0b
+
+   (F) Hindi (Devanagari):
+       u+092F u+0939 u+0932 u+094B u+0917 u+0939 u+093F u+0928 u+094D
+       u+0926 u+0940 u+0915 u+094D u+092F u+094B u+0902 u+0928 u+0939
+       u+0940 u+0902 u+092C u+094B u+0932 u+0938 u+0915 u+0924 u+0947
+       u+0939 u+0948 u+0902
+       Punycode: i1baa7eci9glrd9b2ae1bj0hfcgg6iyaf8o0a1dig0cd
+
+   (G) Japanese (kanji and hiragana):
+       u+306A u+305C u+307F u+3093 u+306A u+65E5 u+672C u+8A9E u+3092
+       u+8A71 u+3057 u+3066 u+304F u+308C u+306A u+3044 u+306E u+304B
+       Punycode: n8jok5ay5dzabd5bym9f0cm5685rrjetr6pdxa
+
+   (H) Korean (Hangul syllables):
+       u+C138 u+ACC4 u+C758 u+BAA8 u+B4E0 u+C0AC u+B78C u+B4E4 u+C774
+       u+D55C u+AD6D u+C5B4 u+B97C u+C774 u+D574 u+D55C u+B2E4 u+BA74
+       u+C5BC u+B9C8 u+B098 u+C88B u+C744 u+AE4C
+       Punycode: 989aomsvi5e83db1d2a355cv1e0vak1dwrv93d5xbh15a0dt30a5j\
+                 psd879ccm6fea98c
+
+   (I) Russian (Cyrillic):
+       U+043F u+043E u+0447 u+0435 u+043C u+0443 u+0436 u+0435 u+043E
+       u+043D u+0438 u+043D u+0435 u+0433 u+043E u+0432 u+043E u+0440
+       u+044F u+0442 u+043F u+043E u+0440 u+0443 u+0441 u+0441 u+043A
+       u+0438
+       Punycode: b1abfaaepdrnnbgefbaDotcwatmq2g4l
+
+   (J) Spanish: Porqu<eacute>nopuedensimplementehablarenEspa<ntilde>ol
+       U+0050 u+006F u+0072 u+0071 u+0075 u+00E9 u+006E u+006F u+0070
+       u+0075 u+0065 u+0064 u+0065 u+006E u+0073 u+0069 u+006D u+0070
+       u+006C u+0065 u+006D u+0065 u+006E u+0074 u+0065 u+0068 u+0061
+       u+0062 u+006C u+0061 u+0072 u+0065 u+006E U+0045 u+0073 u+0070
+       u+0061 u+00F1 u+006F u+006C
+       Punycode: PorqunopuedensimplementehablarenEspaol-fmd56a
+
+   (K) Vietnamese:
+       T<adotbelow>isaoh<odotbelow>kh<ocirc>ngth<ecirchookabove>ch\
+       <ihookabove>n<oacute>iti<ecircacute>ngVi<ecircdotbelow>t
+       U+0054 u+1EA1 u+0069 u+0073 u+0061 u+006F u+0068 u+1ECD u+006B
+       u+0068 u+00F4 u+006E u+0067 u+0074 u+0068 u+1EC3 u+0063 u+0068
+       u+1EC9 u+006E u+00F3 u+0069 u+0074 u+0069 u+1EBF u+006E u+0067
+       U+0056 u+0069 u+1EC7 u+0074
+       Punycode: TisaohkhngthchnitingVit-kjcr8268qyxafd2f1b9g
+
+
+
+Costello                    Standards Track                    [Page 15]
+
+RFC 3492                     IDNA Punycode                    March 2003
+
+
+   The next several examples are all names of Japanese music artists,
+   song titles, and TV programs, just because the author happens to have
+   them handy (but Japanese is useful for providing examples of single-
+   row text, two-row text, ideographic text, and various mixtures
+   thereof).
+
+   (L) 3<nen>B<gumi><kinpachi><sensei>
+       u+0033 u+5E74 U+0042 u+7D44 u+91D1 u+516B u+5148 u+751F
+       Punycode: 3B-ww4c5e180e575a65lsy2b
+
+   (M) <amuro><namie>-with-SUPER-MONKEYS
+       u+5B89 u+5BA4 u+5948 u+7F8E u+6075 u+002D u+0077 u+0069 u+0074
+       u+0068 u+002D U+0053 U+0055 U+0050 U+0045 U+0052 u+002D U+004D
+       U+004F U+004E U+004B U+0045 U+0059 U+0053
+       Punycode: -with-SUPER-MONKEYS-pc58ag80a8qai00g7n9n
+
+   (N) Hello-Another-Way-<sorezore><no><basho>
+       U+0048 u+0065 u+006C u+006C u+006F u+002D U+0041 u+006E u+006F
+       u+0074 u+0068 u+0065 u+0072 u+002D U+0057 u+0061 u+0079 u+002D
+       u+305D u+308C u+305E u+308C u+306E u+5834 u+6240
+       Punycode: Hello-Another-Way--fc4qua05auwb3674vfr0b
+
+   (O) <hitotsu><yane><no><shita>2
+       u+3072 u+3068 u+3064 u+5C4B u+6839 u+306E u+4E0B u+0032
+       Punycode: 2-u9tlzr9756bt3uc0v
+
+   (P) Maji<de>Koi<suru>5<byou><mae>
+       U+004D u+0061 u+006A u+0069 u+3067 U+004B u+006F u+0069 u+3059
+       u+308B u+0035 u+79D2 u+524D
+       Punycode: MajiKoi5-783gue6qz075azm5e
+
+   (Q) <pafii>de<runba>
+       u+30D1 u+30D5 u+30A3 u+30FC u+0064 u+0065 u+30EB u+30F3 u+30D0
+       Punycode: de-jg4avhby1noc0d
+
+   (R) <sono><supiido><de>
+       u+305D u+306E u+30B9 u+30D4 u+30FC u+30C9 u+3067
+       Punycode: d9juau41awczczp
+
+   The last example is an ASCII string that breaks the existing rules
+   for host name labels.  (It is not a realistic example for IDNA,
+   because IDNA never encodes pure ASCII labels.)
+
+   (S) -> $1.00 <-
+       u+002D u+003E u+0020 u+0024 u+0031 u+002E u+0030 u+0030 u+0020
+       u+003C u+002D
+       Punycode: -> $1.00 <--
+
+
+
+
+Costello                    Standards Track                    [Page 16]
+
+RFC 3492                     IDNA Punycode                    March 2003
+
+
+7.2 Decoding traces
+
+   In the following traces, the evolving state of the decoder is shown
+   as a sequence of hexadecimal values, representing the code points in
+   the extended string.  An asterisk appears just after the most
+   recently inserted code point, indicating both n (the value preceeding
+   the asterisk) and i (the position of the value just after the
+   asterisk).  Other numerical values are decimal.
+
+   Decoding trace of example B from section 7.1:
+
+   n is 128, i is 0, bias is 72
+   input is "ihqwcrb4cv8a8dqg056pqjye"
+   there is no delimiter, so extended string starts empty
+   delta "ihq" decodes to 19853
+   bias becomes 21
+   4E0D *
+   delta "wc" decodes to 64
+   bias becomes 20
+   4E0D 4E2D *
+   delta "rb" decodes to 37
+   bias becomes 13
+   4E3A * 4E0D 4E2D
+   delta "4c" decodes to 56
+   bias becomes 17
+   4E3A 4E48 * 4E0D 4E2D
+   delta "v8a" decodes to 599
+   bias becomes 32
+   4E3A 4EC0 * 4E48 4E0D 4E2D
+   delta "8d" decodes to 130
+   bias becomes 23
+   4ED6 * 4E3A 4EC0 4E48 4E0D 4E2D
+   delta "qg" decodes to 154
+   bias becomes 25
+   4ED6 4EEC * 4E3A 4EC0 4E48 4E0D 4E2D
+   delta "056p" decodes to 46301
+   bias becomes 84
+   4ED6 4EEC 4E3A 4EC0 4E48 4E0D 4E2D 6587 *
+   delta "qjye" decodes to 88531
+   bias becomes 90
+   4ED6 4EEC 4E3A 4EC0 4E48 4E0D 8BF4 * 4E2D 6587
+
+
+
+
+
+
+
+
+
+
+Costello                    Standards Track                    [Page 17]
+
+RFC 3492                     IDNA Punycode                    March 2003
+
+
+   Decoding trace of example L from section 7.1:
+
+   n is 128, i is 0, bias is 72
+   input is "3B-ww4c5e180e575a65lsy2b"
+   literal portion is "3B-", so extended string starts as:
+   0033 0042
+   delta "ww4c" decodes to 62042
+   bias becomes 27
+   0033 0042 5148 *
+   delta "5e" decodes to 139
+   bias becomes 24
+   0033 0042 516B * 5148
+   delta "180e" decodes to 16683
+   bias becomes 67
+   0033 5E74 * 0042 516B 5148
+   delta "575a" decodes to 34821
+   bias becomes 82
+   0033 5E74 0042 516B 5148 751F *
+   delta "65l" decodes to 14592
+   bias becomes 67
+   0033 5E74 0042 7D44 * 516B 5148 751F
+   delta "sy2b" decodes to 42088
+   bias becomes 84
+   0033 5E74 0042 7D44 91D1 * 516B 5148 751F
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Costello                    Standards Track                    [Page 18]
+
+RFC 3492                     IDNA Punycode                    March 2003
+
+
+7.3 Encoding traces
+
+   In the following traces, code point values are hexadecimal, while
+   other numerical values are decimal.
+
+   Encoding trace of example B from section 7.1:
+
+   bias is 72
+   input is:
+   4ED6 4EEC 4E3A 4EC0 4E48 4E0D 8BF4 4E2D 6587
+   there are no basic code points, so no literal portion
+   next code point to insert is 4E0D
+   needed delta is 19853, encodes as "ihq"
+   bias becomes 21
+   next code point to insert is 4E2D
+   needed delta is 64, encodes as "wc"
+   bias becomes 20
+   next code point to insert is 4E3A
+   needed delta is 37, encodes as "rb"
+   bias becomes 13
+   next code point to insert is 4E48
+   needed delta is 56, encodes as "4c"
+   bias becomes 17
+   next code point to insert is 4EC0
+   needed delta is 599, encodes as "v8a"
+   bias becomes 32
+   next code point to insert is 4ED6
+   needed delta is 130, encodes as "8d"
+   bias becomes 23
+   next code point to insert is 4EEC
+   needed delta is 154, encodes as "qg"
+   bias becomes 25
+   next code point to insert is 6587
+   needed delta is 46301, encodes as "056p"
+   bias becomes 84
+   next code point to insert is 8BF4
+   needed delta is 88531, encodes as "qjye"
+   bias becomes 90
+   output is "ihqwcrb4cv8a8dqg056pqjye"
+
+
+
+
+
+
+
+
+
+
+
+
+Costello                    Standards Track                    [Page 19]
+
+RFC 3492                     IDNA Punycode                    March 2003
+
+
+   Encoding trace of example L from section 7.1:
+
+   bias is 72
+   input is:
+   0033 5E74 0042 7D44 91D1 516B 5148 751F
+   basic code points (0033, 0042) are copied to literal portion: "3B-"
+   next code point to insert is 5148
+   needed delta is 62042, encodes as "ww4c"
+   bias becomes 27
+   next code point to insert is 516B
+   needed delta is 139, encodes as "5e"
+   bias becomes 24
+   next code point to insert is 5E74
+   needed delta is 16683, encodes as "180e"
+   bias becomes 67
+   next code point to insert is 751F
+   needed delta is 34821, encodes as "575a"
+   bias becomes 82
+   next code point to insert is 7D44
+   needed delta is 14592, encodes as "65l"
+   bias becomes 67
+   next code point to insert is 91D1
+   needed delta is 42088, encodes as "sy2b"
+   bias becomes 84
+   output is "3B-ww4c5e180e575a65lsy2b"
+
+8. Security Considerations
+
+   Users expect each domain name in DNS to be controlled by a single
+   authority.  If a Unicode string intended for use as a domain label
+   could map to multiple ACE labels, then an internationalized domain
+   name could map to multiple ASCII domain names, each controlled by a
+   different authority, some of which could be spoofs that hijack
+   service requests intended for another.  Therefore Punycode is
+   designed so that each Unicode string has a unique encoding.
+
+   However, there can still be multiple Unicode representations of the
+   "same" text, for various definitions of "same".  This problem is
+   addressed to some extent by the Unicode standard under the topic of
+   canonicalization, and this work is leveraged for domain names by
+   Nameprep [NAMEPREP].
+
+
+
+
+
+
+
+
+
+
+Costello                    Standards Track                    [Page 20]
+
+RFC 3492                     IDNA Punycode                    March 2003
+
+
+9. References
+
+9.1 Normative References
+
+   [RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate
+                Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+9.2 Informative References
+
+   [RFC952]     Harrenstien, K., Stahl, M. and E. Feinler, "DOD Internet
+                Host Table Specification", RFC 952, October 1985.
+
+   [RFC1034]    Mockapetris, P., "Domain Names - Concepts and
+                Facilities", STD 13, RFC 1034, November 1987.
+
+   [IDNA]       Faltstrom, P., Hoffman, P. and A. Costello,
+                "Internationalizing Domain Names in Applications
+                (IDNA)", RFC 3490, March 2003.
+
+   [NAMEPREP]   Hoffman, P. and  M. Blanchet, "Nameprep: A Stringprep
+                Profile for Internationalized Domain Names (IDN)", RFC
+                3491, March 2003.
+
+   [ASCII]      Cerf, V., "ASCII format for Network Interchange", RFC
+                20, October 1969.
+
+   [PROVINCIAL] Kaplan, M., "The 'anyone can be provincial!' page",
+                http://www.trigeminal.com/samples/provincial.html.
+
+   [UNICODE]    The Unicode Consortium, "The Unicode Standard",
+                http://www.unicode.org/unicode/standard/standard.html.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Costello                    Standards Track                    [Page 21]
+
+RFC 3492                     IDNA Punycode                    March 2003
+
+
+A. Mixed-case annotation
+
+   In order to use Punycode to represent case-insensitive strings,
+   higher layers need to case-fold the strings prior to Punycode
+   encoding.  The encoded string can use mixed case as an annotation
+   telling how to convert the folded string into a mixed-case string for
+   display purposes.  Note, however, that mixed-case annotation is not
+   used by the ToASCII and ToUnicode operations specified in [IDNA], and
+   therefore implementors of IDNA can disregard this appendix.
+
+   Basic code points can use mixed case directly, because the decoder
+   copies them verbatim, leaving lowercase code points lowercase, and
+   leaving uppercase code points uppercase.  Each non-basic code point
+   is represented by a delta, which is represented by a sequence of
+   basic code points, the last of which provides the annotation.  If it
+   is uppercase, it is a suggestion to map the non-basic code point to
+   uppercase (if possible); if it is lowercase, it is a suggestion to
+   map the non-basic code point to lowercase (if possible).
+
+   These annotations do not alter the code points returned by decoders;
+   the annotations are returned separately, for the caller to use or
+   ignore.  Encoders can accept annotations in addition to code points,
+   but the annotations do not alter the output, except to influence the
+   uppercase/lowercase form of ASCII letters.
+
+   Punycode encoders and decoders need not support these annotations,
+   and higher layers need not use them.
+
+B. Disclaimer and license
+
+   Regarding this entire document or any portion of it (including the
+   pseudocode and C code), the author makes no guarantees and is not
+   responsible for any damage resulting from its use.  The author grants
+   irrevocable permission to anyone to use, modify, and distribute it in
+   any way that does not diminish the rights of anyone else to use,
+   modify, and distribute it, provided that redistributed derivative
+   works do not contain misleading author or version information.
+   Derivative works need not be licensed under similar terms.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Costello                    Standards Track                    [Page 22]
+
+RFC 3492                     IDNA Punycode                    March 2003
+
+
+C. Punycode sample implementation
+
+/*
+punycode.c from RFC 3492
+http://www.nicemice.net/idn/
+Adam M. Costello
+http://www.nicemice.net/amc/
+
+This is ANSI C code (C89) implementing Punycode (RFC 3492).
+
+*/
+
+
+/************************************************************/
+/* Public interface (would normally go in its own .h file): */
+
+#include <limits.h>
+
+enum punycode_status {
+  punycode_success,
+  punycode_bad_input,   /* Input is invalid.                       */
+  punycode_big_output,  /* Output would exceed the space provided. */
+  punycode_overflow     /* Input needs wider integers to process.  */
+};
+
+#if UINT_MAX >= (1 << 26) - 1
+typedef unsigned int punycode_uint;
+#else
+typedef unsigned long punycode_uint;
+#endif
+
+enum punycode_status punycode_encode(
+  punycode_uint input_length,
+  const punycode_uint input[],
+  const unsigned char case_flags[],
+  punycode_uint *output_length,
+  char output[] );
+
+    /* punycode_encode() converts Unicode to Punycode.  The input     */
+    /* is represented as an array of Unicode code points (not code    */
+    /* units; surrogate pairs are not allowed), and the output        */
+    /* will be represented as an array of ASCII code points.  The     */
+    /* output string is *not* null-terminated; it will contain        */
+    /* zeros if and only if the input contains zeros.  (Of course     */
+    /* the caller can leave room for a terminator and add one if      */
+    /* needed.)  The input_length is the number of code points in     */
+    /* the input.  The output_length is an in/out argument: the       */
+    /* caller passes in the maximum number of code points that it     */
+
+
+
+Costello                    Standards Track                    [Page 23]
+
+RFC 3492                     IDNA Punycode                    March 2003
+
+
+    /* can receive, and on successful return it will contain the      */
+    /* number of code points actually output.  The case_flags array   */
+    /* holds input_length boolean values, where nonzero suggests that */
+    /* the corresponding Unicode character be forced to uppercase     */
+    /* after being decoded (if possible), and zero suggests that      */
+    /* it be forced to lowercase (if possible).  ASCII code points    */
+    /* are encoded literally, except that ASCII letters are forced    */
+    /* to uppercase or lowercase according to the corresponding       */
+    /* uppercase flags.  If case_flags is a null pointer then ASCII   */
+    /* letters are left as they are, and other code points are        */
+    /* treated as if their uppercase flags were zero.  The return     */
+    /* value can be any of the punycode_status values defined above   */
+    /* except punycode_bad_input; if not punycode_success, then       */
+    /* output_size and output might contain garbage.                  */
+
+enum punycode_status punycode_decode(
+  punycode_uint input_length,
+  const char input[],
+  punycode_uint *output_length,
+  punycode_uint output[],
+  unsigned char case_flags[] );
+
+    /* punycode_decode() converts Punycode to Unicode.  The input is  */
+    /* represented as an array of ASCII code points, and the output   */
+    /* will be represented as an array of Unicode code points.  The   */
+    /* input_length is the number of code points in the input.  The   */
+    /* output_length is an in/out argument: the caller passes in      */
+    /* the maximum number of code points that it can receive, and     */
+    /* on successful return it will contain the actual number of      */
+    /* code points output.  The case_flags array needs room for at    */
+    /* least output_length values, or it can be a null pointer if the */
+    /* case information is not needed.  A nonzero flag suggests that  */
+    /* the corresponding Unicode character be forced to uppercase     */
+    /* by the caller (if possible), while zero suggests that it be    */
+    /* forced to lowercase (if possible).  ASCII code points are      */
+    /* output already in the proper case, but their flags will be set */
+    /* appropriately so that applying the flags would be harmless.    */
+    /* The return value can be any of the punycode_status values      */
+    /* defined above; if not punycode_success, then output_length,    */
+    /* output, and case_flags might contain garbage.  On success, the */
+    /* decoder will never need to write an output_length greater than */
+    /* input_length, because of how the encoding is defined.          */
+
+/**********************************************************/
+/* Implementation (would normally go in its own .c file): */
+
+#include <string.h>
+
+
+
+
+Costello                    Standards Track                    [Page 24]
+
+RFC 3492                     IDNA Punycode                    March 2003
+
+
+/*** Bootstring parameters for Punycode ***/
+
+enum { base = 36, tmin = 1, tmax = 26, skew = 38, damp = 700,
+       initial_bias = 72, initial_n = 0x80, delimiter = 0x2D };
+
+/* basic(cp) tests whether cp is a basic code point: */
+#define basic(cp) ((punycode_uint)(cp) < 0x80)
+
+/* delim(cp) tests whether cp is a delimiter: */
+#define delim(cp) ((cp) == delimiter)
+
+/* decode_digit(cp) returns the numeric value of a basic code */
+/* point (for use in representing integers) in the range 0 to */
+/* base-1, or base if cp is does not represent a value.       */
+
+static punycode_uint decode_digit(punycode_uint cp)
+{
+  return  cp - 48 < 10 ? cp - 22 :  cp - 65 < 26 ? cp - 65 :
+          cp - 97 < 26 ? cp - 97 :  base;
+}
+
+/* encode_digit(d,flag) returns the basic code point whose value      */
+/* (when used for representing integers) is d, which needs to be in   */
+/* the range 0 to base-1.  The lowercase form is used unless flag is  */
+/* nonzero, in which case the uppercase form is used.  The behavior   */
+/* is undefined if flag is nonzero and digit d has no uppercase form. */
+
+static char encode_digit(punycode_uint d, int flag)
+{
+  return d + 22 + 75 * (d < 26) - ((flag != 0) << 5);
+  /*  0..25 map to ASCII a..z or A..Z */
+  /* 26..35 map to ASCII 0..9         */
+}
+
+/* flagged(bcp) tests whether a basic code point is flagged */
+/* (uppercase).  The behavior is undefined if bcp is not a  */
+/* basic code point.                                        */
+
+#define flagged(bcp) ((punycode_uint)(bcp) - 65 < 26)
+
+/* encode_basic(bcp,flag) forces a basic code point to lowercase */
+/* if flag is zero, uppercase if flag is nonzero, and returns    */
+/* the resulting code point.  The code point is unchanged if it  */
+/* is caseless.  The behavior is undefined if bcp is not a basic */
+/* code point.                                                   */
+
+static char encode_basic(punycode_uint bcp, int flag)
+{
+
+
+
+Costello                    Standards Track                    [Page 25]
+
+RFC 3492                     IDNA Punycode                    March 2003
+
+
+  bcp -= (bcp - 97 < 26) << 5;
+  return bcp + ((!flag && (bcp - 65 < 26)) << 5);
+}
+
+/*** Platform-specific constants ***/
+
+/* maxint is the maximum value of a punycode_uint variable: */
+static const punycode_uint maxint = -1;
+/* Because maxint is unsigned, -1 becomes the maximum value. */
+
+/*** Bias adaptation function ***/
+
+static punycode_uint adapt(
+  punycode_uint delta, punycode_uint numpoints, int firsttime )
+{
+  punycode_uint k;
+
+  delta = firsttime ? delta / damp : delta >> 1;
+  /* delta >> 1 is a faster way of doing delta / 2 */
+  delta += delta / numpoints;
+
+  for (k = 0;  delta > ((base - tmin) * tmax) / 2;  k += base) {
+    delta /= base - tmin;
+  }
+
+  return k + (base - tmin + 1) * delta / (delta + skew);
+}
+
+/*** Main encode function ***/
+
+enum punycode_status punycode_encode(
+  punycode_uint input_length,
+  const punycode_uint input[],
+  const unsigned char case_flags[],
+  punycode_uint *output_length,
+  char output[] )
+{
+  punycode_uint n, delta, h, b, out, max_out, bias, j, m, q, k, t;
+
+  /* Initialize the state: */
+
+  n = initial_n;
+  delta = out = 0;
+  max_out = *output_length;
+  bias = initial_bias;
+
+  /* Handle the basic code points: */
+
+
+
+
+Costello                    Standards Track                    [Page 26]
+
+RFC 3492                     IDNA Punycode                    March 2003
+
+
+  for (j = 0;  j < input_length;  ++j) {
+    if (basic(input[j])) {
+      if (max_out - out < 2) return punycode_big_output;
+      output[out++] =
+        case_flags ?  encode_basic(input[j], case_flags[j]) : input[j];
+    }
+    /* else if (input[j] < n) return punycode_bad_input; */
+    /* (not needed for Punycode with unsigned code points) */
+  }
+
+  h = b = out;
+
+  /* h is the number of code points that have been handled, b is the  */
+  /* number of basic code points, and out is the number of characters */
+  /* that have been output.                                           */
+
+  if (b > 0) output[out++] = delimiter;
+
+  /* Main encoding loop: */
+
+  while (h < input_length) {
+    /* All non-basic code points < n have been     */
+    /* handled already.  Find the next larger one: */
+
+    for (m = maxint, j = 0;  j < input_length;  ++j) {
+      /* if (basic(input[j])) continue; */
+      /* (not needed for Punycode) */
+      if (input[j] >= n && input[j] < m) m = input[j];
+    }
+
+    /* Increase delta enough to advance the decoder's    */
+    /* <n,i> state to <m,0>, but guard against overflow: */
+
+    if (m - n > (maxint - delta) / (h + 1)) return punycode_overflow;
+    delta += (m - n) * (h + 1);
+    n = m;
+
+    for (j = 0;  j < input_length;  ++j) {
+      /* Punycode does not need to check whether input[j] is basic: */
+      if (input[j] < n /* || basic(input[j]) */ ) {
+        if (++delta == 0) return punycode_overflow;
+      }
+
+      if (input[j] == n) {
+        /* Represent delta as a generalized variable-length integer: */
+
+        for (q = delta, k = base;  ;  k += base) {
+          if (out >= max_out) return punycode_big_output;
+
+
+
+Costello                    Standards Track                    [Page 27]
+
+RFC 3492                     IDNA Punycode                    March 2003
+
+
+          t = k <= bias /* + tmin */ ? tmin :     /* +tmin not needed */
+              k >= bias + tmax ? tmax : k - bias;
+          if (q < t) break;
+          output[out++] = encode_digit(t + (q - t) % (base - t), 0);
+          q = (q - t) / (base - t);
+        }
+
+        output[out++] = encode_digit(q, case_flags && case_flags[j]);
+        bias = adapt(delta, h + 1, h == b);
+        delta = 0;
+        ++h;
+      }
+    }
+
+    ++delta, ++n;
+  }
+
+  *output_length = out;
+  return punycode_success;
+}
+
+/*** Main decode function ***/
+
+enum punycode_status punycode_decode(
+  punycode_uint input_length,
+  const char input[],
+  punycode_uint *output_length,
+  punycode_uint output[],
+  unsigned char case_flags[] )
+{
+  punycode_uint n, out, i, max_out, bias,
+                 b, j, in, oldi, w, k, digit, t;
+
+  /* Initialize the state: */
+
+  n = initial_n;
+  out = i = 0;
+  max_out = *output_length;
+  bias = initial_bias;
+
+  /* Handle the basic code points:  Let b be the number of input code */
+  /* points before the last delimiter, or 0 if there is none, then    */
+  /* copy the first b code points to the output.                      */
+
+  for (b = j = 0;  j < input_length;  ++j) if (delim(input[j])) b = j;
+  if (b > max_out) return punycode_big_output;
+
+  for (j = 0;  j < b;  ++j) {
+
+
+
+Costello                    Standards Track                    [Page 28]
+
+RFC 3492                     IDNA Punycode                    March 2003
+
+
+    if (case_flags) case_flags[out] = flagged(input[j]);
+    if (!basic(input[j])) return punycode_bad_input;
+    output[out++] = input[j];
+  }
+
+  /* Main decoding loop:  Start just after the last delimiter if any  */
+  /* basic code points were copied; start at the beginning otherwise. */
+
+  for (in = b > 0 ? b + 1 : 0;  in < input_length;  ++out) {
+
+    /* in is the index of the next character to be consumed, and */
+    /* out is the number of code points in the output array.     */
+
+    /* Decode a generalized variable-length integer into delta,  */
+    /* which gets added to i.  The overflow checking is easier   */
+    /* if we increase i as we go, then subtract off its starting */
+    /* value at the end to obtain delta.                         */
+
+    for (oldi = i, w = 1, k = base;  ;  k += base) {
+      if (in >= input_length) return punycode_bad_input;
+      digit = decode_digit(input[in++]);
+      if (digit >= base) return punycode_bad_input;
+      if (digit > (maxint - i) / w) return punycode_overflow;
+      i += digit * w;
+      t = k <= bias /* + tmin */ ? tmin :     /* +tmin not needed */
+          k >= bias + tmax ? tmax : k - bias;
+      if (digit < t) break;
+      if (w > maxint / (base - t)) return punycode_overflow;
+      w *= (base - t);
+    }
+
+    bias = adapt(i - oldi, out + 1, oldi == 0);
+
+    /* i was supposed to wrap around from out+1 to 0,   */
+    /* incrementing n each time, so we'll fix that now: */
+
+    if (i / (out + 1) > maxint - n) return punycode_overflow;
+    n += i / (out + 1);
+    i %= (out + 1);
+
+    /* Insert n at position i of the output: */
+
+    /* not needed for Punycode: */
+    /* if (decode_digit(n) <= base) return punycode_invalid_input; */
+    if (out >= max_out) return punycode_big_output;
+
+    if (case_flags) {
+      memmove(case_flags + i + 1, case_flags + i, out - i);
+
+
+
+Costello                    Standards Track                    [Page 29]
+
+RFC 3492                     IDNA Punycode                    March 2003
+
+
+      /* Case of last character determines uppercase flag: */
+      case_flags[i] = flagged(input[in - 1]);
+    }
+
+    memmove(output + i + 1, output + i, (out - i) * sizeof *output);
+    output[i++] = n;
+  }
+
+  *output_length = out;
+  return punycode_success;
+}
+
+/******************************************************************/
+/* Wrapper for testing (would normally go in a separate .c file): */
+
+#include <assert.h>
+#include <stdio.h>
+#include <stdlib.h>
+#include <string.h>
+
+/* For testing, we'll just set some compile-time limits rather than */
+/* use malloc(), and set a compile-time option rather than using a  */
+/* command-line option.                                             */
+
+enum {
+  unicode_max_length = 256,
+  ace_max_length = 256
+};
+
+static void usage(char **argv)
+{
+  fprintf(stderr,
+    "\n"
+    "%s -e reads code points and writes a Punycode string.\n"
+    "%s -d reads a Punycode string and writes code points.\n"
+    "\n"
+    "Input and output are plain text in the native character set.\n"
+    "Code points are in the form u+hex separated by whitespace.\n"
+    "Although the specification allows Punycode strings to contain\n"
+    "any characters from the ASCII repertoire, this test code\n"
+    "supports only the printable characters, and needs the Punycode\n"
+    "string to be followed by a newline.\n"
+    "The case of the u in u+hex is the force-to-uppercase flag.\n"
+    , argv[0], argv[0]);
+  exit(EXIT_FAILURE);
+}
+
+static void fail(const char *msg)
+
+
+
+Costello                    Standards Track                    [Page 30]
+
+RFC 3492                     IDNA Punycode                    March 2003
+
+
+{
+  fputs(msg,stderr);
+  exit(EXIT_FAILURE);
+}
+
+static const char too_big[] =
+  "input or output is too large, recompile with larger limits\n";
+static const char invalid_input[] = "invalid input\n";
+static const char overflow[] = "arithmetic overflow\n";
+static const char io_error[] = "I/O error\n";
+
+/* The following string is used to convert printable */
+/* characters between ASCII and the native charset:  */
+
+static const char print_ascii[] =
+  "\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n"
+  "\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n"
+  " !\"#$%&'()*+,-./"
+  "0123456789:;<=>?"
+  "@ABCDEFGHIJKLMNO"
+  "PQRSTUVWXYZ[\\]^_"
+  "`abcdefghijklmno"
+  "pqrstuvwxyz{|}~\n";
+
+int main(int argc, char **argv)
+{
+  enum punycode_status status;
+  int r;
+  unsigned int input_length, output_length, j;
+  unsigned char case_flags[unicode_max_length];
+
+  if (argc != 2) usage(argv);
+  if (argv[1][0] != '-') usage(argv);
+  if (argv[1][2] != 0) usage(argv);
+
+  if (argv[1][1] == 'e') {
+    punycode_uint input[unicode_max_length];
+    unsigned long codept;
+    char output[ace_max_length+1], uplus[3];
+    int c;
+
+    /* Read the input code points: */
+
+    input_length = 0;
+
+    for (;;) {
+      r = scanf("%2s%lx", uplus, &codept);
+      if (ferror(stdin)) fail(io_error);
+
+
+
+Costello                    Standards Track                    [Page 31]
+
+RFC 3492                     IDNA Punycode                    March 2003
+
+
+      if (r == EOF || r == 0) break;
+
+      if (r != 2 || uplus[1] != '+' || codept > (punycode_uint)-1) {
+        fail(invalid_input);
+      }
+
+      if (input_length == unicode_max_length) fail(too_big);
+
+      if (uplus[0] == 'u') case_flags[input_length] = 0;
+      else if (uplus[0] == 'U') case_flags[input_length] = 1;
+      else fail(invalid_input);
+
+      input[input_length++] = codept;
+    }
+
+    /* Encode: */
+
+    output_length = ace_max_length;
+    status = punycode_encode(input_length, input, case_flags,
+                             &output_length, output);
+    if (status == punycode_bad_input) fail(invalid_input);
+    if (status == punycode_big_output) fail(too_big);
+    if (status == punycode_overflow) fail(overflow);
+    assert(status == punycode_success);
+
+    /* Convert to native charset and output: */
+
+    for (j = 0;  j < output_length;  ++j) {
+      c = output[j];
+      assert(c >= 0 && c <= 127);
+      if (print_ascii[c] == 0) fail(invalid_input);
+      output[j] = print_ascii[c];
+    }
+
+    output[j] = 0;
+    r = puts(output);
+    if (r == EOF) fail(io_error);
+    return EXIT_SUCCESS;
+  }
+
+  if (argv[1][1] == 'd') {
+    char input[ace_max_length+2], *p, *pp;
+    punycode_uint output[unicode_max_length];
+
+    /* Read the Punycode input string and convert to ASCII: */
+
+    fgets(input, ace_max_length+2, stdin);
+    if (ferror(stdin)) fail(io_error);
+
+
+
+Costello                    Standards Track                    [Page 32]
+
+RFC 3492                     IDNA Punycode                    March 2003
+
+
+    if (feof(stdin)) fail(invalid_input);
+    input_length = strlen(input) - 1;
+    if (input[input_length] != '\n') fail(too_big);
+    input[input_length] = 0;
+
+    for (p = input;  *p != 0;  ++p) {
+      pp = strchr(print_ascii, *p);
+      if (pp == 0) fail(invalid_input);
+      *p = pp - print_ascii;
+    }
+
+    /* Decode: */
+
+    output_length = unicode_max_length;
+    status = punycode_decode(input_length, input, &output_length,
+                             output, case_flags);
+    if (status == punycode_bad_input) fail(invalid_input);
+    if (status == punycode_big_output) fail(too_big);
+    if (status == punycode_overflow) fail(overflow);
+    assert(status == punycode_success);
+
+    /* Output the result: */
+
+    for (j = 0;  j < output_length;  ++j) {
+      r = printf("%s+%04lX\n",
+                 case_flags[j] ? "U" : "u",
+                 (unsigned long) output[j] );
+      if (r < 0) fail(io_error);
+    }
+
+    return EXIT_SUCCESS;
+  }
+
+  usage(argv);
+  return EXIT_SUCCESS;  /* not reached, but quiets compiler warning */
+}
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Costello                    Standards Track                    [Page 33]
+
+RFC 3492                     IDNA Punycode                    March 2003
+
+
+Author's Address
+
+   Adam M. Costello
+   University of California, Berkeley
+   http://www.nicemice.net/amc/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Costello                    Standards Track                    [Page 34]
+
+RFC 3492                     IDNA Punycode                    March 2003
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Costello                    Standards Track                    [Page 35]
+
diff --git a/doc/rfc/rfc3493.txt b/doc/rfc/rfc3493.txt
new file mode 100644
index 0000000..5fea6c1
--- /dev/null
+++ b/doc/rfc/rfc3493.txt
@@ -0,0 +1,2187 @@
+
+
+
+
+
+
+Network Working Group                                        R. Gilligan
+Request for Comments: 3493                                Intransa, Inc.
+Obsoletes: 2553                                               S. Thomson
+Category: Informational                                            Cisco
+                                                                J. Bound
+                                                               J. McCann
+                                                         Hewlett-Packard
+                                                              W. Stevens
+                                                           February 2003
+
+
+               Basic Socket Interface Extensions for IPv6
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+Abstract
+
+   The de facto standard Application Program Interface (API) for TCP/IP
+   applications is the "sockets" interface.  Although this API was
+   developed for Unix in the early 1980s it has also been implemented on
+   a wide variety of non-Unix systems.  TCP/IP applications written
+   using the sockets API have in the past enjoyed a high degree of
+   portability and we would like the same portability with IPv6
+   applications.  But changes are required to the sockets API to support
+   IPv6 and this memo describes these changes.  These include a new
+   socket address structure to carry IPv6 addresses, new address
+   conversion functions, and some new socket options.  These extensions
+   are designed to provide access to the basic IPv6 features required by
+   TCP and UDP applications, including multicasting, while introducing a
+   minimum of change into the system and providing complete
+   compatibility for existing IPv4 applications.  Additional extensions
+   for advanced IPv6 features (raw sockets and access to the IPv6
+   extension headers) are defined in another document.
+
+
+
+
+
+
+
+
+
+
+Gilligan, et al.             Informational                      [Page 1]
+
+RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
+
+
+Table of Contents
+
+   1.  Introduction................................................3
+   2.  Design Considerations.......................................4
+       2.1  What Needs to be Changed...............................4
+       2.2  Data Types.............................................6
+       2.3  Headers................................................6
+       2.4  Structures.............................................6
+   3.  Socket Interface............................................6
+       3.1  IPv6 Address Family and Protocol Family................6
+       3.2  IPv6 Address Structure.................................7
+       3.3  Socket Address Structure for 4.3BSD-Based Systems......7
+       3.4  Socket Address Structure for 4.4BSD-Based Systems......9
+       3.5  The Socket Functions...................................9
+       3.6  Compatibility with IPv4 Applications..................10
+       3.7  Compatibility with IPv4 Nodes.........................11
+       3.8  IPv6 Wildcard Address.................................11
+       3.9  IPv6 Loopback Address.................................13
+       3.10 Portability Additions.................................14
+   4.  Interface Identification...................................16
+       4.1  Name-to-Index.........................................17
+       4.2  Index-to-Name.........................................17
+       4.3  Return All Interface Names and Indexes................18
+       4.4  Free Memory...........................................18
+   5.  Socket Options.............................................18
+       5.1  Unicast Hop Limit.....................................19
+       5.2  Sending and Receiving Multicast Packets...............19
+       5.3  IPV6_V6ONLY option for AF_INET6 Sockets...............22
+   6.  Library Functions..........................................22
+       6.1  Protocol-Independent Nodename and
+            Service Name Translation..............................23
+       6.2  Socket Address Structure to Node Name
+            and Service Name......................................28
+       6.3  Address Conversion Functions..........................31
+       6.4  Address Testing Macros................................33
+   7.  Summary of New Definitions.................................33
+   8.  Security Considerations....................................35
+   9.  Changes from RFC 2553......................................35
+   10. Acknowledgments............................................36
+   11. References.................................................37
+   12. Authors' Addresses.........................................38
+   13. Full Copyright Statement...................................39
+
+
+
+
+
+
+
+
+
+Gilligan, et al.             Informational                      [Page 2]
+
+RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
+
+
+1. Introduction
+
+   While IPv4 addresses are 32 bits long, IPv6 addresses are 128 bits
+   long.  The socket interface makes the size of an IP address quite
+   visible to an application; virtually all TCP/IP applications for
+   BSD-based systems have knowledge of the size of an IP address.  Those
+   parts of the API that expose the addresses must be changed to
+   accommodate the larger IPv6 address size.  IPv6 also introduces new
+   features, some of which must be made visible to applications via the
+   API.  This memo defines a set of extensions to the socket interface
+   to support the larger address size and new features of IPv6.  It
+   defines "basic" extensions that are of use to a broad range of
+   applications.  A companion document, the "advanced" API [4], covers
+   extensions that are of use to more specialized applications, examples
+   of which include routing daemons, and the "ping" and "traceroute"
+   utilities.
+
+   The development of this API was started in 1994 in the IETF IPng
+   working group.  The API has evolved over the years, published first
+   in RFC 2133, then again in RFC 2553, and reaching its final form in
+   this document.
+
+   As the API matured and stabilized, it was incorporated into the Open
+   Group's Networking Services (XNS) specification, issue 5.2, which was
+   subsequently incorporated into a joint Open Group/IEEE/ISO standard
+   [3].
+
+   Effort has been made to ensure that this document and [3] contain the
+   same information with regard to the API definitions.  However, the
+   reader should note that this document is for informational purposes
+   only, and that the official standard specification of the sockets API
+   is [3].
+
+   It is expected that any future standardization work on this API would
+   be done by the Open Group Base Working Group [6].
+
+   It should also be noted that this document describes only those
+   portions of the API needed for IPv4 and IPv6 communications.  Other
+   potential uses of the API, for example the use of getaddrinfo() and
+   getnameinfo() with the AF_UNIX address family, are beyond the scope
+   of this document.
+
+
+
+
+
+
+
+
+
+
+Gilligan, et al.             Informational                      [Page 3]
+
+RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
+
+
+2. Design Considerations
+
+   There are a number of important considerations in designing changes
+   to this well-worn API:
+
+   -  The API changes should provide both source and binary
+      compatibility for programs written to the original API.  That is,
+      existing program binaries should continue to operate when run on a
+      system supporting the new API.  In addition, existing applications
+      that are re-compiled and run on a system supporting the new API
+      should continue to operate.  Simply put, the API changes for IPv6
+      should not break existing programs.  An additional mechanism for
+      implementations to verify this is to verify the new symbols are
+      protected by Feature Test Macros as described in [3].  (Such
+      Feature Test Macros are not defined by this RFC.)
+
+   -  The changes to the API should be as small as possible in order to
+      simplify the task of converting existing IPv4 applications to
+      IPv6.
+
+   -  Where possible, applications should be able to use this API to
+      interoperate with both IPv6 and IPv4 hosts.  Applications should
+      not need to know which type of host they are communicating with.
+
+   -  IPv6 addresses carried in data structures should be 64-bit
+      aligned.  This is necessary in order to obtain optimum performance
+      on 64-bit machine architectures.
+
+   Because of the importance of providing IPv4 compatibility in the API,
+   these extensions are explicitly designed to operate on machines that
+   provide complete support for both IPv4 and IPv6.  A subset of this
+   API could probably be designed for operation on systems that support
+   only IPv6.  However, this is not addressed in this memo.
+
+2.1 What Needs to be Changed
+
+   The socket interface API consists of a few distinct components:
+
+   -  Core socket functions.
+
+   -  Address data structures.
+
+   -  Name-to-address translation functions.
+
+   -  Address conversion functions.
+
+
+
+
+
+
+Gilligan, et al.             Informational                      [Page 4]
+
+RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
+
+
+   The core socket functions -- those functions that deal with such
+   things as setting up and tearing down TCP connections, and sending
+   and receiving UDP packets -- were designed to be transport
+   independent.  Where protocol addresses are passed as function
+   arguments, they are carried via opaque pointers.  A protocol-specific
+   address data structure is defined for each protocol that the socket
+   functions support.  Applications must cast pointers to these
+   protocol-specific address structures into pointers to the generic
+   "sockaddr" address structure when using the socket functions.  These
+   functions need not change for IPv6, but a new IPv6-specific address
+   data structure is needed.
+
+   The "sockaddr_in" structure is the protocol-specific data structure
+   for IPv4.  This data structure actually includes 8-octets of unused
+   space, and it is tempting to try to use this space to adapt the
+   sockaddr_in structure to IPv6.  Unfortunately, the sockaddr_in
+   structure is not large enough to hold the 16-octet IPv6 address as
+   well as the other information (address family and port number) that
+   is needed.  So a new address data structure must be defined for IPv6.
+
+   IPv6 addresses are scoped [2] so they could be link-local, site,
+   organization, global, or other scopes at this time undefined.  To
+   support applications that want to be able to identify a set of
+   interfaces for a specific scope, the IPv6 sockaddr_in structure must
+   support a field that can be used by an implementation to identify a
+   set of interfaces identifying the scope for an IPv6 address.
+
+   The IPv4 name-to-address translation functions in the socket
+   interface are gethostbyname() and gethostbyaddr().  These are left as
+   is, and new functions are defined which support both IPv4 and IPv6.
+
+   The IPv4 address conversion functions -- inet_ntoa() and inet_addr()
+   -- convert IPv4 addresses between binary and printable form.  These
+   functions are quite specific to 32-bit IPv4 addresses.  We have
+   designed two analogous functions that convert both IPv4 and IPv6
+   addresses, and carry an address type parameter so that they can be
+   extended to other protocol families as well.
+
+   Finally, a few miscellaneous features are needed to support IPv6.  A
+   new interface is needed to support the IPv6 hop limit header field.
+   New socket options are needed to control the sending and receiving of
+   IPv6 multicast packets.
+
+   The socket interface will be enhanced in the future to provide access
+   to other IPv6 features.  Some of these extensions are described in
+   [4].
+
+
+
+
+
+Gilligan, et al.             Informational                      [Page 5]
+
+RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
+
+
+2.2 Data Types
+
+   The data types of the structure elements given in this memo are
+   intended to track the relevant standards.  uintN_t means an unsigned
+   integer of exactly N bits (e.g., uint16_t).  The sa_family_t and
+   in_port_t types are defined in [3].
+
+2.3 Headers
+
+   When function prototypes and structures are shown we show the headers
+   that must be #included to cause that item to be defined.
+
+2.4 Structures
+
+   When structures are described the members shown are the ones that
+   must appear in an implementation.  Additional, nonstandard members
+   may also be defined by an implementation.  As an additional
+   precaution nonstandard members could be verified by Feature Test
+   Macros as described in [3].  (Such Feature Test Macros are not
+   defined by this RFC.)
+
+   The ordering shown for the members of a structure is the recommended
+   ordering, given alignment considerations of multibyte members, but an
+   implementation may order the members differently.
+
+3. Socket Interface
+
+   This section specifies the socket interface changes for IPv6.
+
+3.1 IPv6 Address Family and Protocol Family
+
+   A new address family name, AF_INET6, is defined in <sys/socket.h>.
+   The AF_INET6 definition distinguishes between the original
+   sockaddr_in address data structure, and the new sockaddr_in6 data
+   structure.
+
+   A new protocol family name, PF_INET6, is defined in <sys/socket.h>.
+   Like most of the other protocol family names, this will usually be
+   defined to have the same value as the corresponding address family
+   name:
+
+      #define PF_INET6        AF_INET6
+
+   The AF_INET6 is used in the first argument to the socket() function
+   to indicate that an IPv6 socket is being created.
+
+
+
+
+
+
+Gilligan, et al.             Informational                      [Page 6]
+
+RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
+
+
+3.2 IPv6 Address Structure
+
+   A new in6_addr structure holds a single IPv6 address and is defined
+   as a result of including <netinet/in.h>:
+
+      struct in6_addr {
+          uint8_t  s6_addr[16];      /* IPv6 address */
+      };
+
+   This data structure contains an array of sixteen 8-bit elements,
+   which make up one 128-bit IPv6 address.  The IPv6 address is stored
+   in network byte order.
+
+   The structure in6_addr above is usually implemented with an embedded
+   union with extra fields that force the desired alignment level in a
+   manner similar to BSD implementations of "struct in_addr".  Those
+   additional implementation details are omitted here for simplicity.
+
+   An example is as follows:
+
+   struct in6_addr {
+        union {
+            uint8_t  _S6_u8[16];
+            uint32_t _S6_u32[4];
+            uint64_t _S6_u64[2];
+        } _S6_un;
+   };
+   #define s6_addr _S6_un._S6_u8
+
+3.3 Socket Address Structure for 4.3BSD-Based Systems
+
+   In the socket interface, a different protocol-specific data structure
+   is defined to carry the addresses for each protocol suite.  Each
+   protocol-specific data structure is designed so it can be cast into a
+   protocol-independent data structure -- the "sockaddr" structure.
+   Each has a "family" field that overlays the "sa_family" of the
+   sockaddr data structure.  This field identifies the type of the data
+   structure.
+
+   The sockaddr_in structure is the protocol-specific address data
+   structure for IPv4.  It is used to pass addresses between
+   applications and the system in the socket functions.  The following
+   sockaddr_in6 structure holds IPv6 addresses and is defined as a
+   result of including the <netinet/in.h> header:
+
+
+
+
+
+
+
+Gilligan, et al.             Informational                      [Page 7]
+
+RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
+
+
+struct sockaddr_in6 {
+    sa_family_t     sin6_family;    /* AF_INET6 */
+    in_port_t       sin6_port;      /* transport layer port # */
+    uint32_t        sin6_flowinfo;  /* IPv6 flow information */
+    struct in6_addr sin6_addr;      /* IPv6 address */
+    uint32_t        sin6_scope_id;  /* set of interfaces for a scope */
+};
+
+   This structure is designed to be compatible with the sockaddr data
+   structure used in the 4.3BSD release.
+
+   The sin6_family field identifies this as a sockaddr_in6 structure.
+   This field overlays the sa_family field when the buffer is cast to a
+   sockaddr data structure.  The value of this field must be AF_INET6.
+
+   The sin6_port field contains the 16-bit UDP or TCP port number.  This
+   field is used in the same way as the sin_port field of the
+   sockaddr_in structure.  The port number is stored in network byte
+   order.
+
+   The sin6_flowinfo field is a 32-bit field intended to contain flow-
+   related information.  The exact way this field is mapped to or from a
+   packet is not currently specified.  Until such time as its use is
+   specified, applications should set this field to zero when
+   constructing a sockaddr_in6, and ignore this field in a sockaddr_in6
+   structure constructed by the system.
+
+   The sin6_addr field is a single in6_addr structure (defined in the
+   previous section).  This field holds one 128-bit IPv6 address.  The
+   address is stored in network byte order.
+
+   The ordering of elements in this structure is specifically designed
+   so that when sin6_addr field is aligned on a 64-bit boundary, the
+   start of the structure will also be aligned on a 64-bit boundary.
+   This is done for optimum performance on 64-bit architectures.
+
+   The sin6_scope_id field is a 32-bit integer that identifies a set of
+   interfaces as appropriate for the scope [2] of the address carried in
+   the sin6_addr field.  The mapping of sin6_scope_id to an interface or
+   set of interfaces is left to implementation and future specifications
+   on the subject of scoped addresses.
+
+   Notice that the sockaddr_in6 structure will normally be larger than
+   the generic sockaddr structure.  On many existing implementations the
+   sizeof(struct sockaddr_in) equals sizeof(struct sockaddr), with both
+   being 16 bytes.  Any existing code that makes this assumption needs
+   to be examined carefully when converting to IPv6.
+
+
+
+
+Gilligan, et al.             Informational                      [Page 8]
+
+RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
+
+
+3.4 Socket Address Structure for 4.4BSD-Based Systems
+
+   The 4.4BSD release includes a small, but incompatible change to the
+   socket interface.  The "sa_family" field of the sockaddr data
+   structure was changed from a 16-bit value to an 8-bit value, and the
+   space saved used to hold a length field, named "sa_len".  The
+   sockaddr_in6 data structure given in the previous section cannot be
+   correctly cast into the newer sockaddr data structure.  For this
+   reason, the following alternative IPv6 address data structure is
+   provided to be used on systems based on 4.4BSD.  It is defined as a
+   result of including the <netinet/in.h> header.
+
+struct sockaddr_in6 {
+    uint8_t         sin6_len;       /* length of this struct */
+    sa_family_t     sin6_family;    /* AF_INET6 */
+    in_port_t       sin6_port;      /* transport layer port # */
+    uint32_t        sin6_flowinfo;  /* IPv6 flow information */
+    struct in6_addr sin6_addr;      /* IPv6 address */
+    uint32_t        sin6_scope_id;  /* set of interfaces for a scope */
+};
+
+   The only differences between this data structure and the 4.3BSD
+   variant are the inclusion of the length field, and the change of the
+   family field to a 8-bit data type.  The definitions of all the other
+   fields are identical to the structure defined in the previous
+   section.
+
+   Systems that provide this version of the sockaddr_in6 data structure
+   must also declare SIN6_LEN as a result of including the
+   <netinet/in.h> header.  This macro allows applications to determine
+   whether they are being built on a system that supports the 4.3BSD or
+   4.4BSD variants of the data structure.
+
+3.5 The Socket Functions
+
+   Applications call the socket() function to create a socket descriptor
+   that represents a communication endpoint.  The arguments to the
+   socket() function tell the system which protocol to use, and what
+   format address structure will be used in subsequent functions.  For
+   example, to create an IPv4/TCP socket, applications make the call:
+
+      s = socket(AF_INET, SOCK_STREAM, 0);
+
+   To create an IPv4/UDP socket, applications make the call:
+
+      s = socket(AF_INET, SOCK_DGRAM, 0);
+
+
+
+
+
+Gilligan, et al.             Informational                      [Page 9]
+
+RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
+
+
+   Applications may create IPv6/TCP and IPv6/UDP sockets (which may also
+   handle IPv4 communication as described in section 3.7) by simply
+   using the constant AF_INET6 instead of AF_INET in the first argument.
+   For example, to create an IPv6/TCP socket, applications make the
+   call:
+
+      s = socket(AF_INET6, SOCK_STREAM, 0);
+
+   To create an IPv6/UDP socket, applications make the call:
+
+      s = socket(AF_INET6, SOCK_DGRAM, 0);
+
+   Once the application has created a AF_INET6 socket, it must use the
+   sockaddr_in6 address structure when passing addresses in to the
+   system.  The functions that the application uses to pass addresses
+   into the system are:
+
+      bind()
+      connect()
+      sendmsg()
+      sendto()
+
+   The system will use the sockaddr_in6 address structure to return
+   addresses to applications that are using AF_INET6 sockets.  The
+   functions that return an address from the system to an application
+   are:
+
+      accept()
+      recvfrom()
+      recvmsg()
+      getpeername()
+      getsockname()
+
+   No changes to the syntax of the socket functions are needed to
+   support IPv6, since all of the "address carrying" functions use an
+   opaque address pointer, and carry an address length as a function
+   argument.
+
+3.6 Compatibility with IPv4 Applications
+
+   In order to support the large base of applications using the original
+   API, system implementations must provide complete source and binary
+   compatibility with the original API.  This means that systems must
+   continue to support AF_INET sockets and the sockaddr_in address
+   structure.  Applications must be able to create IPv4/TCP and IPv4/UDP
+   sockets using the AF_INET constant in the socket() function, as
+
+
+
+
+
+Gilligan, et al.             Informational                     [Page 10]
+
+RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
+
+
+   described in the previous section.  Applications should be able to
+   hold a combination of IPv4/TCP, IPv4/UDP, IPv6/TCP and IPv6/UDP
+   sockets simultaneously within the same process.
+
+   Applications using the original API should continue to operate as
+   they did on systems supporting only IPv4.  That is, they should
+   continue to interoperate with IPv4 nodes.
+
+3.7 Compatibility with IPv4 Nodes
+
+   The API also provides a different type of compatibility: the ability
+   for IPv6 applications to interoperate with IPv4 applications.  This
+   feature uses the IPv4-mapped IPv6 address format defined in the IPv6
+   addressing architecture specification [2].  This address format
+   allows the IPv4 address of an IPv4 node to be represented as an IPv6
+   address.  The IPv4 address is encoded into the low-order 32 bits of
+   the IPv6 address, and the high-order 96 bits hold the fixed prefix
+   0:0:0:0:0:FFFF.  IPv4-mapped addresses are written as follows:
+
+      ::FFFF:<IPv4-address>
+
+   These addresses can be generated automatically by the getaddrinfo()
+   function, as described in Section 6.1.
+
+   Applications may use AF_INET6 sockets to open TCP connections to IPv4
+   nodes, or send UDP packets to IPv4 nodes, by simply encoding the
+   destination's IPv4 address as an IPv4-mapped IPv6 address, and
+   passing that address, within a sockaddr_in6 structure, in the
+   connect() or sendto() call.  When applications use AF_INET6 sockets
+   to accept TCP connections from IPv4 nodes, or receive UDP packets
+   from IPv4 nodes, the system returns the peer's address to the
+   application in the accept(), recvfrom(), or getpeername() call using
+   a sockaddr_in6 structure encoded this way.
+
+   Few applications will likely need to know which type of node they are
+   interoperating with.  However, for those applications that do need to
+   know, the IN6_IS_ADDR_V4MAPPED() macro, defined in Section 6.4, is
+   provided.
+
+3.8 IPv6 Wildcard Address
+
+   While the bind() function allows applications to select the source IP
+   address of UDP packets and TCP connections, applications often want
+   the system to select the source address for them.  With IPv4, one
+   specifies the address as the symbolic constant INADDR_ANY (called the
+   "wildcard" address) in the bind() call, or simply omits the bind()
+   entirely.
+
+
+
+
+Gilligan, et al.             Informational                     [Page 11]
+
+RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
+
+
+   Since the IPv6 address type is a structure (struct in6_addr), a
+   symbolic constant can be used to initialize an IPv6 address variable,
+   but cannot be used in an assignment.  Therefore systems provide the
+   IPv6 wildcard address in two forms.
+
+   The first version is a global variable named "in6addr_any" that is an
+   in6_addr structure.  The extern declaration for this variable is
+   defined in <netinet/in.h>:
+
+      extern const struct in6_addr in6addr_any;
+
+   Applications use in6addr_any similarly to the way they use INADDR_ANY
+   in IPv4.  For example, to bind a socket to port number 23, but let
+   the system select the source address, an application could use the
+   following code:
+
+      struct sockaddr_in6 sin6;
+       . . .
+      sin6.sin6_family = AF_INET6;
+      sin6.sin6_flowinfo = 0;
+      sin6.sin6_port = htons(23);
+      sin6.sin6_addr = in6addr_any;  /* structure assignment */
+       . . .
+      if (bind(s, (struct sockaddr *) &sin6, sizeof(sin6)) == -1)
+              . . .
+
+   The other version is a symbolic constant named IN6ADDR_ANY_INIT and
+   is defined in <netinet/in.h>.  This constant can be used to
+   initialize an in6_addr structure:
+
+      struct in6_addr anyaddr = IN6ADDR_ANY_INIT;
+
+   Note that this constant can be used ONLY at declaration time.  It can
+   not be used to assign a previously declared in6_addr structure.  For
+   example, the following code will not work:
+
+      /* This is the WRONG way to assign an unspecified address */
+      struct sockaddr_in6 sin6;
+       . . .
+      sin6.sin6_addr = IN6ADDR_ANY_INIT; /* will NOT compile */
+
+   Be aware that the IPv4 INADDR_xxx constants are all defined in host
+   byte order but the IPv6 IN6ADDR_xxx constants and the IPv6
+   in6addr_xxx externals are defined in network byte order.
+
+
+
+
+
+
+
+Gilligan, et al.             Informational                     [Page 12]
+
+RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
+
+
+3.9 IPv6 Loopback Address
+
+   Applications may need to send UDP packets to, or originate TCP
+   connections to, services residing on the local node.  In IPv4, they
+   can do this by using the constant IPv4 address INADDR_LOOPBACK in
+   their connect(), sendto(), or sendmsg() call.
+
+   IPv6 also provides a loopback address to contact local TCP and UDP
+   services.  Like the unspecified address, the IPv6 loopback address is
+   provided in two forms -- a global variable and a symbolic constant.
+
+   The global variable is an in6_addr structure named
+   "in6addr_loopback."  The extern declaration for this variable is
+   defined in <netinet/in.h>:
+
+      extern const struct in6_addr in6addr_loopback;
+
+   Applications use in6addr_loopback as they would use INADDR_LOOPBACK
+   in IPv4 applications (but beware of the byte ordering difference
+   mentioned at the end of the previous section).  For example, to open
+   a TCP connection to the local telnet server, an application could use
+   the following code:
+
+   struct sockaddr_in6 sin6;
+    . . .
+   sin6.sin6_family = AF_INET6;
+   sin6.sin6_flowinfo = 0;
+   sin6.sin6_port = htons(23);
+   sin6.sin6_addr = in6addr_loopback;  /* structure assignment */
+    . . .
+   if (connect(s, (struct sockaddr *) &sin6, sizeof(sin6)) == -1)
+           . . .
+
+   The symbolic constant is named IN6ADDR_LOOPBACK_INIT and is defined
+   in <netinet/in.h>.  It can be used at declaration time ONLY; for
+   example:
+
+      struct in6_addr loopbackaddr = IN6ADDR_LOOPBACK_INIT;
+
+   Like IN6ADDR_ANY_INIT, this constant cannot be used in an assignment
+   to a previously declared IPv6 address variable.
+
+
+
+
+
+
+
+
+
+
+Gilligan, et al.             Informational                     [Page 13]
+
+RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
+
+
+3.10 Portability Additions
+
+   One simple addition to the sockets API that can help application
+   writers is the "struct sockaddr_storage".  This data structure can
+   simplify writing code that is portable across multiple address
+   families and platforms.  This data structure is designed with the
+   following goals.
+
+   - Large enough to accommodate all supported protocol-specific address
+      structures.
+
+   - Aligned at an appropriate boundary so that pointers to it can be
+      cast as pointers to protocol specific address structures and used
+      to access the fields of those structures without alignment
+      problems.
+
+   The sockaddr_storage structure contains field ss_family which is of
+   type sa_family_t.  When a sockaddr_storage structure is cast to a
+   sockaddr structure, the ss_family field of the sockaddr_storage
+   structure maps onto the sa_family field of the sockaddr structure.
+   When a sockaddr_storage structure is cast as a protocol specific
+   address structure, the ss_family field maps onto a field of that
+   structure that is of type sa_family_t and that identifies the
+   protocol's address family.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gilligan, et al.             Informational                     [Page 14]
+
+RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
+
+
+   An example implementation design of such a data structure would be as
+   follows.
+
+/*
+ * Desired design of maximum size and alignment
+ */
+#define _SS_MAXSIZE    128  /* Implementation specific max size */
+#define _SS_ALIGNSIZE  (sizeof (int64_t))
+                         /* Implementation specific desired alignment */
+/*
+ * Definitions used for sockaddr_storage structure paddings design.
+ */
+#define _SS_PAD1SIZE   (_SS_ALIGNSIZE - sizeof (sa_family_t))
+#define _SS_PAD2SIZE   (_SS_MAXSIZE - (sizeof (sa_family_t) +
+                              _SS_PAD1SIZE + _SS_ALIGNSIZE))
+struct sockaddr_storage {
+    sa_family_t  ss_family;     /* address family */
+    /* Following fields are implementation specific */
+    char      __ss_pad1[_SS_PAD1SIZE];
+              /* 6 byte pad, this is to make implementation
+              /* specific pad up to alignment field that */
+              /* follows explicit in the data structure */
+    int64_t   __ss_align;     /* field to force desired structure */
+               /* storage alignment */
+    char      __ss_pad2[_SS_PAD2SIZE];
+              /* 112 byte pad to achieve desired size, */
+              /* _SS_MAXSIZE value minus size of ss_family */
+              /* __ss_pad1, __ss_align fields is 112 */
+};
+
+   The above example implementation illustrates a data structure which
+   will align on a 64-bit boundary.  An implementation-specific field
+   "__ss_align" along with "__ss_pad1" is used to force a 64-bit
+   alignment which covers proper alignment good enough for the needs of
+   sockaddr_in6 (IPv6), sockaddr_in (IPv4) address data structures.  The
+   size of padding field __ss_pad1 depends on the chosen alignment
+   boundary.  The size of padding field __ss_pad2 depends on the value
+   of overall size chosen for the total size of the structure.  This
+   size and alignment are represented in the above example by
+   implementation specific (not required) constants _SS_MAXSIZE (chosen
+   value 128) and _SS_ALIGNSIZE (with chosen value 8).  Constants
+   _SS_PAD1SIZE (derived value 6) and _SS_PAD2SIZE (derived value 112)
+   are also for illustration and not required.  The derived values
+   assume sa_family_t is 2 bytes.  The implementation specific
+   definitions and structure field names above start with an underscore
+   to denote implementation private namespace.  Portable code is not
+   expected to access or reference those fields or constants.
+
+
+
+
+Gilligan, et al.             Informational                     [Page 15]
+
+RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
+
+
+   On implementations where the sockaddr data structure includes a
+   "sa_len" field this data structure would look like this:
+
+/*
+ * Definitions used for sockaddr_storage structure paddings design.
+ */
+#define _SS_PAD1SIZE (_SS_ALIGNSIZE -
+                            (sizeof (uint8_t) + sizeof (sa_family_t))
+#define _SS_PAD2SIZE (_SS_MAXSIZE -
+                            (sizeof (uint8_t) + sizeof (sa_family_t) +
+                             _SS_PAD1SIZE + _SS_ALIGNSIZE))
+struct sockaddr_storage {
+    uint8_t      ss_len;        /* address length */
+    sa_family_t  ss_family;     /* address family */
+    /* Following fields are implementation specific */
+    char         __ss_pad1[_SS_PAD1SIZE];
+                  /* 6 byte pad, this is to make implementation
+                  /* specific pad up to alignment field that */
+                  /* follows explicit in the data structure */
+    int64_t      __ss_align;  /* field to force desired structure */
+                  /* storage alignment */
+    char         __ss_pad2[_SS_PAD2SIZE];
+                  /* 112 byte pad to achieve desired size, */
+                  /* _SS_MAXSIZE value minus size of ss_len, */
+                  /* __ss_family, __ss_pad1, __ss_align fields is 112 */
+};
+
+4. Interface Identification
+
+   This API uses an interface index (a small positive integer) to
+   identify the local interface on which a multicast group is joined
+   (Section 5.2).  Additionally, the advanced API [4] uses these same
+   interface indexes to identify the interface on which a datagram is
+   received, or to specify the interface on which a datagram is to be
+   sent.
+
+   Interfaces are normally known by names such as "le0", "sl1", "ppp2",
+   and the like.  On Berkeley-derived implementations, when an interface
+   is made known to the system, the kernel assigns a unique positive
+   integer value (called the interface index) to that interface.  These
+   are small positive integers that start at 1.  (Note that 0 is never
+   used for an interface index.)  There may be gaps so that there is no
+   current interface for a particular positive interface index.
+
+   This API defines two functions that map between an interface name and
+   index, a third function that returns all the interface names and
+   indexes, and a fourth function to return the dynamic memory allocated
+   by the previous function.  How these functions are implemented is
+
+
+
+Gilligan, et al.             Informational                     [Page 16]
+
+RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
+
+
+   left up to the implementation.  4.4BSD implementations can implement
+   these functions using the existing sysctl() function with the
+   NET_RT_IFLIST command.  Other implementations may wish to use ioctl()
+   for this purpose.
+
+4.1 Name-to-Index
+
+   The first function maps an interface name into its corresponding
+   index.
+
+      #include <net/if.h>
+
+      unsigned int  if_nametoindex(const char *ifname);
+
+   If ifname is the name of an interface, the if_nametoindex() function
+   shall return the interface index corresponding to name ifname;
+   otherwise, it shall return zero.  No errors are defined.
+
+4.2 Index-to-Name
+
+   The second function maps an interface index into its corresponding
+   name.
+
+      #include <net/if.h>
+
+      char  *if_indextoname(unsigned int ifindex, char *ifname);
+
+   When this function is called, the ifname argument shall point to a
+   buffer of at least IF_NAMESIZE bytes.  The function shall place in
+   this buffer the name of the interface with index ifindex.
+   (IF_NAMESIZE is also defined in <net/if.h> and its value includes a
+   terminating null byte at the end of the interface name.)  If ifindex
+   is an interface index, then the function shall return the value
+   supplied in ifname, which points to a buffer now containing the
+   interface name.  Otherwise, the function shall return a NULL pointer
+   and set errno to indicate the error.  If there is no interface
+   corresponding to the specified index, errno is set to ENXIO.  If
+   there was a system error (such as running out of memory), errno would
+   be set to the proper value (e.g., ENOMEM).
+
+
+
+
+
+
+
+
+
+
+
+
+Gilligan, et al.             Informational                     [Page 17]
+
+RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
+
+
+4.3 Return All Interface Names and Indexes
+
+   The if_nameindex structure holds the information about a single
+   interface and is defined as a result of including the <net/if.h>
+   header.
+
+   struct if_nameindex {
+     unsigned int   if_index;  /* 1, 2, ... */
+     char          *if_name;   /* null terminated name: "le0", ... */
+   };
+
+   The final function returns an array of if_nameindex structures, one
+   structure per interface.
+
+      #include <net/if.h>
+
+      struct if_nameindex  *if_nameindex(void);
+
+   The end of the array of structures is indicated by a structure with
+   an if_index of 0 and an if_name of NULL.  The function returns a NULL
+   pointer upon an error, and would set errno to the appropriate value.
+
+   The memory used for this array of structures along with the interface
+   names pointed to by the if_name members is obtained dynamically.
+   This memory is freed by the next function.
+
+4.4 Free Memory
+
+   The following function frees the dynamic memory that was allocated by
+   if_nameindex().
+
+      #include <net/if.h>
+
+      void  if_freenameindex(struct if_nameindex *ptr);
+
+   The ptr argument shall be a pointer that was returned by
+   if_nameindex().  After if_freenameindex() has been called, the
+   application shall not use the array of which ptr is the address.
+
+5. Socket Options
+
+   A number of new socket options are defined for IPv6.  All of these
+   new options are at the IPPROTO_IPV6 level.  That is, the "level"
+   parameter in the getsockopt() and setsockopt() calls is IPPROTO_IPV6
+   when using these options.  The constant name prefix IPV6_ is used in
+   all of the new socket options.  This serves to clearly identify these
+   options as applying to IPv6.
+
+
+
+
+Gilligan, et al.             Informational                     [Page 18]
+
+RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
+
+
+   The declaration for IPPROTO_IPV6, the new IPv6 socket options, and
+   related constants defined in this section are obtained by including
+   the header <netinet/in.h>.
+
+5.1 Unicast Hop Limit
+
+   A new setsockopt() option controls the hop limit used in outgoing
+   unicast IPv6 packets.  The name of this option is IPV6_UNICAST_HOPS,
+   and it is used at the IPPROTO_IPV6 layer.  The following example
+   illustrates how it is used:
+
+   int  hoplimit = 10;
+
+   if (setsockopt(s, IPPROTO_IPV6, IPV6_UNICAST_HOPS,
+                  (char *) &hoplimit, sizeof(hoplimit)) == -1)
+       perror("setsockopt IPV6_UNICAST_HOPS");
+
+   When the IPV6_UNICAST_HOPS option is set with setsockopt(), the
+   option value given is used as the hop limit for all subsequent
+   unicast packets sent via that socket.  If the option is not set, the
+   system selects a default value.  The integer hop limit value (called
+   x) is interpreted as follows:
+
+      x < -1:        return an error of EINVAL
+      x == -1:       use kernel default
+      0 <= x <= 255: use x
+      x >= 256:      return an error of EINVAL
+
+   The IPV6_UNICAST_HOPS option may be used with getsockopt() to
+   determine the hop limit value that the system will use for subsequent
+   unicast packets sent via that socket.  For example:
+
+      int  hoplimit;
+      socklen_t  len = sizeof(hoplimit);
+
+      if (getsockopt(s, IPPROTO_IPV6, IPV6_UNICAST_HOPS,
+                     (char *) &hoplimit, &len) == -1)
+          perror("getsockopt IPV6_UNICAST_HOPS");
+      else
+          printf("Using %d for hop limit.\n", hoplimit);
+
+5.2 Sending and Receiving Multicast Packets
+
+   IPv6 applications may send multicast packets by simply specifying an
+   IPv6 multicast address as the destination address, for example in the
+   destination address argument of the sendto() function.
+
+
+
+
+
+Gilligan, et al.             Informational                     [Page 19]
+
+RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
+
+
+   Three socket options at the IPPROTO_IPV6 layer control some of the
+   parameters for sending multicast packets.  Setting these options is
+   not required: applications may send multicast packets without using
+   these options.  The setsockopt() options for controlling the sending
+   of multicast packets are summarized below.  These three options can
+   also be used with getsockopt().
+
+      IPV6_MULTICAST_IF
+
+         Set the interface to use for outgoing multicast packets.  The
+         argument is the index of the interface to use.  If the
+         interface index is specified as zero, the system selects the
+         interface (for example, by looking up the address in a routing
+         table and using the resulting interface).
+
+         Argument type: unsigned int
+
+      IPV6_MULTICAST_HOPS
+
+         Set the hop limit to use for outgoing multicast packets.  (Note
+         a separate option - IPV6_UNICAST_HOPS - is provided to set the
+         hop limit to use for outgoing unicast packets.)
+
+         The interpretation of the argument is the same as for the
+         IPV6_UNICAST_HOPS option:
+
+            x < -1:        return an error of EINVAL
+            x == -1:       use kernel default
+            0 <= x <= 255: use x
+            x >= 256:      return an error of EINVAL
+
+            If IPV6_MULTICAST_HOPS is not set, the default is 1
+            (same as IPv4 today)
+
+         Argument type: int
+
+      IPV6_MULTICAST_LOOP
+
+         If a multicast datagram is sent to a group to which the sending
+         host itself belongs (on the outgoing interface), a copy of the
+         datagram is looped back by the IP layer for local delivery if
+         this option is set to 1.  If this option is set to 0 a copy is
+         not looped back.  Other option values return an error of
+         EINVAL.
+
+
+
+
+
+
+
+Gilligan, et al.             Informational                     [Page 20]
+
+RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
+
+
+         If IPV6_MULTICAST_LOOP is not set, the default is 1 (loopback;
+         same as IPv4 today).
+
+         Argument type: unsigned int
+
+   The reception of multicast packets is controlled by the two
+   setsockopt() options summarized below.  An error of EOPNOTSUPP is
+   returned if these two options are used with getsockopt().
+
+      IPV6_JOIN_GROUP
+
+         Join a multicast group on a specified local interface.
+         If the interface index is specified as 0,
+         the kernel chooses the local interface.
+         For example, some kernels look up the multicast group
+         in the normal IPv6 routing table and use the resulting
+         interface.
+
+         Argument type: struct ipv6_mreq
+
+      IPV6_LEAVE_GROUP
+
+         Leave a multicast group on a specified interface.
+         If the interface index is specified as 0, the system
+         may choose a multicast group membership to drop by
+         matching the multicast address only.
+
+         Argument type: struct ipv6_mreq
+
+   The argument type of both of these options is the ipv6_mreq
+   structure, defined as a result of including the <netinet/in.h>
+   header;
+
+   struct ipv6_mreq {
+       struct in6_addr ipv6mr_multiaddr; /* IPv6 multicast addr */
+       unsigned int    ipv6mr_interface; /* interface index */
+   };
+
+   Note that to receive multicast datagrams a process must join the
+   multicast group to which datagrams will be sent.  UDP applications
+   must also bind the UDP port to which datagrams will be sent.  Some
+   processes also bind the multicast group address to the socket, in
+   addition to the port, to prevent other datagrams destined to that
+   same port from being delivered to the socket.
+
+
+
+
+
+
+
+Gilligan, et al.             Informational                     [Page 21]
+
+RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
+
+
+5.3 IPV6_V6ONLY option for AF_INET6 Sockets
+
+   This socket option restricts AF_INET6 sockets to IPv6 communications
+   only.  As stated in section <3.7 Compatibility with IPv4 Nodes>,
+   AF_INET6 sockets may be used for both IPv4 and IPv6 communications.
+   Some applications may want to restrict their use of an AF_INET6
+   socket to IPv6 communications only.  For these applications the
+   IPV6_V6ONLY socket option is defined.  When this option is turned on,
+   the socket can be used to send and receive IPv6 packets only.  This
+   is an IPPROTO_IPV6 level option.  This option takes an int value.
+   This is a boolean option.  By default this option is turned off.
+
+   Here is an example of setting this option:
+
+      int on = 1;
+
+      if (setsockopt(s, IPPROTO_IPV6, IPV6_V6ONLY,
+                     (char *)&on, sizeof(on)) == -1)
+          perror("setsockopt IPV6_V6ONLY");
+      else
+          printf("IPV6_V6ONLY set\n");
+
+   Note - This option has no effect on the use of IPv4 Mapped addresses
+   which enter a node as a valid IPv6 addresses for IPv6 communications
+   as defined by Stateless IP/ICMP Translation Algorithm (SIIT) [5].
+
+   An example use of this option is to allow two versions of the same
+   server process to run on the same port, one providing service over
+   IPv6, the other providing the same service over IPv4.
+
+6. Library Functions
+
+   New library functions are needed to perform a variety of operations
+   with IPv6 addresses.  Functions are needed to lookup IPv6 addresses
+   in the Domain Name System (DNS).  Both forward lookup (nodename-to-
+   address translation) and reverse lookup (address-to-nodename
+   translation) need to be supported.  Functions are also needed to
+   convert IPv6 addresses between their binary and textual form.
+
+   We note that the two existing functions, gethostbyname() and
+   gethostbyaddr(), are left as-is.  New functions are defined to handle
+   both IPv4 and IPv6 addresses.
+
+   The commonly used function gethostbyname() is inadequate for many
+   applications, first because it provides no way for the caller to
+   specify anything about the types of addresses desired (IPv4 only,
+   IPv6 only, IPv4-mapped IPv6 are OK, etc.), and second because many
+   implementations of this function are not thread safe.  RFC 2133
+
+
+
+Gilligan, et al.             Informational                     [Page 22]
+
+RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
+
+
+   defined a function named gethostbyname2() but this function was also
+   inadequate, first because its use required setting a global option
+   (RES_USE_INET6) when IPv6 addresses were required, and second because
+   a flag argument is needed to provide the caller with additional
+   control over the types of addresses required.  The gethostbyname2()
+   function was deprecated in RFC 2553 and is no longer part of the
+   basic API.
+
+6.1 Protocol-Independent Nodename and Service Name Translation
+
+   Nodename-to-address translation is done in a protocol-independent
+   fashion using the getaddrinfo() function.
+
+#include <sys/socket.h>
+#include <netdb.h>
+
+
+int getaddrinfo(const char *nodename, const char *servname,
+                const struct addrinfo *hints, struct addrinfo **res);
+
+void freeaddrinfo(struct addrinfo *ai);
+
+struct addrinfo {
+  int     ai_flags;     /* AI_PASSIVE, AI_CANONNAME,
+                           AI_NUMERICHOST, .. */
+  int     ai_family;    /* AF_xxx */
+  int     ai_socktype;  /* SOCK_xxx */
+  int     ai_protocol;  /* 0 or IPPROTO_xxx for IPv4 and IPv6 */
+  socklen_t  ai_addrlen;   /* length of ai_addr */
+  char   *ai_canonname; /* canonical name for nodename */
+  struct sockaddr  *ai_addr; /* binary address */
+  struct addrinfo  *ai_next; /* next structure in linked list */
+};
+
+   The getaddrinfo() function translates the name of a service location
+   (for example, a host name) and/or a service name and returns a set of
+   socket addresses and associated information to be used in creating a
+   socket with which to address the specified service.
+
+   The nodename and servname arguments are either null pointers or
+   pointers to null-terminated strings.  One or both of these two
+   arguments must be a non-null pointer.
+
+   The format of a valid name depends on the address family or families.
+   If a specific family is not given and the name could be interpreted
+   as valid within multiple supported families, the implementation will
+   attempt to resolve the name in all supported families and, in absence
+   of errors, one or more results shall be returned.
+
+
+
+Gilligan, et al.             Informational                     [Page 23]
+
+RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
+
+
+   If the nodename argument is not null, it can be a descriptive name or
+   can be an address string.  If the specified address family is
+   AF_INET, AF_INET6, or AF_UNSPEC, valid descriptive names include host
+   names. If the specified address family is AF_INET or AF_UNSPEC,
+   address strings using Internet standard dot notation as specified in
+   inet_addr() are valid.  If the specified address family is AF_INET6
+   or AF_UNSPEC, standard IPv6 text forms described in inet_pton() are
+   valid.
+
+   If nodename is not null, the requested service location is named by
+   nodename; otherwise, the requested service location is local to the
+   caller.
+
+   If servname is null, the call shall return network-level addresses
+   for the specified nodename.  If servname is not null, it is a null-
+   terminated character string identifying the requested service.  This
+   can be either a descriptive name or a numeric representation suitable
+   for use with the address family or families.  If the specified
+   address family is AF_INET, AF_INET6 or AF_UNSPEC, the service can be
+   specified as a string specifying a decimal port number.
+
+   If the argument hints is not null, it refers to a structure
+   containing input values that may direct the operation by providing
+   options and by limiting the returned information to a specific socket
+   type, address family and/or protocol.  In this hints structure every
+   member other than ai_flags, ai_family, ai_socktype and ai_protocol
+   shall be set to zero or a null pointer.  A value of AF_UNSPEC for
+   ai_family means that the caller shall accept any address family.  A
+   value of zero for ai_socktype means that the caller shall accept any
+   socket type.  A value of zero for ai_protocol means that the caller
+   shall accept any protocol.  If hints is a null pointer, the behavior
+   shall be as if it referred to a structure containing the value zero
+   for the ai_flags, ai_socktype and ai_protocol fields, and AF_UNSPEC
+   for the ai_family field.
+
+   Note:
+
+   1. If the caller handles only TCP and not UDP, for example, then the
+      ai_protocol member of the hints structure should be set to
+      IPPROTO_TCP when getaddrinfo() is called.
+
+   2. If the caller handles only IPv4 and not IPv6, then the ai_family
+      member of the hints structure should be set to AF_INET when
+      getaddrinfo() is called.
+
+
+
+
+
+
+
+Gilligan, et al.             Informational                     [Page 24]
+
+RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
+
+
+   The ai_flags field to which hints parameter points shall be set to
+   zero or be the bitwise-inclusive OR of one or more of the values
+   AI_PASSIVE, AI_CANONNAME, AI_NUMERICHOST, AI_NUMERICSERV,
+   AI_V4MAPPED, AI_ALL, and AI_ADDRCONFIG.
+
+   If the AI_PASSIVE flag is specified, the returned address information
+   shall be suitable for use in binding a socket for accepting incoming
+   connections for the specified service (i.e., a call to bind()).  In
+   this case, if the nodename argument is null, then the IP address
+   portion of the socket address structure shall be set to INADDR_ANY
+   for an IPv4 address or IN6ADDR_ANY_INIT for an IPv6 address.  If the
+   AI_PASSIVE flag is not specified, the returned address information
+   shall be suitable for a call to connect() (for a connection-mode
+   protocol) or for a call to connect(), sendto() or sendmsg() (for a
+   connectionless protocol).  In this case, if the nodename argument is
+   null, then the IP address portion of the socket address structure
+   shall be set to the loopback address.  This flag is ignored if the
+   nodename argument is not null.
+
+   If the AI_CANONNAME flag is specified and the nodename argument is
+   not null, the function shall attempt to determine the canonical name
+   corresponding to nodename (for example, if nodename is an alias or
+   shorthand notation for a complete name).
+
+   If the AI_NUMERICHOST flag is specified, then a non-null nodename
+   string supplied shall be a numeric host address string.  Otherwise,
+   an [EAI_NONAME] error is returned.  This flag shall prevent any type
+   of name resolution service (for example, the DNS) from being invoked.
+
+   If the AI_NUMERICSERV flag is specified, then a non-null servname
+   string supplied shall be a numeric port string.  Otherwise, an
+   [EAI_NONAME] error shall be returned.  This flag shall prevent any
+   type of name resolution service (for example, NIS+) from being
+   invoked.
+
+   If the AI_V4MAPPED flag is specified along with an ai_family of
+   AF_INET6, then getaddrinfo() shall return IPv4-mapped IPv6 addresses
+   on finding no matching IPv6 addresses (ai_addrlen shall be 16).
+
+      For example, when using the DNS, if no AAAA records are found then
+      a query is made for A records and any found are returned as IPv4-
+      mapped IPv6 addresses.
+
+   The AI_V4MAPPED flag shall be ignored unless ai_family equals
+   AF_INET6.
+
+   If the AI_ALL flag is used with the AI_V4MAPPED flag, then
+   getaddrinfo() shall return all matching IPv6 and IPv4 addresses.
+
+
+
+Gilligan, et al.             Informational                     [Page 25]
+
+RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
+
+
+      For example, when using the DNS, queries are made for both AAAA
+      records and A records, and getaddrinfo() returns the combined
+      results of both queries.  Any IPv4 addresses found are returned as
+      IPv4-mapped IPv6 addresses.
+
+   The AI_ALL flag without the AI_V4MAPPED flag is ignored.
+
+      Note:
+
+      When ai_family is not specified (AF_UNSPEC), AI_V4MAPPED and
+      AI_ALL flags will only be used if AF_INET6 is supported.
+
+   If the AI_ADDRCONFIG flag is specified, IPv4 addresses shall be
+   returned only if an IPv4 address is configured on the local system,
+   and IPv6 addresses shall be returned only if an IPv6 address is
+   configured on the local system.  The loopback address is not
+   considered for this case as valid as a configured address.
+
+      For example, when using the DNS, a query for AAAA records should
+      occur only if the node has at least one IPv6 address configured
+      (other than IPv6 loopback) and a query for A records should occur
+      only if the node has at least one IPv4 address configured (other
+      than the IPv4 loopback).
+
+   The ai_socktype field to which argument hints points specifies the
+   socket type for the service, as defined for socket().  If a specific
+   socket type is not given (for example, a value of zero) and the
+   service name could be interpreted as valid with multiple supported
+   socket types, the implementation shall attempt to resolve the service
+   name for all supported socket types and, in the absence of errors,
+   all possible results shall be returned.  A non-zero socket type value
+   shall limit the returned information to values with the specified
+   socket type.
+
+   If the ai_family field to which hints points has the value AF_UNSPEC,
+   addresses shall be returned for use with any address family that can
+   be used with the specified nodename and/or servname.  Otherwise,
+   addresses shall be returned for use only with the specified address
+   family.  If ai_family is not AF_UNSPEC and ai_protocol is not zero,
+   then addresses are returned for use only with the specified address
+   family and protocol; the value of ai_protocol shall be interpreted as
+   in a call to the socket() function with the corresponding values of
+   ai_family and ai_protocol.
+
+   The freeaddrinfo() function frees one or more addrinfo structures
+   returned by getaddrinfo(), along with any additional storage
+   associated with those structures (for example, storage pointed to by
+   the ai_canonname and ai_addr fields; an application must not
+
+
+
+Gilligan, et al.             Informational                     [Page 26]
+
+RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
+
+
+   reference this storage after the associated addrinfo structure has
+   been freed).  If the ai_next field of the structure is not null, the
+   entire list of structures is freed.  The freeaddrinfo() function must
+   support the freeing of arbitrary sublists of an addrinfo list
+   originally returned by getaddrinfo().
+
+   Functions getaddrinfo() and freeaddrinfo() must be thread-safe.
+
+   A zero return value for getaddrinfo() indicates successful
+   completion; a non-zero return value indicates failure.  The possible
+   values for the failures are listed below under Error Return Values.
+
+   Upon successful return of getaddrinfo(), the location to which res
+   points shall refer to a linked list of addrinfo structures, each of
+   which shall specify a socket address and information for use in
+   creating a socket with which to use that socket address.  The list
+   shall include at least one addrinfo structure.  The ai_next field of
+   each structure contains a pointer to the next structure on the list,
+   or a null pointer if it is the last structure on the list.  Each
+   structure on the list shall include values for use with a call to the
+   socket() function, and a socket address for use with the connect()
+   function or, if the AI_PASSIVE flag was specified, for use with the
+   bind() function.  The fields ai_family, ai_socktype, and ai_protocol
+   shall be usable as the arguments to the socket() function to create a
+   socket suitable for use with the returned address.  The fields
+   ai_addr and ai_addrlen are usable as the arguments to the connect()
+   or bind() functions with such a socket, according to the AI_PASSIVE
+   flag.
+
+   If nodename is not null, and if requested by the AI_CANONNAME flag,
+   the ai_canonname field of the first returned addrinfo structure shall
+   point to a null-terminated string containing the canonical name
+   corresponding to the input nodename; if the canonical name is not
+   available, then ai_canonname shall refer to the nodename argument or
+   a string with the same contents.  The contents of the ai_flags field
+   of the returned structures are undefined.
+
+   All fields in socket address structures returned by getaddrinfo()
+   that are not filled in through an explicit argument (for example,
+   sin6_flowinfo) shall be set to zero.
+
+   Note: This makes it easier to compare socket address structures.
+
+
+
+
+
+
+
+
+
+Gilligan, et al.             Informational                     [Page 27]
+
+RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
+
+
+   Error Return Values:
+
+   The getaddrinfo() function shall fail and return the corresponding
+   value if:
+
+   [EAI_AGAIN]     The name could not be resolved at this time.  Future
+                   attempts may succeed.
+
+   [EAI_BADFLAGS]  The flags parameter had an invalid value.
+
+   [EAI_FAIL]      A non-recoverable error occurred when attempting to
+                   resolve the name.
+
+   [EAI_FAMILY]    The address family was not recognized.
+
+   [EAI_MEMORY]    There was a memory allocation failure when trying to
+                   allocate storage for the return value.
+
+   [EAI_NONAME]    The name does not resolve for the supplied
+                   parameters.  Neither nodename nor servname were
+                   supplied.  At least one of these must be supplied.
+
+   [EAI_SERVICE]   The service passed was not recognized for the
+                   specified socket type.
+
+   [EAI_SOCKTYPE]  The intended socket type was not recognized.
+
+   [EAI_SYSTEM]    A system error occurred; the error code can be found
+                   in errno.
+
+   The gai_strerror() function provides a descriptive text string
+   corresponding to an EAI_xxx error value.
+
+      #include <netdb.h>
+
+      const char *gai_strerror(int ecode);
+
+   The argument is one of the EAI_xxx values defined for the
+   getaddrinfo() and getnameinfo() functions.  The return value points
+   to a string describing the error.  If the argument is not one of the
+   EAI_xxx values, the function still returns a pointer to a string
+   whose contents indicate an unknown error.
+
+6.2 Socket Address Structure to Node Name and Service Name
+
+   The getnameinfo() function is used to translate the contents of a
+   socket address structure to a node name and/or service name.
+
+
+
+
+Gilligan, et al.             Informational                     [Page 28]
+
+RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
+
+
+   #include <sys/socket.h>
+   #include <netdb.h>
+
+   int getnameinfo(const struct sockaddr *sa, socklen_t salen,
+                       char *node, socklen_t nodelen,
+                       char *service, socklen_t servicelen,
+                         int flags);
+
+   The getnameinfo() function shall translate a socket address to a node
+   name and service location, all of which are defined as in
+   getaddrinfo().
+
+   The sa argument points to a socket address structure to be
+   translated.
+
+   The salen argument holds the size of the socket address structure
+   pointed to by sa.
+
+   If the socket address structure contains an IPv4-mapped IPv6 address
+   or an IPv4-compatible IPv6 address, the implementation shall extract
+   the embedded IPv4 address and lookup the node name for that IPv4
+   address.
+
+      Note: The IPv6 unspecified address ("::") and the IPv6 loopback
+      address ("::1") are not IPv4-compatible addresses.  If the address
+      is the IPv6 unspecified address ("::"), a lookup is not performed,
+      and the [EAI_NONAME] error is returned.
+
+   If the node argument is non-NULL and the nodelen argument is nonzero,
+   then the node argument points to a buffer able to contain up to
+   nodelen characters that receives the node name as a null-terminated
+   string.  If the node argument is NULL or the nodelen argument is
+   zero, the node name shall not be returned.  If the node's name cannot
+   be located, the numeric form of the node's address is returned
+   instead of its name.
+
+   If the service argument is non-NULL and the servicelen argument is
+   non-zero, then the service argument points to a buffer able to
+   contain up to servicelen bytes that receives the service name as a
+   null-terminated string.  If the service argument is NULL or the
+   servicelen argument is zero, the service name shall not be returned.
+   If the service's name cannot be located, the numeric form of the
+   service address (for example, its port number) shall be returned
+   instead of its name.
+
+   The arguments node and service cannot both be NULL.
+
+
+
+
+
+Gilligan, et al.             Informational                     [Page 29]
+
+RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
+
+
+   The flags argument is a flag that changes the default actions of the
+   function.  By default the fully-qualified domain name (FQDN) for the
+   host shall be returned, but:
+
+   -  If the flag bit NI_NOFQDN is set, only the node name portion of
+      the FQDN shall be returned for local hosts.
+
+   -  If the flag bit NI_NUMERICHOST is set, the numeric form of the
+      host's address shall be returned instead of its name, under all
+      circumstances.
+
+   -  If the flag bit NI_NAMEREQD is set, an error shall be returned if
+      the host's name cannot be located.
+
+   -  If the flag bit NI_NUMERICSERV is set, the numeric form of the
+      service address shall be returned (for example, its port number)
+      instead of its name, under all circumstances.
+
+   -  If the flag bit NI_DGRAM is set, this indicates that the service
+      is a datagram service (SOCK_DGRAM).  The default behavior shall
+      assume that the service is a stream service (SOCK_STREAM).
+
+   Note:
+
+   1. The NI_NUMERICxxx flags are required to support the "-n" flags
+      that many commands provide.
+
+   2. The NI_DGRAM flag is required for the few AF_INET and AF_INET6
+      port numbers (for example, [512,514]) that represent different
+      services for UDP and TCP.
+
+   The getnameinfo() function shall be thread safe.
+
+   A zero return value for getnameinfo() indicates successful
+   completion; a non-zero return value indicates failure.
+
+   Upon successful completion, getnameinfo() shall return the node and
+   service names, if requested, in the buffers provided.  The returned
+   names are always null-terminated strings.
+
+
+
+
+
+
+
+
+
+
+
+
+Gilligan, et al.             Informational                     [Page 30]
+
+RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
+
+
+   Error Return Values:
+
+   The getnameinfo() function shall fail and return the corresponding
+   value if:
+
+   [EAI_AGAIN]    The name could not be resolved at this time.
+                  Future attempts may succeed.
+
+   [EAI_BADFLAGS] The flags had an invalid value.
+
+   [EAI_FAIL]     A non-recoverable error occurred.
+
+   [EAI_FAMILY]   The address family was not recognized or the address
+                  length was invalid for the specified family.
+
+   [EAI_MEMORY]   There was a memory allocation failure.
+
+   [EAI_NONAME]   The name does not resolve for the supplied parameters.
+                  NI_NAMEREQD is set and the host's name cannot be
+                  located, or both nodename and servname were null.
+
+   [EAI_OVERFLOW] An argument buffer overflowed.
+
+   [EAI_SYSTEM]   A system error occurred.  The error code can be found
+                  in errno.
+
+6.3 Address Conversion Functions
+
+   The two IPv4 functions inet_addr() and inet_ntoa() convert an IPv4
+   address between binary and text form.  IPv6 applications need similar
+   functions.  The following two functions convert both IPv6 and IPv4
+   addresses:
+
+   #include <arpa/inet.h>
+
+   int inet_pton(int af, const char *src, void *dst);
+
+   const char *inet_ntop(int af, const void *src,
+                            char *dst, socklen_t size);
+
+   The inet_pton() function shall convert an address in its standard
+   text presentation form into its numeric binary form.  The af argument
+   shall specify the family of the address.  The AF_INET and AF_INET6
+   address families shall be supported.  The src argument points to the
+   string being passed in.  The dst argument points to a buffer into
+   which the function stores the numeric address; this shall be large
+   enough to hold the numeric address (32 bits for AF_INET, 128 bits for
+   AF_INET6).  The inet_pton() function shall return 1 if the conversion
+
+
+
+Gilligan, et al.             Informational                     [Page 31]
+
+RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
+
+
+   succeeds, with the address pointed to by dst in network byte order.
+   It shall return 0 if the input is not a valid IPv4 dotted-decimal
+   string or a valid IPv6 address string, or -1 with errno set to
+   EAFNOSUPPORT if the af argument is unknown.
+
+   If the af argument of inet_pton() is AF_INET, the src string shall be
+   in the standard IPv4 dotted-decimal form:
+
+      ddd.ddd.ddd.ddd
+
+   where "ddd" is a one to three digit decimal number between 0 and 255.
+   The inet_pton() function does not accept other formats (such as the
+   octal numbers, hexadecimal numbers, and fewer than four numbers that
+   inet_addr() accepts).
+
+   If the af argument of inet_pton() is AF_INET6, the src string shall
+   be in one of the standard IPv6 text forms defined in Section 2.2 of
+   the addressing architecture specification [2].
+
+   The inet_ntop() function shall convert a numeric address into a text
+   string suitable for presentation.  The af argument shall specify the
+   family of the address.  This can be AF_INET or AF_INET6.  The src
+   argument points to a buffer holding an IPv4 address if the af
+   argument is AF_INET, or an IPv6 address if the af argument is
+   AF_INET6; the address must be in network byte order.  The dst
+   argument points to a buffer where the function stores the resulting
+   text string; it shall not be NULL.  The size argument specifies the
+   size of this buffer, which shall be large enough to hold the text
+   string (INET_ADDRSTRLEN characters for IPv4, INET6_ADDRSTRLEN
+   characters for IPv6).
+
+   In order to allow applications to easily declare buffers of the
+   proper size to store IPv4 and IPv6 addresses in string form, the
+   following two constants are defined in <netinet/in.h>:
+
+      #define INET_ADDRSTRLEN    16
+      #define INET6_ADDRSTRLEN   46
+
+   The inet_ntop() function shall return a pointer to the buffer
+   containing the text string if the conversion succeeds, and NULL
+   otherwise.  Upon failure, errno is set to EAFNOSUPPORT if the af
+   argument is invalid or ENOSPC if the size of the result buffer is
+   inadequate.
+
+
+
+
+
+
+
+
+Gilligan, et al.             Informational                     [Page 32]
+
+RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
+
+
+6.4 Address Testing Macros
+
+   The following macros can be used to test for special IPv6 addresses.
+
+   #include <netinet/in.h>
+
+   int  IN6_IS_ADDR_UNSPECIFIED (const struct in6_addr *);
+   int  IN6_IS_ADDR_LOOPBACK    (const struct in6_addr *);
+   int  IN6_IS_ADDR_MULTICAST   (const struct in6_addr *);
+   int  IN6_IS_ADDR_LINKLOCAL   (const struct in6_addr *);
+   int  IN6_IS_ADDR_SITELOCAL   (const struct in6_addr *);
+   int  IN6_IS_ADDR_V4MAPPED    (const struct in6_addr *);
+   int  IN6_IS_ADDR_V4COMPAT    (const struct in6_addr *);
+
+   int  IN6_IS_ADDR_MC_NODELOCAL(const struct in6_addr *);
+   int  IN6_IS_ADDR_MC_LINKLOCAL(const struct in6_addr *);
+   int  IN6_IS_ADDR_MC_SITELOCAL(const struct in6_addr *);
+   int  IN6_IS_ADDR_MC_ORGLOCAL (const struct in6_addr *);
+   int  IN6_IS_ADDR_MC_GLOBAL   (const struct in6_addr *);
+
+   The first seven macros return true if the address is of the specified
+   type, or false otherwise.  The last five test the scope of a
+   multicast address and return true if the address is a multicast
+   address of the specified scope or false if the address is either not
+   a multicast address or not of the specified scope.
+
+   Note that IN6_IS_ADDR_LINKLOCAL and IN6_IS_ADDR_SITELOCAL return true
+   only for the two types of local-use IPv6 unicast addresses (Link-
+   Local and Site-Local) defined in [2], and that by this definition,
+   the IN6_IS_ADDR_LINKLOCAL macro returns false for the IPv6 loopback
+   address (::1).  These two macros do not return true for IPv6
+   multicast addresses of either link-local scope or site-local scope.
+
+7. Summary of New Definitions
+
+   The following list summarizes the constants, structure, and extern
+   definitions discussed in this memo, sorted by header.
+
+<net/if.h>      IF_NAMESIZE
+<net/if.h>      struct if_nameindex{};
+
+<netdb.h>       AI_ADDRCONFIG
+<netdb.h>       AI_ALL
+<netdb.h>       AI_CANONNAME
+<netdb.h>       AI_NUMERICHOST
+<netdb.h>       AI_NUMERICSERV
+<netdb.h>       AI_PASSIVE
+<netdb.h>       AI_V4MAPPED
+
+
+
+Gilligan, et al.             Informational                     [Page 33]
+
+RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
+
+
+<netdb.h>       EAI_AGAIN
+<netdb.h>       EAI_BADFLAGS
+<netdb.h>       EAI_FAIL
+<netdb.h>       EAI_FAMILY
+<netdb.h>       EAI_MEMORY
+<netdb.h>       EAI_NONAME
+<netdb.h>       EAI_OVERFLOW
+<netdb.h>       EAI_SERVICE
+<netdb.h>       EAI_SOCKTYPE
+<netdb.h>       EAI_SYSTEM
+<netdb.h>       NI_DGRAM
+<netdb.h>       NI_NAMEREQD
+<netdb.h>       NI_NOFQDN
+<netdb.h>       NI_NUMERICHOST
+<netdb.h>       NI_NUMERICSERV
+<netdb.h>       struct addrinfo{};
+
+<netinet/in.h>  IN6ADDR_ANY_INIT
+<netinet/in.h>  IN6ADDR_LOOPBACK_INIT
+<netinet/in.h>  INET6_ADDRSTRLEN
+<netinet/in.h>  INET_ADDRSTRLEN
+<netinet/in.h>  IPPROTO_IPV6
+<netinet/in.h>  IPV6_JOIN_GROUP
+<netinet/in.h>  IPV6_LEAVE_GROUP
+<netinet/in.h>  IPV6_MULTICAST_HOPS
+<netinet/in.h>  IPV6_MULTICAST_IF
+<netinet/in.h>  IPV6_MULTICAST_LOOP
+<netinet/in.h>  IPV6_UNICAST_HOPS
+<netinet/in.h>  IPV6_V6ONLY
+<netinet/in.h>  SIN6_LEN
+<netinet/in.h>  extern const struct in6_addr in6addr_any;
+<netinet/in.h>  extern const struct in6_addr in6addr_loopback;
+<netinet/in.h>  struct in6_addr{};
+<netinet/in.h>  struct ipv6_mreq{};
+<netinet/in.h>  struct sockaddr_in6{};
+
+<sys/socket.h>  AF_INET6
+<sys/socket.h>  PF_INET6
+<sys/socket.h>  struct sockaddr_storage;
+
+   The following list summarizes the function and macro prototypes
+   discussed in this memo, sorted by header.
+
+<arpa/inet.h>   int inet_pton(int, const char *, void *);
+<arpa/inet.h>   const char *inet_ntop(int, const void *,
+                               char *, socklen_t);
+
+
+
+
+
+Gilligan, et al.             Informational                     [Page 34]
+
+RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
+
+
+<net/if.h>      char *if_indextoname(unsigned int, char *);
+<net/if.h>      unsigned int if_nametoindex(const char *);
+<net/if.h>      void if_freenameindex(struct if_nameindex *);
+<net/if.h>      struct if_nameindex *if_nameindex(void);
+
+<netdb.h>       int getaddrinfo(const char *, const char *,
+                                const struct addrinfo *,
+                                struct addrinfo **);
+<netdb.h>       int getnameinfo(const struct sockaddr *, socklen_t,
+                  char *, socklen_t, char *, socklen_t, int);
+<netdb.h>       void freeaddrinfo(struct addrinfo *);
+<netdb.h>       const char *gai_strerror(int);
+
+<netinet/in.h>  int IN6_IS_ADDR_LINKLOCAL(const struct in6_addr *);
+<netinet/in.h>  int IN6_IS_ADDR_LOOPBACK(const struct in6_addr *);
+<netinet/in.h>  int IN6_IS_ADDR_MC_GLOBAL(const struct in6_addr *);
+<netinet/in.h>  int IN6_IS_ADDR_MC_LINKLOCAL(const struct in6_addr *);
+<netinet/in.h>  int IN6_IS_ADDR_MC_NODELOCAL(const struct in6_addr *);
+<netinet/in.h>  int IN6_IS_ADDR_MC_ORGLOCAL(const struct in6_addr *);
+<netinet/in.h>  int IN6_IS_ADDR_MC_SITELOCAL(const struct in6_addr *);
+<netinet/in.h>  int IN6_IS_ADDR_MULTICAST(const struct in6_addr *);
+<netinet/in.h>  int IN6_IS_ADDR_SITELOCAL(const struct in6_addr *);
+<netinet/in.h>  int IN6_IS_ADDR_UNSPECIFIED(const struct in6_addr *);
+<netinet/in.h>  int IN6_IS_ADDR_V4COMPAT(const struct in6_addr *);
+<netinet/in.h>  int IN6_IS_ADDR_V4MAPPED(const struct in6_addr *);
+
+8. Security Considerations
+
+   IPv6 provides a number of new security mechanisms, many of which need
+   to be accessible to applications.  Companion memos detailing the
+   extensions to the socket interfaces to support IPv6 security are
+   being written.
+
+9. Changes from RFC 2553
+
+   1. Add brief description of the history of this API and its relation
+      to the Open Group/IEEE/ISO standards.
+
+   2. Alignments with [3].
+
+   3. Removed all references to getipnodebyname() and getipnodebyaddr(),
+      which are deprecated in favor of getaddrinfo() and getnameinfo().
+
+   4. Added IPV6_V6ONLY IP level socket option to permit nodes to not
+      process IPv4 packets as IPv4 Mapped addresses in implementations.
+
+   5. Added SIIT to references and added new contributors.
+
+
+
+
+Gilligan, et al.             Informational                     [Page 35]
+
+RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
+
+
+   6. In previous versions of this specification, the sin6_flowinfo
+      field was associated with the IPv6 traffic class and flow label,
+      but its usage was not completely specified.  The complete
+      definition of the sin6_flowinfo field, including its association
+      with the traffic class or flow label, is now deferred to a future
+      specification.
+
+10. Acknowledgments
+
+   This specification's evolution and completeness were significantly
+   influenced by the efforts of Richard Stevens, who has passed on.
+   Richard's wisdom and talent made the specification what it is today.
+   The co-authors will long think of Richard with great respect.
+
+   Thanks to the many people who made suggestions and provided feedback
+   to this document, including:
+
+   Werner Almesberger, Ran Atkinson, Fred Baker, Dave Borman, Andrew
+   Cherenson, Alex Conta, Alan Cox, Steve Deering, Richard Draves,
+   Francis Dupont, Robert Elz, Brian Haberman, Jun-ichiro itojun Hagino,
+   Marc Hasson, Tom Herbert, Bob Hinden, Wan-Yen Hsu, Christian Huitema,
+   Koji Imada, Markus Jork, Ron Lee, Alan Lloyd, Charles Lynn, Dan
+   McDonald, Dave Mitton, Finnbarr Murphy, Thomas Narten, Josh Osborne,
+   Craig Partridge, Jean-Luc Richier, Bill Sommerfield, Erik Scoredos,
+   Keith Sklower, JINMEI Tatuya, Dave Thaler, Matt Thomas, Harvey
+   Thompson, Dean D. Throop, Karen Tracey, Glenn Trewitt, Paul Vixie,
+   David Waitzman, Carl Williams, Kazu Yamamoto, Vlad Yasevich, Stig
+   Venaas, and Brian Zill.
+
+   The getaddrinfo() and getnameinfo() functions are taken from an
+   earlier document by Keith Sklower.  As noted in that document,
+   William Durst, Steven Wise, Michael Karels, and Eric Allman provided
+   many useful discussions on the subject of protocol-independent name-
+   to-address translation, and reviewed early versions of Keith
+   Sklower's original proposal.  Eric Allman implemented the first
+   prototype of getaddrinfo().  The observation that specifying the pair
+   of name and service would suffice for connecting to a service
+   independent of protocol details was made by Marshall Rose in a
+   proposal to X/Open for a "Uniform Network Interface".
+
+   Craig Metz, Jack McCann, Erik Nordmark, Tim Hartrick, and Mukesh
+   Kacker made many contributions to this document.  Ramesh Govindan
+   made a number of contributions and co-authored an earlier version of
+   this memo.
+
+
+
+
+
+
+
+Gilligan, et al.             Informational                     [Page 36]
+
+RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
+
+
+11. References
+
+   [1]  Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
+        Specification", RFC 2460, December 1998.
+
+   [2]  Hinden, R. and S. Deering, "IP Version 6 Addressing
+        Architecture", RFC 2373, July 1998.
+
+   [3]  IEEE Std. 1003.1-2001 Standard for Information Technology --
+        Portable Operating System Interface (POSIX). Open Group
+        Technical Standard: Base Specifications, Issue 6, December 2001.
+        ISO/IEC 9945:2002.  http://www.opengroup.org/austin
+
+   [4]  Stevens, W. and M. Thomas, "Advanced Sockets API for IPv6", RFC
+        2292, February 1998.
+
+   [5]  Nordmark, E., "Stateless IP/ICMP Translation Algorithm (SIIT)",
+        RFC 2765, February 2000.
+
+   [6]  The Open Group Base Working Group
+        http://www.opengroup.org/platform/base.html
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gilligan, et al.             Informational                     [Page 37]
+
+RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
+
+
+12. Authors' Addresses
+
+   Bob Gilligan
+   Intransa, Inc.
+   2870 Zanker Rd.
+   San Jose, CA 95134
+
+   Phone: 408-678-8647
+   EMail: gilligan@intransa.com
+
+
+   Susan Thomson
+   Cisco Systems
+   499 Thornall Street, 8th floor
+   Edison, NJ 08837
+
+   Phone: 732-635-3086
+   EMail:  sethomso@cisco.com
+
+
+   Jim Bound
+   Hewlett-Packard Company
+   110 Spitbrook Road ZKO3-3/W20
+   Nashua, NH 03062
+
+   Phone: 603-884-0062
+   EMail: Jim.Bound@hp.com
+
+
+   Jack McCann
+   Hewlett-Packard Company
+   110 Spitbrook Road ZKO3-3/W20
+   Nashua, NH 03062
+
+   Phone: 603-884-2608
+   EMail: Jack.McCann@hp.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gilligan, et al.             Informational                     [Page 38]
+
+RFC 3493       Basic Socket Interface Extensions for IPv6  February 2003
+
+
+13. Full Copyright Statement
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gilligan, et al.             Informational                     [Page 39]
+
diff --git a/doc/rfc/rfc3513.txt b/doc/rfc/rfc3513.txt
new file mode 100644
index 0000000..49c0fa4
--- /dev/null
+++ b/doc/rfc/rfc3513.txt
@@ -0,0 +1,1459 @@
+
+
+
+
+
+
+Network Working Group                                          R. Hinden
+Request for Comments: 3513                                         Nokia
+Obsoletes: 2373                                               S. Deering
+Category: Standards Track                                  Cisco Systems
+                                                              April 2003
+
+
+       Internet Protocol Version 6 (IPv6) Addressing Architecture
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+Abstract
+
+   This specification defines the addressing architecture of the IP
+   Version 6 (IPv6) protocol.  The document includes the IPv6 addressing
+   model, text representations of IPv6 addresses, definition of IPv6
+   unicast addresses, anycast addresses, and multicast addresses, and an
+   IPv6 node's required addresses.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hinden & Deering            Standards Track                     [Page 1]
+
+RFC 3513              IPv6 Addressing Architecture            April 2003
+
+
+Table of Contents
+
+   1. Introduction.................................................3
+   2. IPv6 Addressing..............................................3
+      2.1 Addressing Model.........................................4
+      2.2 Text Representation of Addresses.........................4
+      2.3 Text Representation of Address Prefixes..................5
+      2.4 Address Type Identification..............................6
+      2.5 Unicast Addresses........................................7
+          2.5.1 Interface Identifiers..............................8
+          2.5.2 The Unspecified Address............................9
+          2.5.3 The Loopback Address...............................9
+          2.5.4 Global Unicast Addresses..........................10
+          2.5.5 IPv6 Addresses with Embedded IPv4 Addresses.......10
+          2.5.6 Local-use IPv6 Unicast Addresses..................11
+      2.6 Anycast Addresses.......................................12
+          2.6.1 Required Anycast Address..........................13
+      2.7 Multicast Addresses.....................................13
+          2.7.1 Pre-Defined Multicast Addresses...................15
+      2.8 A Node's Required Addresses.............................17
+   3. Security Considerations.....................................17
+   4. IANA Considerations.........................................18
+   5. References..................................................19
+      5.1 Normative References....................................19
+      5.2 Informative References..................................19
+   APPENDIX A: Creating Modified EUI-64 format Interface IDs......21
+   APPENDIX B: Changes from RFC-2373..............................24
+   Authors' Addresses.............................................25
+   Full Copyright Statement.......................................26
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hinden & Deering            Standards Track                     [Page 2]
+
+RFC 3513              IPv6 Addressing Architecture            April 2003
+
+
+1.  Introduction
+
+   This specification defines the addressing architecture of the IP
+   Version 6 (IPv6) protocol.  It includes the basic formats for the
+   various types of IPv6 addresses (unicast, anycast, and multicast).
+
+   The authors would like to acknowledge the contributions of Paul
+   Francis, Scott Bradner, Jim Bound, Brian Carpenter, Matt Crawford,
+   Deborah Estrin, Roger Fajman, Bob Fink, Peter Ford, Bob Gilligan,
+   Dimitry Haskin, Tom Harsch, Christian Huitema, Tony Li, Greg
+   Minshall, Thomas Narten, Erik Nordmark, Yakov Rekhter, Bill Simpson,
+   Sue Thomson, Markku Savela, and Larry Masinter.
+
+2. IPv6 Addressing
+
+   IPv6 addresses are 128-bit identifiers for interfaces and sets of
+   interfaces (where "interface" is as defined in section 2 of [IPV6]).
+   There are three types of addresses:
+
+   Unicast:   An identifier for a single interface.  A packet sent to a
+              unicast address is delivered to the interface identified
+              by that address.
+
+   Anycast:   An identifier for a set of interfaces (typically belonging
+              to different nodes).  A packet sent to an anycast address
+              is delivered to one of the interfaces identified by that
+              address (the "nearest" one, according to the routing
+              protocols' measure of distance).
+
+   Multicast: An identifier for a set of interfaces (typically belonging
+              to different nodes).  A packet sent to a multicast address
+              is delivered to all interfaces identified by that address.
+
+   There are no broadcast addresses in IPv6, their function being
+   superseded by multicast addresses.
+
+   In this document, fields in addresses are given a specific name, for
+   example "subnet".  When this name is used with the term "ID" for
+   identifier after the name (e.g., "subnet ID"), it refers to the
+   contents of the named field.  When it is used with the term "prefix"
+   (e.g., "subnet prefix") it refers to all of the address from the left
+   up to and including this field.
+
+   In IPv6, all zeros and all ones are legal values for any field,
+   unless specifically excluded.  Specifically, prefixes may contain, or
+   end with, zero-valued fields.
+
+
+
+
+
+Hinden & Deering            Standards Track                     [Page 3]
+
+RFC 3513              IPv6 Addressing Architecture            April 2003
+
+
+2.1 Addressing Model
+
+   IPv6 addresses of all types are assigned to interfaces, not nodes.
+   An IPv6 unicast address refers to a single interface.  Since each
+   interface belongs to a single node, any of that node's interfaces'
+   unicast addresses may be used as an identifier for the node.
+
+   All interfaces are required to have at least one link-local unicast
+   address (see section 2.8 for additional required addresses).  A
+   single interface may also have multiple IPv6 addresses of any type
+   (unicast, anycast, and multicast) or scope.  Unicast addresses with
+   scope greater than link-scope are not needed for interfaces that are
+   not used as the origin or destination of any IPv6 packets to or from
+   non-neighbors.  This is sometimes convenient for point-to-point
+   interfaces.  There is one exception to this addressing model:
+
+      A unicast address or a set of unicast addresses may be assigned to
+      multiple physical interfaces if the implementation treats the
+      multiple physical interfaces as one interface when presenting it
+      to the internet layer.  This is useful for load-sharing over
+      multiple physical interfaces.
+
+   Currently IPv6 continues the IPv4 model that a subnet prefix is
+   associated with one link.  Multiple subnet prefixes may be assigned
+   to the same link.
+
+2.2 Text Representation of Addresses
+
+   There are three conventional forms for representing IPv6 addresses as
+   text strings:
+
+   1. The preferred form is x:x:x:x:x:x:x:x, where the 'x's are the
+      hexadecimal values of the eight 16-bit pieces of the address.
+
+      Examples:
+
+         FEDC:BA98:7654:3210:FEDC:BA98:7654:3210
+
+         1080:0:0:0:8:800:200C:417A
+
+      Note that it is not necessary to write the leading zeros in an
+      individual field, but there must be at least one numeral in every
+      field (except for the case described in 2.).
+
+   2. Due to some methods of allocating certain styles of IPv6
+      addresses, it will be common for addresses to contain long strings
+      of zero bits.  In order to make writing addresses containing zero
+      bits easier a special syntax is available to compress the zeros.
+
+
+
+Hinden & Deering            Standards Track                     [Page 4]
+
+RFC 3513              IPv6 Addressing Architecture            April 2003
+
+
+      The use of "::" indicates one or more groups of 16 bits of zeros.
+      The "::" can only appear once in an address.  The "::" can also be
+      used to compress leading or trailing zeros in an address.
+
+      For example, the following addresses:
+
+         1080:0:0:0:8:800:200C:417A  a unicast address
+         FF01:0:0:0:0:0:0:101        a multicast address
+         0:0:0:0:0:0:0:1             the loopback address
+         0:0:0:0:0:0:0:0             the unspecified addresses
+
+      may be represented as:
+
+         1080::8:800:200C:417A       a unicast address
+         FF01::101                   a multicast address
+         ::1                         the loopback address
+         ::                          the unspecified addresses
+
+   3. An alternative form that is sometimes more convenient when dealing
+      with a mixed environment of IPv4 and IPv6 nodes is
+      x:x:x:x:x:x:d.d.d.d, where the 'x's are the hexadecimal values of
+      the six high-order 16-bit pieces of the address, and the 'd's are
+      the decimal values of the four low-order 8-bit pieces of the
+      address (standard IPv4 representation).  Examples:
+
+         0:0:0:0:0:0:13.1.68.3
+
+         0:0:0:0:0:FFFF:129.144.52.38
+
+      or in compressed form:
+
+         ::13.1.68.3
+
+         ::FFFF:129.144.52.38
+
+2.3 Text Representation of Address Prefixes
+
+   The text representation of IPv6 address prefixes is similar to the
+   way IPv4 addresses prefixes are written in CIDR notation [CIDR].  An
+   IPv6 address prefix is represented by the notation:
+
+      ipv6-address/prefix-length
+
+   where
+
+      ipv6-address    is an IPv6 address in any of the notations listed
+                      in section 2.2.
+
+
+
+
+Hinden & Deering            Standards Track                     [Page 5]
+
+RFC 3513              IPv6 Addressing Architecture            April 2003
+
+
+      prefix-length   is a decimal value specifying how many of the
+                      leftmost contiguous bits of the address comprise
+                      the prefix.
+
+   For example, the following are legal representations of the 60-bit
+   prefix 12AB00000000CD3 (hexadecimal):
+
+      12AB:0000:0000:CD30:0000:0000:0000:0000/60
+      12AB::CD30:0:0:0:0/60
+      12AB:0:0:CD30::/60
+
+   The following are NOT legal representations of the above prefix:
+
+      12AB:0:0:CD3/60   may drop leading zeros, but not trailing zeros,
+                        within any 16-bit chunk of the address
+
+      12AB::CD30/60     address to left of "/" expands to
+                        12AB:0000:0000:0000:0000:000:0000:CD30
+
+      12AB::CD3/60      address to left of "/" expands to
+                        12AB:0000:0000:0000:0000:000:0000:0CD3
+
+   When writing both a node address and a prefix of that node address
+   (e.g., the node's subnet prefix), the two can combined as follows:
+
+      the node address      12AB:0:0:CD30:123:4567:89AB:CDEF
+      and its subnet number 12AB:0:0:CD30::/60
+
+      can be abbreviated as 12AB:0:0:CD30:123:4567:89AB:CDEF/60
+
+2.4 Address Type Identification
+
+   The type of an IPv6 address is identified by the high-order bits of
+   the address, as follows:
+
+   Address type         Binary prefix        IPv6 notation   Section
+   ------------         -------------        -------------   -------
+   Unspecified          00...0  (128 bits)   ::/128          2.5.2
+   Loopback             00...1  (128 bits)   ::1/128         2.5.3
+   Multicast            11111111             FF00::/8        2.7
+   Link-local unicast   1111111010           FE80::/10       2.5.6
+   Site-local unicast   1111111011           FEC0::/10       2.5.6
+   Global unicast       (everything else)
+
+   Anycast addresses are taken from the unicast address spaces (of any
+   scope) and are not syntactically distinguishable from unicast
+   addresses.
+
+
+
+
+Hinden & Deering            Standards Track                     [Page 6]
+
+RFC 3513              IPv6 Addressing Architecture            April 2003
+
+
+   The general format of global unicast addresses is described in
+   section 2.5.4.  Some special-purpose subtypes of global unicast
+   addresses which contain embedded IPv4 addresses (for the purposes of
+   IPv4-IPv6 interoperation) are described in section 2.5.5.
+
+   Future specifications may redefine one or more sub-ranges of the
+   global unicast space for other purposes, but unless and until that
+   happens, implementations must treat all addresses that do not start
+   with any of the above-listed prefixes as global unicast addresses.
+
+2.5 Unicast Addresses
+
+   IPv6 unicast addresses are aggregable with prefixes of arbitrary
+   bit-length similar to IPv4 addresses under Classless Interdomain
+   Routing.
+
+   There are several types of unicast addresses in IPv6, in particular
+   global unicast, site-local unicast, and link-local unicast.  There
+   are also some special-purpose subtypes of global unicast, such as
+   IPv6 addresses with embedded IPv4 addresses or encoded NSAP
+   addresses.  Additional address types or subtypes can be defined in
+   the future.
+
+   IPv6 nodes may have considerable or little knowledge of the internal
+   structure of the IPv6 address, depending on the role the node plays
+   (for instance, host versus router).  At a minimum, a node may
+   consider that unicast addresses (including its own) have no internal
+   structure:
+
+   |                           128 bits                              |
+   +-----------------------------------------------------------------+
+   |                          node address                           |
+   +-----------------------------------------------------------------+
+
+   A slightly sophisticated host (but still rather simple) may
+   additionally be aware of subnet prefix(es) for the link(s) it is
+   attached to, where different addresses may have different values for
+   n:
+
+   |                         n bits                 |   128-n bits   |
+   +------------------------------------------------+----------------+
+   |                   subnet prefix                | interface ID   |
+   +------------------------------------------------+----------------+
+
+   Though a very simple router may have no knowledge of the internal
+   structure of IPv6 unicast addresses, routers will more generally have
+   knowledge of one or more of the hierarchical boundaries for the
+   operation of routing protocols.  The known boundaries will differ
+
+
+
+Hinden & Deering            Standards Track                     [Page 7]
+
+RFC 3513              IPv6 Addressing Architecture            April 2003
+
+
+   from router to router, depending on what positions the router holds
+   in the routing hierarchy.
+
+2.5.1 Interface Identifiers
+
+   Interface identifiers in IPv6 unicast addresses are used to identify
+   interfaces on a link.  They are required to be unique within a subnet
+   prefix.  It is recommended that the same interface identifier not be
+   assigned to different nodes on a link.  They may also be unique over
+   a broader scope.  In some cases an interface's identifier will be
+   derived directly from that interface's link-layer address.  The same
+   interface identifier may be used on multiple interfaces on a single
+   node, as long as they are attached to different subnets.
+
+   Note that the uniqueness of interface identifiers is independent of
+   the uniqueness of IPv6 addresses.  For example, a global unicast
+   address may be created with a non-global scope interface identifier
+   and a site-local address may be created with a global scope interface
+   identifier.
+
+   For all unicast addresses, except those that start with binary value
+   000, Interface IDs are required to be 64 bits long and to be
+   constructed in Modified EUI-64 format.
+
+   Modified EUI-64 format based Interface identifiers may have global
+   scope when derived from a global token (e.g., IEEE 802 48-bit MAC or
+   IEEE EUI-64 identifiers [EUI64]) or may have local scope where a
+   global token is not available (e.g., serial links, tunnel end-points,
+   etc.) or where global tokens are undesirable (e.g., temporary tokens
+   for privacy [PRIV]).
+
+   Modified EUI-64 format interface identifiers are formed by inverting
+   the "u" bit (universal/local bit in IEEE EUI-64 terminology) when
+   forming the interface identifier from IEEE EUI-64 identifiers.  In
+   the resulting Modified EUI-64 format the "u" bit is set to one (1) to
+   indicate global scope, and it is set to zero (0) to indicate local
+   scope.  The first three octets in binary of an IEEE EUI-64 identifier
+   are as follows:
+
+       0       0 0       1 1       2
+      |0       7 8       5 6       3|
+      +----+----+----+----+----+----+
+      |cccc|ccug|cccc|cccc|cccc|cccc|
+      +----+----+----+----+----+----+
+
+   written in Internet standard bit-order , where "u" is the
+   universal/local bit, "g" is the individual/group bit, and "c" are the
+   bits of the company_id.  Appendix A: "Creating Modified EUI-64 format
+
+
+
+Hinden & Deering            Standards Track                     [Page 8]
+
+RFC 3513              IPv6 Addressing Architecture            April 2003
+
+
+   Interface Identifiers" provides examples on the creation of Modified
+   EUI-64 format based interface identifiers.
+
+   The motivation for inverting the "u" bit when forming an interface
+   identifier is to make it easy for system administrators to hand
+   configure non-global identifiers when hardware tokens are not
+   available.  This is expected to be case for serial links, tunnel end-
+   points, etc.  The alternative would have been for these to be of the
+   form 0200:0:0:1, 0200:0:0:2, etc., instead of the much simpler 1, 2,
+   etc.
+
+   The use of the universal/local bit in the Modified EUI-64 format
+   identifier is to allow development of future technology that can take
+   advantage of interface identifiers with global scope.
+
+   The details of forming interface identifiers are defined in the
+   appropriate "IPv6 over <link>" specification such as "IPv6 over
+   Ethernet" [ETHER], "IPv6 over FDDI" [FDDI], etc.
+
+2.5.2 The Unspecified Address
+
+   The address 0:0:0:0:0:0:0:0 is called the unspecified address.  It
+   must never be assigned to any node.  It indicates the absence of an
+   address.  One example of its use is in the Source Address field of
+   any IPv6 packets sent by an initializing host before it has learned
+   its own address.
+
+   The unspecified address must not be used as the destination address
+   of IPv6 packets or in IPv6 Routing Headers.  An IPv6 packet with a
+   source address of unspecified must never be forwarded by an IPv6
+   router.
+
+2.5.3 The Loopback Address
+
+   The unicast address 0:0:0:0:0:0:0:1 is called the loopback address.
+   It may be used by a node to send an IPv6 packet to itself.  It may
+   never be assigned to any physical interface.   It is treated as
+   having link-local scope, and may be thought of as the link-local
+   unicast address of a virtual interface (typically called "the
+   loopback interface") to an imaginary link that goes nowhere.
+
+   The loopback address must not be used as the source address in IPv6
+   packets that are sent outside of a single node.  An IPv6 packet with
+   a destination address of loopback must never be sent outside of a
+   single node and must never be forwarded by an IPv6 router.  A packet
+   received on an interface with destination address of loopback must be
+   dropped.
+
+
+
+
+Hinden & Deering            Standards Track                     [Page 9]
+
+RFC 3513              IPv6 Addressing Architecture            April 2003
+
+
+2.5.4 Global Unicast Addresses
+
+   The general format for IPv6 global unicast addresses is as follows:
+
+   |         n bits         |   m bits  |       128-n-m bits         |
+   +------------------------+-----------+----------------------------+
+   | global routing prefix  | subnet ID |       interface ID         |
+   +------------------------+-----------+----------------------------+
+
+   where the global routing prefix is a (typically hierarchically-
+   structured) value assigned to a site (a cluster of subnets/links),
+   the subnet ID is an identifier of a link within the site, and the
+   interface ID is as defined in section 2.5.1.
+
+   All global unicast addresses other than those that start with binary
+   000 have a 64-bit interface ID field (i.e., n + m = 64), formatted as
+   described in section 2.5.1.  Global unicast addresses that start with
+   binary 000 have no such constraint on the size or structure of the
+   interface ID field.
+
+   Examples of global unicast addresses that start with binary 000 are
+   the IPv6 address with embedded IPv4 addresses described in section
+   2.5.5 and the IPv6 address containing encoded NSAP addresses
+   specified in [NSAP].  An example of global addresses starting with a
+   binary value other than 000 (and therefore having a 64-bit interface
+   ID field) can be found in [AGGR].
+
+2.5.5 IPv6 Addresses with Embedded IPv4 Addresses
+
+   The IPv6 transition mechanisms [TRAN] include a technique for hosts
+   and routers to dynamically tunnel IPv6 packets over IPv4 routing
+   infrastructure.  IPv6 nodes that use this technique are assigned
+   special IPv6 unicast addresses that carry a global IPv4 address in
+   the low-order 32 bits.  This type of address is termed an "IPv4-
+   compatible IPv6 address" and has the format:
+
+   |                80 bits               | 16 |      32 bits        |
+   +--------------------------------------+--------------------------+
+   |0000..............................0000|0000|    IPv4 address     |
+   +--------------------------------------+----+---------------------+
+
+   Note: The IPv4 address used in the "IPv4-compatible IPv6 address"
+   must be a globally-unique IPv4 unicast address.
+
+   A second type of IPv6 address which holds an embedded IPv4 address is
+   also defined.  This address type is used to represent the addresses
+   of IPv4 nodes as IPv6 addresses.  This type of address is termed an
+   "IPv4-mapped IPv6 address" and has the format:
+
+
+
+Hinden & Deering            Standards Track                    [Page 10]
+
+RFC 3513              IPv6 Addressing Architecture            April 2003
+
+
+   |                80 bits               | 16 |      32 bits        |
+   +--------------------------------------+--------------------------+
+   |0000..............................0000|FFFF|    IPv4 address     |
+   +--------------------------------------+----+---------------------+
+
+2.5.6 Local-Use IPv6 Unicast Addresses
+
+   There are two types of local-use unicast addresses defined.  These
+   are Link-Local and Site-Local.  The Link-Local is for use on a single
+   link and the Site-Local is for use in a single site.  Link-Local
+   addresses have the following format:
+
+   |   10     |
+   |  bits    |         54 bits         |          64 bits           |
+   +----------+-------------------------+----------------------------+
+   |1111111010|           0             |       interface ID         |
+   +----------+-------------------------+----------------------------+
+
+   Link-Local addresses are designed to be used for addressing on a
+   single link for purposes such as automatic address configuration,
+   neighbor discovery, or when no routers are present.
+
+   Routers must not forward any packets with link-local source or
+   destination addresses to other links.
+
+   Site-Local addresses have the following format:
+
+   |   10     |
+   |  bits    |         54 bits         |         64 bits            |
+   +----------+-------------------------+----------------------------+
+   |1111111011|        subnet ID        |       interface ID         |
+   +----------+-------------------------+----------------------------+
+
+   Site-local addresses are designed to be used for addressing inside of
+   a site without the need for a global prefix.  Although a subnet ID
+   may be up to 54-bits long, it is expected that globally-connected
+   sites will use the same subnet IDs for site-local and global
+   prefixes.
+
+   Routers must not forward any packets with site-local source or
+   destination addresses outside of the site.
+
+
+
+
+
+
+
+
+
+
+Hinden & Deering            Standards Track                    [Page 11]
+
+RFC 3513              IPv6 Addressing Architecture            April 2003
+
+
+2.6 Anycast Addresses
+
+   An IPv6 anycast address is an address that is assigned to more than
+   one interface (typically belonging to different nodes), with the
+   property that a packet sent to an anycast address is routed to the
+   "nearest" interface having that address, according to the routing
+   protocols' measure of distance.
+
+   Anycast addresses are allocated from the unicast address space, using
+   any of the defined unicast address formats.  Thus, anycast addresses
+   are syntactically indistinguishable from unicast addresses.  When a
+   unicast address is assigned to more than one interface, thus turning
+   it into an anycast address, the nodes to which the address is
+   assigned must be explicitly configured to know that it is an anycast
+   address.
+
+   For any assigned anycast address, there is a longest prefix P of that
+   address that identifies the topological region in which all
+   interfaces belonging to that anycast address reside.  Within the
+   region identified by P, the anycast address must be maintained as a
+   separate entry in the routing system (commonly referred to as a "host
+   route"); outside the region identified by P, the anycast address may
+   be aggregated into the routing entry for prefix P.
+
+   Note that in the worst case, the prefix P of an anycast set may be
+   the null prefix, i.e., the members of the set may have no topological
+   locality.  In that case, the anycast address must be maintained as a
+   separate routing entry throughout the entire internet, which presents
+   a severe scaling limit on how many such "global" anycast sets may be
+   supported.  Therefore, it is expected that support for global anycast
+   sets may be unavailable or very restricted.
+
+   One expected use of anycast addresses is to identify the set of
+   routers belonging to an organization providing internet service.
+   Such addresses could be used as intermediate addresses in an IPv6
+   Routing header, to cause a packet to be delivered via a particular
+   service provider or sequence of service providers.
+
+   Some other possible uses are to identify the set of routers attached
+   to a particular subnet, or the set of routers providing entry into a
+   particular routing domain.
+
+   There is little experience with widespread, arbitrary use of internet
+   anycast addresses, and some known complications and hazards when
+   using them in their full generality [ANYCST].  Until more experience
+   has been gained and solutions are specified, the following
+   restrictions are imposed on IPv6 anycast addresses:
+
+
+
+
+Hinden & Deering            Standards Track                    [Page 12]
+
+RFC 3513              IPv6 Addressing Architecture            April 2003
+
+
+   o  An anycast address must not be used as the source address of an
+      IPv6 packet.
+
+   o  An anycast address must not be assigned to an IPv6 host, that is,
+      it may be assigned to an IPv6 router only.
+
+2.6.1 Required Anycast Address
+
+   The Subnet-Router anycast address is predefined.  Its format is as
+   follows:
+
+   |                         n bits                 |   128-n bits   |
+   +------------------------------------------------+----------------+
+   |                   subnet prefix                | 00000000000000 |
+   +------------------------------------------------+----------------+
+
+   The "subnet prefix" in an anycast address is the prefix which
+   identifies a specific link.  This anycast address is syntactically
+   the same as a unicast address for an interface on the link with the
+   interface identifier set to zero.
+
+   Packets sent to the Subnet-Router anycast address will be delivered
+   to one router on the subnet.  All routers are required to support the
+   Subnet-Router anycast addresses for the subnets to which they have
+   interfaces.
+
+   The subnet-router anycast address is intended to be used for
+   applications where a node needs to communicate with any one of the
+   set of routers.
+
+2.7 Multicast Addresses
+
+   An IPv6 multicast address is an identifier for a group of interfaces
+   (typically on different nodes).  An interface may belong to any
+   number of multicast groups.  Multicast addresses have the following
+   format:
+
+   |   8    |  4 |  4 |                  112 bits                   |
+   +------ -+----+----+---------------------------------------------+
+   |11111111|flgs|scop|                  group ID                   |
+   +--------+----+----+---------------------------------------------+
+
+         binary 11111111 at the start of the address identifies the
+         address as being a multicast address.
+
+                                       +-+-+-+-+
+         flgs is a set of 4 flags:     |0|0|0|T|
+                                       +-+-+-+-+
+
+
+
+Hinden & Deering            Standards Track                    [Page 13]
+
+RFC 3513              IPv6 Addressing Architecture            April 2003
+
+
+            The high-order 3 flags are reserved, and must be initialized
+            to 0.
+
+            T = 0 indicates a permanently-assigned ("well-known")
+            multicast address, assigned by the Internet Assigned Number
+            Authority (IANA).
+
+            T = 1 indicates a non-permanently-assigned ("transient")
+            multicast address.
+
+         scop is a 4-bit multicast scope value used to limit the scope
+         of the multicast group.  The values are:
+
+            0  reserved
+            1  interface-local scope
+            2  link-local scope
+            3  reserved
+            4  admin-local scope
+            5  site-local scope
+            6  (unassigned)
+            7  (unassigned)
+            8  organization-local scope
+            9  (unassigned)
+            A  (unassigned)
+            B  (unassigned)
+            C  (unassigned)
+            D  (unassigned)
+            E  global scope
+            F  reserved
+
+            interface-local scope spans only a single interface on a
+            node, and is useful only for loopback transmission of
+            multicast.
+
+            link-local and site-local multicast scopes span the same
+            topological regions as the corresponding unicast scopes.
+
+            admin-local scope is the smallest scope that must be
+            administratively configured, i.e., not automatically derived
+            from physical connectivity or other, non- multicast-related
+            configuration.
+
+            organization-local scope is intended to span multiple sites
+            belonging to a single organization.
+
+            scopes labeled "(unassigned)" are available for
+            administrators to define additional multicast regions.
+
+
+
+
+Hinden & Deering            Standards Track                    [Page 14]
+
+RFC 3513              IPv6 Addressing Architecture            April 2003
+
+
+         group ID identifies the multicast group, either permanent or
+         transient, within the given scope.
+
+   The "meaning" of a permanently-assigned multicast address is
+   independent of the scope value.  For example, if the "NTP servers
+   group" is assigned a permanent multicast address with a group ID of
+   101 (hex), then:
+
+      FF01:0:0:0:0:0:0:101 means all NTP servers on the same interface
+      (i.e., the same node) as the sender.
+
+      FF02:0:0:0:0:0:0:101 means all NTP servers on the same link as the
+      sender.
+
+      FF05:0:0:0:0:0:0:101 means all NTP servers in the same site as the
+      sender.
+
+      FF0E:0:0:0:0:0:0:101 means all NTP servers in the internet.
+
+   Non-permanently-assigned multicast addresses are meaningful only
+   within a given scope.  For example, a group identified by the non-
+   permanent, site-local multicast address FF15:0:0:0:0:0:0:101 at one
+   site bears no relationship to a group using the same address at a
+   different site, nor to a non-permanent group using the same group ID
+   with different scope, nor to a permanent group with the same group
+   ID.
+
+   Multicast addresses must not be used as source addresses in IPv6
+   packets or appear in any Routing header.
+
+   Routers must not forward any multicast packets beyond of the scope
+   indicated by the scop field in the destination multicast address.
+
+   Nodes must not originate a packet to a multicast address whose scop
+   field contains the reserved value 0; if such a packet is received, it
+   must be silently dropped.  Nodes should not originate a packet to a
+   multicast address whose scop field contains the reserved value F; if
+   such a packet is sent or received, it must be treated the same as
+   packets destined to a global (scop E) multicast address.
+
+2.7.1 Pre-Defined Multicast Addresses
+
+   The following well-known multicast addresses are pre-defined.  The
+   group ID's defined in this section are defined for explicit scope
+   values.
+
+   Use of these group IDs for any other scope values, with the T flag
+   equal to 0, is not allowed.
+
+
+
+Hinden & Deering            Standards Track                    [Page 15]
+
+RFC 3513              IPv6 Addressing Architecture            April 2003
+
+
+      Reserved Multicast Addresses:   FF00:0:0:0:0:0:0:0
+                                      FF01:0:0:0:0:0:0:0
+                                      FF02:0:0:0:0:0:0:0
+                                      FF03:0:0:0:0:0:0:0
+                                      FF04:0:0:0:0:0:0:0
+                                      FF05:0:0:0:0:0:0:0
+                                      FF06:0:0:0:0:0:0:0
+                                      FF07:0:0:0:0:0:0:0
+                                      FF08:0:0:0:0:0:0:0
+                                      FF09:0:0:0:0:0:0:0
+                                      FF0A:0:0:0:0:0:0:0
+                                      FF0B:0:0:0:0:0:0:0
+                                      FF0C:0:0:0:0:0:0:0
+                                      FF0D:0:0:0:0:0:0:0
+                                      FF0E:0:0:0:0:0:0:0
+                                      FF0F:0:0:0:0:0:0:0
+
+   The above multicast addresses are reserved and shall never be
+   assigned to any multicast group.
+
+      All Nodes Addresses:    FF01:0:0:0:0:0:0:1
+                              FF02:0:0:0:0:0:0:1
+
+   The above multicast addresses identify the group of all IPv6 nodes,
+   within scope 1 (interface-local) or 2 (link-local).
+
+      All Routers Addresses:   FF01:0:0:0:0:0:0:2
+                               FF02:0:0:0:0:0:0:2
+                               FF05:0:0:0:0:0:0:2
+
+   The above multicast addresses identify the group of all IPv6 routers,
+   within scope 1 (interface-local), 2 (link-local), or 5 (site-local).
+
+      Solicited-Node Address:  FF02:0:0:0:0:1:FFXX:XXXX
+
+   Solicited-node multicast address are computed as a function of a
+   node's unicast and anycast addresses.  A solicited-node multicast
+   address is formed by taking the low-order 24 bits of an address
+   (unicast or anycast) and appending those bits to the prefix
+   FF02:0:0:0:0:1:FF00::/104 resulting in a multicast address in the
+   range
+
+      FF02:0:0:0:0:1:FF00:0000
+
+   to
+
+      FF02:0:0:0:0:1:FFFF:FFFF
+
+
+
+
+Hinden & Deering            Standards Track                    [Page 16]
+
+RFC 3513              IPv6 Addressing Architecture            April 2003
+
+
+   For example, the solicited node multicast address corresponding to
+   the IPv6 address 4037::01:800:200E:8C6C is FF02::1:FF0E:8C6C.  IPv6
+   addresses that differ only in the high-order bits, e.g., due to
+   multiple high-order prefixes associated with different aggregations,
+   will map to the same solicited-node address thereby, reducing the
+   number of multicast addresses a node must join.
+
+   A node is required to compute and join (on the appropriate interface)
+   the associated Solicited-Node multicast addresses for every unicast
+   and anycast address it is assigned.
+
+2.8 A Node's Required Addresses
+
+   A host is required to recognize the following addresses as
+   identifying itself:
+
+      o  Its required Link-Local Address for each interface.
+      o  Any additional Unicast and Anycast Addresses that have been
+         configured for the node's interfaces (manually or
+         automatically).
+      o  The loopback address.
+      o  The All-Nodes Multicast Addresses defined in section 2.7.1.
+      o  The Solicited-Node Multicast Address for each of its unicast
+         and anycast addresses.
+      o  Multicast Addresses of all other groups to which the node
+         belongs.
+
+   A router is required to recognize all addresses that a host is
+   required to recognize, plus the following addresses as identifying
+   itself:
+
+      o  The Subnet-Router Anycast Addresses for all interfaces for
+         which it is configured to act as a router.
+      o  All other Anycast Addresses with which the router has been
+         configured.
+      o  The All-Routers Multicast Addresses defined in section 2.7.1.
+
+3. Security Considerations
+
+   IPv6 addressing documents do not have any direct impact on Internet
+   infrastructure security.  Authentication of IPv6 packets is defined
+   in [AUTH].
+
+
+
+
+
+
+
+
+
+Hinden & Deering            Standards Track                    [Page 17]
+
+RFC 3513              IPv6 Addressing Architecture            April 2003
+
+
+4. IANA Considerations
+
+   The table and notes at http://www.isi.edu/in-
+   notes/iana/assignments/ipv6-address-space.txt should be replaced with
+   the following:
+
+   INTERNET PROTOCOL VERSION 6 ADDRESS SPACE
+
+   The initial assignment of IPv6 address space is as follows:
+
+   Allocation                            Prefix         Fraction of
+                                         (binary)       Address Space
+   -----------------------------------   --------       -------------
+   Unassigned (see Note 1 below)         0000 0000      1/256
+   Unassigned                            0000 0001      1/256
+   Reserved for NSAP Allocation          0000 001       1/128 [RFC1888]
+   Unassigned                            0000 01        1/64
+   Unassigned                            0000 1         1/32
+   Unassigned                            0001           1/16
+   Global Unicast                        001            1/8   [RFC2374]
+   Unassigned                            010            1/8
+   Unassigned                            011            1/8
+   Unassigned                            100            1/8
+   Unassigned                            101            1/8
+   Unassigned                            110            1/8
+   Unassigned                            1110           1/16
+   Unassigned                            1111 0         1/32
+   Unassigned                            1111 10        1/64
+   Unassigned                            1111 110       1/128
+   Unassigned                            1111 1110 0    1/512
+   Link-Local Unicast Addresses          1111 1110 10   1/1024
+   Site-Local Unicast Addresses          1111 1110 11   1/1024
+   Multicast Addresses                   1111 1111      1/256
+
+   Notes:
+
+   1. The "unspecified address", the "loopback address", and the IPv6
+      Addresses with Embedded IPv4 Addresses are assigned out of the
+      0000 0000 binary prefix space.
+
+   2. For now, IANA should limit its allocation of IPv6 unicast address
+      space to the range of addresses that start with binary value 001.
+      The rest of the global unicast address space (approximately 85% of
+      the IPv6 address space) is reserved for future definition and use,
+      and is not to be assigned by IANA at this time.
+
+
+
+
+
+
+Hinden & Deering            Standards Track                    [Page 18]
+
+RFC 3513              IPv6 Addressing Architecture            April 2003
+
+
+5.  References
+
+5.1  Normative References
+
+   [IPV6]    Deering, S. and R. Hinden, "Internet Protocol, Version 6
+             (IPv6) Specification", RFC 2460, December 1998.
+
+   [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
+             3", BCP 9 , RFC 2026, October 1996.
+
+5.2  Informative References
+
+   [ANYCST]  Partridge, C., Mendez, T. and W. Milliken, "Host Anycasting
+             Service", RFC 1546, November 1993.
+
+   [AUTH]    Kent, S. and R. Atkinson, "IP Authentication Header", RFC
+             2402, November 1998.
+
+   [AGGR]    Hinden, R., O'Dell, M. and S. Deering, "An Aggregatable
+             Global Unicast Address Format", RFC 2374, July 1998.
+
+   [CIDR]    Fuller, V., Li, T., Yu, J. and K. Varadhan, "Classless
+             Inter-Domain Routing (CIDR): An Address Assignment and
+             Aggregation Strategy", RFC 1519, September 1993.
+
+   [ETHER]   Crawford, M., "Transmission of IPv6 Packets over Ethernet
+             Networks", RFC 2464, December 1998.
+
+   [EUI64]   IEEE, "Guidelines for 64-bit Global Identifier (EUI-64)
+             Registration Authority",
+             http://standards.ieee.org/regauth/oui/tutorials/EUI64.html,
+             March 1997.
+
+   [FDDI]    Crawford, M., "Transmission of IPv6 Packets over FDDI
+             Networks", RFC 2467, December 1998.
+
+   [MASGN]   Hinden, R. and S. Deering, "IPv6 Multicast Address
+             Assignments", RFC 2375, July 1998.
+
+   [NSAP]    Bound, J., Carpenter, B., Harrington, D., Houldsworth, J.
+             and A. Lloyd, "OSI NSAPs and IPv6", RFC 1888, August 1996.
+
+   [PRIV]    Narten, T. and R. Draves, "Privacy Extensions for Stateless
+             Address Autoconfiguration in IPv6", RFC 3041, January 2001.
+
+   [TOKEN]   Crawford, M., Narten, T. and S. Thomas, "Transmission of
+             IPv6 Packets over Token Ring Networks", RFC 2470, December
+             1998.
+
+
+
+Hinden & Deering            Standards Track                    [Page 19]
+
+RFC 3513              IPv6 Addressing Architecture            April 2003
+
+
+   [TRAN]    Gilligan, R. and E. Nordmark, "Transition Mechanisms for
+             IPv6 Hosts and Routers", RFC 2893, August 2000.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hinden & Deering            Standards Track                    [Page 20]
+
+RFC 3513              IPv6 Addressing Architecture            April 2003
+
+
+APPENDIX A: Creating Modified EUI-64 format Interface Identifiers
+
+   Depending on the characteristics of a specific link or node there are
+   a number of approaches for creating Modified EUI-64 format interface
+   identifiers.  This appendix describes some of these approaches.
+
+Links or Nodes with IEEE EUI-64 Identifiers
+
+   The only change needed to transform an IEEE EUI-64 identifier to an
+   interface identifier is to invert the "u" (universal/local) bit.  For
+   example, a globally unique IEEE EUI-64 identifier of the form:
+
+   |0              1|1              3|3              4|4              6|
+   |0              5|6              1|2              7|8              3|
+   +----------------+----------------+----------------+----------------+
+   |cccccc0gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|mmmmmmmmmmmmmmmm|
+   +----------------+----------------+----------------+----------------+
+
+   where "c" are the bits of the assigned company_id, "0" is the value
+   of the universal/local bit to indicate global scope, "g" is
+   individual/group bit, and "m" are the bits of the manufacturer-
+   selected extension identifier.  The IPv6 interface identifier would
+   be of the form:
+
+   |0              1|1              3|3              4|4              6|
+   |0              5|6              1|2              7|8              3|
+   +----------------+----------------+----------------+----------------+
+   |cccccc1gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|mmmmmmmmmmmmmmmm|
+   +----------------+----------------+----------------+----------------+
+
+   The only change is inverting the value of the universal/local bit.
+
+Links or Nodes with IEEE 802 48 bit MAC's
+
+   [EUI64] defines a method to create a IEEE EUI-64 identifier from an
+   IEEE 48bit MAC identifier.  This is to insert two octets, with
+   hexadecimal values of 0xFF and 0xFE, in the middle of the 48 bit MAC
+   (between the company_id and vendor supplied id).  For example, the 48
+   bit IEEE MAC with global scope:
+
+
+
+
+
+
+
+
+
+
+
+
+Hinden & Deering            Standards Track                    [Page 21]
+
+RFC 3513              IPv6 Addressing Architecture            April 2003
+
+
+   |0              1|1              3|3              4|
+   |0              5|6              1|2              7|
+   +----------------+----------------+----------------+
+   |cccccc0gcccccccc|ccccccccmmmmmmmm|mmmmmmmmmmmmmmmm|
+   +----------------+----------------+----------------+
+
+   where "c" are the bits of the assigned company_id, "0" is the value
+   of the universal/local bit to indicate global scope, "g" is
+   individual/group bit, and "m" are the bits of the manufacturer-
+   selected extension identifier.  The interface identifier would be of
+   the form:
+
+   |0              1|1              3|3              4|4              6|
+   |0              5|6              1|2              7|8              3|
+   +----------------+----------------+----------------+----------------+
+   |cccccc1gcccccccc|cccccccc11111111|11111110mmmmmmmm|mmmmmmmmmmmmmmmm|
+   +----------------+----------------+----------------+----------------+
+
+   When IEEE 802 48bit MAC addresses are available (on an interface or a
+   node), an implementation may use them to create interface identifiers
+   due to their availability and uniqueness properties.
+
+Links with Other Kinds of Identifiers
+
+   There are a number of types of links that have link-layer interface
+   identifiers other than IEEE EIU-64 or IEEE 802 48-bit MACs.  Examples
+   include LocalTalk and Arcnet.  The method to create an Modified EUI-
+   64 format identifier is to take the link identifier (e.g., the
+   LocalTalk 8 bit node identifier) and zero fill it to the left.  For
+   example, a LocalTalk 8 bit node identifier of hexadecimal value 0x4F
+   results in the following interface identifier:
+
+   |0              1|1              3|3              4|4              6|
+   |0              5|6              1|2              7|8              3|
+   +----------------+----------------+----------------+----------------+
+   |0000000000000000|0000000000000000|0000000000000000|0000000001001111|
+   +----------------+----------------+----------------+----------------+
+
+   Note that this results in the universal/local bit set to "0" to
+   indicate local scope.
+
+Links without Identifiers
+
+   There are a number of links that do not have any type of built-in
+   identifier.  The most common of these are serial links and configured
+   tunnels.  Interface identifiers must be chosen that are unique within
+   a subnet-prefix.
+
+
+
+
+Hinden & Deering            Standards Track                    [Page 22]
+
+RFC 3513              IPv6 Addressing Architecture            April 2003
+
+
+   When no built-in identifier is available on a link the preferred
+   approach is to use a global interface identifier from another
+   interface or one which is assigned to the node itself.  When using
+   this approach no other interface connecting the same node to the same
+   subnet-prefix may use the same identifier.
+
+   If there is no global interface identifier available for use on the
+   link the implementation needs to create a local-scope interface
+   identifier.  The only requirement is that it be unique within a
+   subnet prefix.  There are many possible approaches to select a
+   subnet-prefix-unique interface identifier.  These include:
+
+      Manual Configuration
+      Node Serial Number
+      Other node-specific token
+
+   The subnet-prefix-unique interface identifier should be generated in
+   a manner that it does not change after a reboot of a node or if
+   interfaces are added or deleted from the node.
+
+   The selection of the appropriate algorithm is link and implementation
+   dependent.  The details on forming interface identifiers are defined
+   in the appropriate "IPv6 over <link>" specification.  It is strongly
+   recommended that a collision detection algorithm be implemented as
+   part of any automatic algorithm.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hinden & Deering            Standards Track                    [Page 23]
+
+RFC 3513              IPv6 Addressing Architecture            April 2003
+
+
+APPENDIX B: Changes from RFC-2373
+
+   The following changes were made from RFC-2373 "IP Version 6
+   Addressing Architecture":
+
+   -  Clarified text in section 2.2 to allow "::" to represent one or
+      more groups of 16 bits of zeros.
+   -  Changed uniqueness requirement of Interface Identifiers from
+      unique on a link to unique within a subnet prefix.  Also added a
+      recommendation that the same interface identifier not be assigned
+      to different machines on a link.
+   -  Change site-local format to make the subnet ID field 54-bit long
+      and remove the 38-bit zero's field.
+   -  Added description of multicast scop values and rules to handle the
+      reserved scop value 0.
+   -  Revised sections 2.4 and 2.5.6 to simplify and clarify how
+      different address types  are identified.  This was done to insure
+      that implementations do not build in any knowledge about global
+      unicast format prefixes.  Changes include:
+         o  Removed Format Prefix (FP) terminology
+         o  Revised list of address types to only include exceptions to
+            global unicast and a singe entry that identifies everything
+            else as Global Unicast.
+         o  Removed list of defined prefix exceptions from section 2.5.6
+            as it is now the main part of section 2.4.
+   -  Clarified text relating to EUI-64 identifiers to distinguish
+      between IPv6's "Modified EUI-64 format" identifiers and IEEE EUI-
+      64 identifiers.
+   -  Combined the sections on the Global Unicast Addresses and NSAP
+      Addresses into a single section on Global Unicast Addresses,
+      generalized the Global Unicast format, and cited [AGGR] and [NSAP]
+      as examples.
+   -  Reordered sections 2.5.4 and 2.5.5.
+   -  Removed section 2.7.2 Assignment of New IPv6 Multicast Addresses
+      because this is being redefined elsewhere.
+   -  Added an IANA considerations section that updates the IANA IPv6
+      address allocations and documents the NSAP and AGGR allocations.
+   -  Added clarification that the "IPv4-compatible IPv6 address" must
+      use global IPv4 unicast addresses.
+   -  Divided references in to normative and non-normative sections.
+   -  Added reference to [PRIV] in section 2.5.1
+   -  Added clarification that routers must not forward multicast
+      packets outside of the scope indicated in the multicast address.
+   -  Added clarification that routers must not forward packets with
+       source address of the unspecified address.
+   -  Added clarification that routers must drop packets received on an
+      interface with destination address of loopback.
+   -  Clarified the definition of IPv4-mapped addresses.
+
+
+
+Hinden & Deering            Standards Track                    [Page 24]
+
+RFC 3513              IPv6 Addressing Architecture            April 2003
+
+
+   -  Removed the ABNF Description of Text Representations Appendix.
+   -  Removed the address block reserved for IPX addresses.
+   -  Multicast scope changes:
+         o  Changed name of scope value 1 from "node-local" to
+            "interface-local"
+         o  Defined scope value 4 as "admin-local"
+   -  Corrected reference to RFC1933 and updated references.
+   -  Many small changes to clarify and make the text more consistent.
+
+Authors' Addresses
+
+   Robert M. Hinden
+   Nokia
+   313 Fairchild Drive
+   Mountain View, CA 94043
+   USA
+
+   Phone: +1 650 625-2004
+   EMail: hinden@iprg.nokia.com
+
+
+   Stephen E. Deering
+   Cisco Systems, Inc.
+   170 West Tasman Drive
+   San Jose, CA 95134-1706
+   USA
+
+   Phone: +1 408 527-8213
+   EMail: deering@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hinden & Deering            Standards Track                    [Page 25]
+
+RFC 3513              IPv6 Addressing Architecture            April 2003
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hinden & Deering            Standards Track                    [Page 26]
+
diff --git a/doc/rfc/rfc3596.txt b/doc/rfc/rfc3596.txt
new file mode 100644
index 0000000..f65690c
--- /dev/null
+++ b/doc/rfc/rfc3596.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Network Working Group                                         S. Thomson
+Request for Comments: 3596                                         Cisco
+Obsoletes: 3152, 1886                                         C. Huitema
+Category: Standards Track                                      Microsoft
+                                                              V. Ksinant
+                                                                   6WIND
+                                                              M. Souissi
+                                                                   AFNIC
+                                                            October 2003
+
+
+                 DNS Extensions to Support IP Version 6
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+Abstract
+
+   This document defines the changes that need to be made to the Domain
+   Name System (DNS) to support hosts running IP version 6 (IPv6).  The
+   changes include a resource record type to store an IPv6 address, a
+   domain to support lookups based on an IPv6 address, and updated
+   definitions of existing query types that return Internet addresses as
+   part of additional section processing.  The extensions are designed
+   to be compatible with existing applications and, in particular, DNS
+   implementations themselves.
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
+   2.  New resource record definition and domain. . . . . . . . . . .  2
+       2.1.  AAAA record type . . . . . . . . . . . . . . . . . . . .  3
+       2.2.  AAAA data format . . . . . . . . . . . . . . . . . . . .  3
+       2.3.  AAAA query . . . . . . . . . . . . . . . . . . . . . . .  3
+       2.4.  Textual format of AAAA records . . . . . . . . . . . . .  3
+       2.5.  IP6.ARPA domain. . . . . . . . . . . . . . . . . . . . .  3
+   3.  Modifications to existing query types. . . . . . . . . . . . .  4
+   4.  Security Considerations. . . . . . . . . . . . . . . . . . . .  4
+   5.  IANA Considerations. . . . . . . . . . . . . . . . . . . . . .  4
+
+
+
+Thomson, et al.             Standards Track                     [Page 1]
+
+RFC 3596             DNS Extensions to Support IPv6         October 2003
+
+
+   6.  Intellectual Property Statement. . . . . . . . . . . . . . . .  4
+   Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . . .  5
+   Appendix A: Changes from RFC 1886. . . . . . . . . . . . . . . . .  6
+   Normative References . . . . . . . . . . . . . . . . . . . . . . .  6
+   Informative References . . . . . . . . . . . . . . . . . . . . . .  6
+   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .  7
+   Full Copyright Statement . . . . . . . . . . . . . . . . . . . . .  8
+
+1. Introduction
+
+   Current support for the storage of Internet addresses in the Domain
+   Name System (DNS) [1,2] cannot easily be extended to support IPv6
+   addresses [3] since applications assume that address queries return
+   32-bit IPv4 addresses only.
+
+   To support the storage of IPv6 addresses in the DNS, this document
+   defines the following extensions:
+
+      o A resource record type is defined to map a domain name to an
+        IPv6 address.
+
+      o A domain is defined to support lookups based on address.
+
+      o Existing queries that perform additional section processing to
+        locate IPv4 addresses are redefined to perform additional
+        section processing on both IPv4 and IPv6 addresses.
+
+   The changes are designed to be compatible with existing software.
+   The existing support for IPv4 addresses is retained.  Transition
+   issues related to the co-existence of both IPv4 and IPv6 addresses in
+   the DNS are discussed in [4].
+
+   The IP protocol version used for querying resource records is
+   independent of the protocol version of the resource records; e.g.,
+   IPv4 transport can be used to query IPv6 records and vice versa.
+
+   This document combines RFC 1886 [5] and changes to RFC 1886 made by
+   RFC 3152 [6], obsoleting both.  Changes mainly consist in replacing
+   the IP6.INT domain by IP6.ARPA as defined in RFC 3152.
+
+2. New resource record definition and domain
+
+   A record type is defined to store a host's IPv6 address.  A host that
+   has more than one IPv6 address must have more than one such record.
+
+
+
+
+
+
+
+Thomson, et al.             Standards Track                     [Page 2]
+
+RFC 3596             DNS Extensions to Support IPv6         October 2003
+
+
+2.1 AAAA record type
+
+   The AAAA resource record type is a record specific to the Internet
+   class that stores a single IPv6 address.
+
+   The IANA assigned value of the type is 28 (decimal).
+
+2.2 AAAA data format
+
+   A 128 bit IPv6 address is encoded in the data portion of an AAAA
+   resource record in network byte order (high-order byte first).
+
+2.3 AAAA query
+
+   An AAAA query for a specified domain name in the Internet class
+   returns all associated AAAA resource records in the answer section of
+   a response.
+
+   A type AAAA query does not trigger additional section processing.
+
+2.4 Textual format of AAAA records
+
+   The textual representation of the data portion of the AAAA resource
+   record used in a master database file is the textual representation
+   of an IPv6 address as defined in [3].
+
+2.5 IP6.ARPA Domain
+
+   A special domain is defined to look up a record given an IPv6
+   address.  The intent of this domain is to provide a way of mapping an
+   IPv6 address to a host name, although it may be used for other
+   purposes as well.  The domain is rooted at IP6.ARPA.
+
+   An IPv6 address is represented as a name in the IP6.ARPA domain by a
+   sequence of nibbles separated by dots with the suffix ".IP6.ARPA".
+   The sequence of nibbles is encoded in reverse order, i.e., the
+   low-order nibble is encoded first, followed by the next low-order
+   nibble and so on.  Each nibble is represented by a hexadecimal digit.
+   For example, the reverse lookup domain name corresponding to the
+   address
+
+       4321:0:1:2:3:4:567:89ab
+
+   would be
+
+   b.a.9.8.7.6.5.0.4.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.0.0.0.0.1.2.3.4.IP6.
+                                                                  ARPA.
+
+
+
+
+Thomson, et al.             Standards Track                     [Page 3]
+
+RFC 3596             DNS Extensions to Support IPv6         October 2003
+
+
+3. Modifications to existing query types
+
+   All existing query types that perform type A additional section
+   processing, i.e., name server (NS), location of services (SRV) and
+   mail exchange (MX) query types, must be redefined to perform both
+   type A and type AAAA additional section processing.  These
+   definitions mean that a name server must add any relevant IPv4
+   addresses and any relevant IPv6 addresses available locally to the
+   additional section of a response when processing any one of the above
+   queries.
+
+4. Security Considerations
+
+   Any information obtained from the DNS must be regarded as unsafe
+   unless techniques specified in [7] or [8] are used.  The definitions
+   of the AAAA record type and of the IP6.ARPA domain do not change the
+   model for use of these techniques.
+
+   So, this specification is not believed to cause any new security
+   problems, nor to solve any existing ones.
+
+5. IANA Considerations
+
+   There are no IANA assignments to be performed.
+
+6. Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   intellectual property or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; neither does it represent that it
+   has made any effort to identify any such rights.  Information on the
+   IETF's procedures with respect to rights in standards-track and
+   standards-related documentation can be found in BCP-11.  Copies of
+   claims of rights made available for publication and any assurances of
+   licenses to be made available, or the result of an attempt made to
+   obtain a general license or permission for the use of such
+   proprietary rights by implementors or users of this specification can
+   be obtained from the IETF Secretariat.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights which may cover technology that may be required to practice
+   this standard.  Please address the information to the IETF Executive
+   Director.
+
+
+
+
+
+Thomson, et al.             Standards Track                     [Page 4]
+
+RFC 3596             DNS Extensions to Support IPv6         October 2003
+
+
+Acknowledgments
+
+   Vladimir Ksinant and Mohsen Souissi would like to thank Sebastien
+   Barbin (IRISA), Luc Beloeil (France Telecom R&D), Jean-Mickael Guerin
+   (6WIND), Vincent Levigneron (AFNIC), Alain Ritoux (6WIND), Frederic
+   Roudaut (IRISA) and G6 group for their help during the RFC 1886
+   Interop tests sessions.
+
+   Many thanks to Alain Durand and Olafur Gudmundsson for their support.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Thomson, et al.             Standards Track                     [Page 5]
+
+RFC 3596             DNS Extensions to Support IPv6         October 2003
+
+
+Appendix A: Changes from RFC 1886
+
+   The following changes were made from RFC 1886 "DNS Extensions to
+   support IP version 6":
+
+   - Replaced the "IP6.INT" domain by "IP6.ARPA".
+   - Mentioned SRV query types in section 3 "MODIFICATIONS TO
+     EXISTING QUERY TYPES"
+   - Added security considerations.
+   - Updated references :
+     * From RFC 1884 to RFC 3513 (IP Version 6 Addressing
+       Architecture).
+     * From "work in progress" to RFC 2893 (Transition Mechanisms for
+       IPv6 Hosts and Routers).
+     * Added reference to RFC 1886, RFC 3152, RFC 2535 and RFC 2845.
+   - Updated document abstract
+   - Added table of contents
+   - Added full copyright statement
+   - Added IANA considerations section
+   - Added Intellectual Property Statement
+
+Normative References
+
+   [1]  Mockapetris, P., "Domain Names - Concepts and Facilities", STD
+        13, RFC 1034, November 1987.
+
+   [2]  Mockapetris, P., "Domain Names - Implementation and
+        Specification", STD 13, RFC 1035, November 1987.
+
+   [3]  Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6)
+        Addressing Architecture", RFC 3513, April 2003.
+
+Informative References
+
+   [4]  Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6
+        Hosts and Routers", RFC 2893, August 2000.
+
+   [5]  Thomson, S. and C. Huitema, "DNS Extensions to support IP
+        version 6", RFC 1886, December 1995.
+
+   [6]  Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152, August
+        2001.
+
+   [7]  Eastlake, D., "Domain Name System Security Extensions", RFC
+        2535, March 1999
+
+
+
+
+
+
+Thomson, et al.             Standards Track                     [Page 6]
+
+RFC 3596             DNS Extensions to Support IPv6         October 2003
+
+
+   [8]  Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
+        "Secret Key Transaction Authentication for DNS (TSIG)", RFC
+        2845, May 2000.
+
+Authors' Addresses
+
+   Susan Thomson
+   Cisco Systems
+   499 Thornall Street, 8th floor
+   Edison, NJ 08837
+
+   Phone: +1 732-635-3086
+   EMail:  sethomso@cisco.com
+
+
+   Christian Huitema
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA 98052-6399
+
+   EMail: huitema@microsoft.com
+
+
+   Vladimir Ksinant
+   6WIND S.A.
+   Immeuble Central Gare - Bat.C
+   1, place Charles de Gaulle
+   78180, Montigny-Le-Bretonneux - France
+
+   Phone: +33 1 39 30 92 36
+   EMail: vladimir.ksinant@6wind.com
+
+
+   Mohsen Souissi
+   AFNIC
+   Immeuble International
+   2, rue Stephenson,
+   78181, Saint-Quentin en Yvelines Cedex - France
+
+   Phone: +33 1 39 30 83 40
+   EMail: Mohsen.Souissi@nic.fr
+
+
+
+
+
+
+
+
+
+
+Thomson, et al.             Standards Track                     [Page 7]
+
+RFC 3596             DNS Extensions to Support IPv6         October 2003
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assignees.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Thomson, et al.             Standards Track                     [Page 8]
+
diff --git a/doc/rfc/rfc3597.txt b/doc/rfc/rfc3597.txt
new file mode 100644
index 0000000..19e9a55
--- /dev/null
+++ b/doc/rfc/rfc3597.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Network Working Group                                      A. Gustafsson
+Request for Comments: 3597                                  Nominum Inc.
+Category: Standards Track                                 September 2003
+
+
+           Handling of Unknown DNS Resource Record (RR) Types
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+Abstract
+
+   Extending the Domain Name System (DNS) with new Resource Record (RR)
+   types currently requires changes to name server software.  This
+   document specifies the changes necessary to allow future DNS
+   implementations to handle new RR types transparently.
+
+1.  Introduction
+
+   The DNS is designed to be extensible to support new services through
+   the introduction of new resource record (RR) types.  In practice,
+   deploying a new RR type currently requires changes to the name server
+   software not only at the authoritative DNS server that is providing
+   the new information and the client making use of it, but also at all
+   slave servers for the zone containing it, and in some cases also at
+   caching name servers and forwarders used by the client.
+
+   Because the deployment of new server software is slow and expensive,
+   the potential of the DNS in supporting new services has never been
+   fully realized.  This memo proposes changes to name servers and to
+   procedures for defining new RR types aimed at simplifying the future
+   deployment of new RR types.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC 2119].
+
+
+
+
+
+
+Gustafsson                  Standards Track                     [Page 1]
+
+RFC 3597            Handling of Unknown DNS RR Types      September 2003
+
+
+2.  Definition
+
+   An "RR of unknown type" is an RR whose RDATA format is not known to
+   the DNS implementation at hand, and whose type is not an assigned
+   QTYPE or Meta-TYPE as specified in [RFC 2929] (section 3.1) nor
+   within the range reserved in that section for assignment only to
+   QTYPEs and Meta-TYPEs.  Such an RR cannot be converted to a type-
+   specific text format, compressed, or otherwise handled in a type-
+   specific way.
+
+   In the case of a type whose RDATA format is class specific, an RR is
+   considered to be of unknown type when the RDATA format for that
+   combination of type and class is not known.
+
+3.  Transparency
+
+   To enable new RR types to be deployed without server changes, name
+   servers and resolvers MUST handle RRs of unknown type transparently.
+   That is, they must treat the RDATA section of such RRs as
+   unstructured binary data, storing and transmitting it without change
+   [RFC1123].
+
+   To ensure the correct operation of equality comparison (section 6)
+   and of the DNSSEC canonical form (section 7) when an RR type is known
+   to some but not all of the servers involved, servers MUST also
+   exactly preserve the RDATA of RRs of known type, except for changes
+   due to compression or decompression where allowed by section 4 of
+   this memo.  In particular, the character case of domain names that
+   are not subject to compression MUST be preserved.
+
+4.  Domain Name Compression
+
+   RRs containing compression pointers in the RDATA part cannot be
+   treated transparently, as the compression pointers are only
+   meaningful within the context of a DNS message.  Transparently
+   copying the RDATA into a new DNS message would cause the compression
+   pointers to point at the corresponding location in the new message,
+   which now contains unrelated data.  This would cause the compressed
+   name to be corrupted.
+
+   To avoid such corruption, servers MUST NOT compress domain names
+   embedded in the RDATA of types that are class-specific or not well-
+   known.  This requirement was stated in [RFC1123] without defining the
+   term "well-known"; it is hereby specified that only the RR types
+   defined in [RFC1035] are to be considered "well-known".
+
+
+
+
+
+
+Gustafsson                  Standards Track                     [Page 2]
+
+RFC 3597            Handling of Unknown DNS RR Types      September 2003
+
+
+   The specifications of a few existing RR types have explicitly allowed
+   compression contrary to this specification: [RFC2163] specified that
+   compression applies to the PX RR, and [RFC2535] allowed compression
+   in SIG RRs and NXT RRs records.  Since this specification disallows
+   compression in these cases, it is an update to [RFC2163] (section 4)
+   and [RFC2535] (sections 4.1.7 and 5.2).
+
+   Receiving servers MUST decompress domain names in RRs of well-known
+   type, and SHOULD also decompress RRs of type RP, AFSDB, RT, SIG, PX,
+   NXT, NAPTR, and SRV (although the current specification of the SRV RR
+   in [RFC2782] prohibits compression, [RFC2052] mandated it, and some
+   servers following that earlier specification are still in use).
+
+   Future specifications for new RR types that contain domain names
+   within their RDATA MUST NOT allow the use of name compression for
+   those names, and SHOULD explicitly state that the embedded domain
+   names MUST NOT be compressed.
+
+   As noted in [RFC1123], the owner name of an RR is always eligible for
+   compression.
+
+5.  Text Representation
+
+   In the "type" field of a master file line, an unknown RR type is
+   represented by the word "TYPE" immediately followed by the decimal RR
+   type number, with no intervening whitespace.  In the "class" field,
+   an unknown class is similarly represented as the word "CLASS"
+   immediately followed by the decimal class number.
+
+   This convention allows types and classes to be distinguished from
+   each other and from TTL values, allowing the "[<TTL>] [<class>]
+   <type> <RDATA>" and "[<class>] [<TTL>] <type> <RDATA>" forms of
+   [RFC1035] to both be unambiguously parsed.
+
+   The RDATA section of an RR of unknown type is represented as a
+   sequence of white space separated words as follows:
+
+      The special token \# (a backslash immediately followed by a hash
+      sign), which identifies the RDATA as having the generic encoding
+      defined herein rather than a traditional type-specific encoding.
+
+      An unsigned decimal integer specifying the RDATA length in octets.
+
+      Zero or more words of hexadecimal data encoding the actual RDATA
+      field, each containing an even number of hexadecimal digits.
+
+   If the RDATA is of zero length, the text representation contains only
+   the \# token and the single zero representing the length.
+
+
+
+Gustafsson                  Standards Track                     [Page 3]
+
+RFC 3597            Handling of Unknown DNS RR Types      September 2003
+
+
+   An implementation MAY also choose to represent some RRs of known type
+   using the above generic representations for the type, class and/or
+   RDATA, which carries the benefit of making the resulting master file
+   portable to servers where these types are unknown.  Using the generic
+   representation for the RDATA of an RR of known type can also be
+   useful in the case of an RR type where the text format varies
+   depending on a version, protocol, or similar field (or several)
+   embedded in the RDATA when such a field has a value for which no text
+   format is known, e.g., a LOC RR [RFC1876] with a VERSION other than
+   0.
+
+   Even though an RR of known type represented in the \# format is
+   effectively treated as an unknown type for the purpose of parsing the
+   RDATA text representation, all further processing by the server MUST
+   treat it as a known type and take into account any applicable type-
+   specific rules regarding compression, canonicalization, etc.
+
+   The following are examples of RRs represented in this manner,
+   illustrating various combinations of generic and type-specific
+   encodings for the different fields of the master file format:
+
+      a.example.   CLASS32     TYPE731         \# 6 abcd (
+                                               ef 01 23 45 )
+      b.example.   HS          TYPE62347       \# 0
+      e.example.   IN          A               \# 4 0A000001
+      e.example.   CLASS1      TYPE1           10.0.0.2
+
+6.  Equality Comparison
+
+   Certain DNS protocols, notably Dynamic Update [RFC2136], require RRs
+   to be compared for equality.  Two RRs of the same unknown type are
+   considered equal when their RDATA is bitwise equal.  To ensure that
+   the outcome of the comparison is identical whether the RR is known to
+   the server or not, specifications for new RR types MUST NOT specify
+   type-specific comparison rules.
+
+   This implies that embedded domain names, being included in the
+   overall bitwise comparison, are compared in a case-sensitive manner.
+
+   As a result, when a new RR type contains one or more embedded domain
+   names, it is possible to have multiple RRs owned by the same name
+   that differ only in the character case of the embedded domain
+   name(s).  This is similar to the existing possibility of multiple TXT
+   records differing only in character case, and not expected to cause
+   any problems in practice.
+
+
+
+
+
+
+Gustafsson                  Standards Track                     [Page 4]
+
+RFC 3597            Handling of Unknown DNS RR Types      September 2003
+
+
+7.  DNSSEC Canonical Form and Ordering
+
+   DNSSEC defines a canonical form and ordering for RRs [RFC2535]
+   (section 8.1).  In that canonical form, domain names embedded in the
+   RDATA are converted to lower case.
+
+   The downcasing is necessary to ensure the correctness of DNSSEC
+   signatures when case distinctions in domain names are lost due to
+   compression, but since it requires knowledge of the presence and
+   position of embedded domain names, it cannot be applied to unknown
+   types.
+
+   To ensure continued consistency of the canonical form of RR types
+   where compression is allowed, and for continued interoperability with
+   existing implementations that already implement the [RFC2535]
+   canonical form and apply it to their known RR types, the canonical
+   form remains unchanged for all RR types whose whose initial
+   publication as an RFC was prior to the initial publication of this
+   specification as an RFC (RFC 3597).
+
+   As a courtesy to implementors, it is hereby noted that the complete
+   set of such previously published RR types that contain embedded
+   domain names, and whose DNSSEC canonical form therefore involves
+   downcasing according to the DNS rules for character comparisons,
+   consists of the RR types NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR,
+   HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT, NAPTR, KX, SRV,
+   DNAME, and A6.
+
+   This document specifies that for all other RR types (whether treated
+   as unknown types or treated as known types according to an RR type
+   definition RFC more recent than RFC 3597), the canonical form is such
+   that no downcasing of embedded domain names takes place, and
+   otherwise identical to the canonical form specified in [RFC2535]
+   section 8.1.
+
+   Note that the owner name is always set to lower case according to the
+   DNS rules for character comparisons, regardless of the RR type.
+
+   The DNSSEC canonical RR ordering is as specified in [RFC2535] section
+   8.3, where the octet sequence is the canonical form as revised by
+   this specification.
+
+8.  Additional Section Processing
+
+   Unknown RR types cause no additional section processing.  Future RR
+   type specifications MAY specify type-specific additional section
+   processing rules, but any such processing MUST be optional as it can
+   only be performed by servers for which the RR type in case is known.
+
+
+
+Gustafsson                  Standards Track                     [Page 5]
+
+RFC 3597            Handling of Unknown DNS RR Types      September 2003
+
+
+9.  IANA Considerations
+
+   This document does not require any IANA actions.
+
+10.  Security Considerations
+
+   This specification is not believed to cause any new security
+   problems, nor to solve any existing ones.
+
+11.  Normative References
+
+   [RFC1034]   Mockapetris, P., "Domain Names - Concepts and
+               Facilities", STD 13, RFC 1034, November 1987.
+
+   [RFC1035]   Mockapetris, P., "Domain Names - Implementation and
+               Specifications", STD 13, RFC 1035, November 1987.
+
+   [RFC1123]   Braden, R., Ed., "Requirements for Internet Hosts --
+               Application and Support", STD 3, RFC 1123, October 1989.
+
+   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
+               Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2535]   Eastlake, D., "Domain Name System Security Extensions",
+               RFC 2535, March 1999.
+
+   [RFC2163]   Allocchio, C., "Using the Internet DNS to Distribute
+               MIXER Conformant Global Address Mapping (MCGAM)", RFC
+               2163, January 1998.
+
+   [RFC2929]   Eastlake, D., Brunner-Williams, E. and B. Manning,
+               "Domain Name System (DNS) IANA Considerations", BCP 42,
+               RFC 2929, September 2000.
+
+12.  Informative References
+
+   [RFC1876]   Davis, C., Vixie, P., Goodwin, T. and I. Dickinson, "A
+               Means for Expressing Location Information in the Domain
+               Name System", RFC 1876, January 1996.
+
+   [RFC2052]   Gulbrandsen, A. and P. Vixie, "A DNS RR for specifying
+               the location of services (DNS SRV)", RFC 2052, October
+               1996.
+
+   [RFC2136]   Vixie, P., Ed., Thomson, S., Rekhter, Y. and J. Bound,
+               "Dynamic Updates in the Domain Name System (DNS UPDATE)",
+               RFC 2136, April 1997.
+
+
+
+
+Gustafsson                  Standards Track                     [Page 6]
+
+RFC 3597            Handling of Unknown DNS RR Types      September 2003
+
+
+   [RFC2782]   Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
+               specifying the location of services (DNS SRV)", RFC 2782,
+               February 2000.
+
+13.  Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   intellectual property or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; neither does it represent that it
+   has made any effort to identify any such rights.  Information on the
+   IETF's procedures with respect to rights in standards-track and
+   standards-related documentation can be found in BCP-11.  Copies of
+   claims of rights made available for publication and any assurances of
+   licenses to be made available, or the result of an attempt made to
+   obtain a general license or permission for the use of such
+   proprietary rights by implementors or users of this specification can
+   be obtained from the IETF Secretariat.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights which may cover technology that may be required to practice
+   this standard.  Please address the information to the IETF Executive
+   Director.
+
+14.  Author's Address
+
+   Andreas Gustafsson
+   Nominum, Inc.
+   2385 Bay Rd
+   Redwood City, CA 94063
+   USA
+
+   Phone: +1 650 381 6004
+   EMail: gson@nominum.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gustafsson                  Standards Track                     [Page 7]
+
+RFC 3597            Handling of Unknown DNS RR Types      September 2003
+
+
+15.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assignees.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gustafsson                  Standards Track                     [Page 8]
+
diff --git a/doc/rfc/rfc3645.txt b/doc/rfc/rfc3645.txt
new file mode 100644
index 0000000..6126678
--- /dev/null
+++ b/doc/rfc/rfc3645.txt
@@ -0,0 +1,1459 @@
+
+
+
+
+
+
+Network Working Group                                            S. Kwan
+Request for Comments: 3645                                       P. Garg
+Updates: 2845                                                  J. Gilroy
+Category: Standards Track                                      L. Esibov
+                                                             J. Westhead
+                                                         Microsoft Corp.
+                                                                 R. Hall
+                                                     Lucent Technologies
+                                                            October 2003
+
+
+                 Generic Security Service Algorithm for
+        Secret Key Transaction Authentication for DNS (GSS-TSIG)
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+Abstract
+
+   The Secret Key Transaction Authentication for DNS (TSIG) protocol
+   provides transaction level authentication for DNS.  TSIG is
+   extensible through the definition of new algorithms.  This document
+   specifies an algorithm based on the Generic Security Service
+   Application Program Interface (GSS-API) (RFC2743).  This document
+   updates RFC 2845.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kwan, et al.                Standards Track                     [Page 1]
+
+RFC 3645                        GSS-TSIG                    October 2003
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
+   2.  Algorithm Overview . . . . . . . . . . . . . . . . . . . . . .  3
+       2.1.  GSS Details. . . . . . . . . . . . . . . . . . . . . . .  4
+       2.2.  Modifications to the TSIG protocol (RFC 2845). . . . . .  4
+   3.  Client Protocol Details. . . . . . . . . . . . . . . . . . . .  5
+       3.1.  Negotiating Context. . . . . . . . . . . . . . . . . . .  5
+           3.1.1.  Call GSS_Init_sec_context. . . . . . . . . . . . .  6
+           3.1.2.  Send TKEY Query to Server. . . . . . . . . . . . .  8
+           3.1.3.  Receive TKEY Query-Response from Server. . . . . .  8
+       3.2.  Context Established. . . . . . . . . . . . . . . . . . . 11
+           3.2.1.  Terminating a Context. . . . . . . . . . . . . . . 11
+   4.  Server Protocol Details. . . . . . . . . . . . . . . . . . . . 12
+       4.1.  Negotiating Context. . . . . . . . . . . . . . . . . . . 12
+           4.1.1.  Receive TKEY Query from Client . . . . . . . . . . 12
+           4.1.2.  Call GSS_Accept_sec_context. . . . . . . . . . . . 12
+           4.1.3.  Send TKEY Query-Response to Client . . . . . . . . 13
+       4.2.  Context Established. . . . . . . . . . . . . . . . . . . 15
+           4.2.1.  Terminating a Context. . . . . . . . . . . . . . . 15
+   5.  Sending and Verifying Signed Messages. . . . . . . . . . . . . 15
+       5.1.  Sending a Signed Message - Call GSS_GetMIC . . . . . . . 15
+       5.2.  Verifying a Signed Message - Call GSS_VerifyMIC. . . . . 16
+   6.  Example usage of GSS-TSIG algorithm. . . . . . . . . . . . . . 18
+   7.  Security Considerations. . . . . . . . . . . . . . . . . . . . 22
+   8.  IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 22
+   9.  Conformance. . . . . . . . . . . . . . . . . . . . . . . . . . 22
+   10. Intellectual Property Statement. . . . . . . . . . . . . . . . 23
+   11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23
+   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
+       12.1.  Normative References. . . . . . . . . . . . . . . . . . 24
+       12.2.  Informative References. . . . . . . . . . . . . . . . . 24
+   13. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25
+   14. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 26
+
+1.  Introduction
+
+   The Secret Key Transaction Authentication for DNS (TSIG) [RFC2845]
+   protocol was developed to provide a lightweight authentication and
+   integrity of messages between two DNS entities, such as client and
+   server or server and server.  TSIG can be used to protect dynamic
+   update messages, authenticate regular message or to off-load
+   complicated DNSSEC [RFC2535] processing from a client to a server and
+   still allow the client to be assured of the integrity of the answers.
+
+
+
+
+
+
+
+Kwan, et al.                Standards Track                     [Page 2]
+
+RFC 3645                        GSS-TSIG                    October 2003
+
+
+   The TSIG protocol [RFC2845] is extensible through the definition of
+   new algorithms.  This document specifies an algorithm based on the
+   Generic Security Service Application Program Interface (GSS-API)
+   [RFC2743].  GSS-API is a framework that provides an abstraction of
+   security to the application protocol developer.  The security
+   services offered can include authentication, integrity, and
+   confidentiality.
+
+   The GSS-API framework has several benefits:
+
+   *  Mechanism and protocol independence.  The underlying mechanisms
+      that realize the security services can be negotiated on the fly
+      and varied over time.  For example, a client and server MAY use
+      Kerberos [RFC1964] for one transaction, whereas that same server
+      MAY use SPKM [RFC2025] with a different client.
+
+   *  The protocol developer is removed from the responsibility of
+      creating and managing a security infrastructure.  For example, the
+      developer does not need to create new key distribution or key
+      management systems.  Instead the developer relies on the security
+      service mechanism to manage this on its behalf.
+
+   The scope of this document is limited to the description of an
+   authentication mechanism only.  It does not discuss and/or propose an
+   authorization mechanism.  Readers that are unfamiliar with GSS-API
+   concepts are encouraged to read the characteristics and concepts
+   section of [RFC2743] before examining this protocol in detail.  It is
+   also assumed that the reader is familiar with [RFC2845], [RFC2930],
+   [RFC1034] and [RFC1035].
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",
+   "RECOMMENDED", and "MAY" in this document are to be interpreted as
+   described in BCP 14, RFC 2119 [RFC2119].
+
+2.  Algorithm Overview
+
+   In GSS, client and server interact to create a "security context".
+   The security context can be used to create and verify transaction
+   signatures on messages between the two parties.  A unique security
+   context is required for each unique connection between client and
+   server.
+
+   Creating a security context involves a negotiation between client and
+   server.  Once a context has been established, it has a finite
+   lifetime for which it can be used to secure messages.  Thus there are
+   three states of a context associated with a connection:
+
+
+
+
+
+Kwan, et al.                Standards Track                     [Page 3]
+
+RFC 3645                        GSS-TSIG                    October 2003
+
+
+                              +----------+
+                              |          |
+                              V          |
+                      +---------------+  |
+                      | Uninitialized |  |
+                      |               |  |
+                      +---------------+  |
+                              |          |
+                              V          |
+                      +---------------+  |
+                      | Negotiating   |  |
+                      | Context       |  |
+                      +---------------+  |
+                              |          |
+                              V          |
+                      +---------------+  |
+                      | Context       |  |
+                      | Established   |  |
+                      +---------------+  |
+                              |          |
+                              +----------+
+
+   Every connection begins in the uninitialized state.
+
+2.1.  GSS Details
+
+   Client and server MUST be locally authenticated and have acquired
+   default credentials before using this protocol as specified in
+   Section 1.1.1 "Credentials" in RFC 2743 [RFC2743].
+
+   The GSS-TSIG algorithm consists of two stages:
+
+   I.  Establish security context.  The Client and Server use the
+       GSS_Init_sec_context and GSS_Accept_sec_context APIs to generate
+       the tokens that they pass to each other using [RFC2930] as a
+       transport mechanism.
+
+   II. Once the security context is established it is used to generate
+       and verify signatures using GSS_GetMIC and GSS_VerifyMIC APIs.
+       These signatures are exchanged by the Client and Server as a part
+       of the TSIG records exchanged in DNS messages sent between the
+       Client and Server, as described in [RFC2845].
+
+2.2.  Modifications to the TSIG protocol (RFC 2845)
+
+   Modification to RFC 2845 allows use of TSIG through signing server's
+   response in an explicitly specified place in multi message exchange
+   between two DNS entities even if client's request wasn't signed.
+
+
+
+Kwan, et al.                Standards Track                     [Page 4]
+
+RFC 3645                        GSS-TSIG                    October 2003
+
+
+   Specifically, Section 4.2 of RFC 2845 MUST be modified as follows:
+
+   Replace:
+      "The server MUST not generate a signed response to an unsigned
+      request."
+
+   With:
+      "The server MUST not generate a signed response to an unsigned
+      request, except in case of response to client's unsigned TKEY
+      query if secret key is established on server side after server
+      processed client's query.  Signing responses to unsigned TKEY
+      queries MUST be explicitly specified in the description of an
+      individual secret key establishment algorithm."
+
+3.  Client Protocol Details
+
+   A unique context is required for each server to which the client
+   sends secure messages.  A context is identified by a context handle.
+   A client maintains a mapping of servers to handles:
+
+      (target_name, key_name, context_handle)
+
+   The value key_name also identifies a context handle.  The key_name is
+   the owner name of the TKEY and TSIG records sent between a client and
+   a server to indicate to each other which context MUST be used to
+   process the current request.
+
+   DNS client and server MAY use various underlying security mechanisms
+   to establish security context as described in sections 3 and 4.  At
+   the same time, in order to guarantee interoperability between DNS
+   clients and servers that support GSS-TSIG it is REQUIRED that
+   security mechanism used by client enables use of Kerberos v5 (see
+   Section 9 for more information).
+
+3.1.  Negotiating Context
+
+   In GSS, establishing a security context involves the passing of
+   opaque tokens between the client and the server.  The client
+   generates the initial token and sends it to the server.  The server
+   processes the token and if necessary, returns a subsequent token to
+   the client.  The client processes this token, and so on, until the
+   negotiation is complete.  The number of times the client and server
+   exchange tokens depends on the underlying security mechanism.  A
+   completed negotiation results in a context handle.
+
+
+
+
+
+
+
+Kwan, et al.                Standards Track                     [Page 5]
+
+RFC 3645                        GSS-TSIG                    October 2003
+
+
+   The TKEY resource record [RFC2930] is used as the vehicle to transfer
+   tokens between client and server.  The TKEY record is a general
+   mechanism for establishing secret keys for use with TSIG.  For more
+   information, see [RFC2930].
+
+3.1.1.  Call GSS_Init_sec_context
+
+   To obtain the first token to be sent to a server, a client MUST call
+   GSS_Init_sec_context API.
+
+   The following input parameters MUST be used.  The outcome of the call
+   is indicated with the output values below.  Consult Sections 2.2.1,
+   "GSS_Init_sec_context call", of [RFC2743] for syntax definitions.
+
+   INPUTS
+     CREDENTIAL HANDLE claimant_cred_handle = NULL (NULL specifies "use
+         default").  Client MAY instead specify some other valid
+         handle to its credentials.
+     CONTEXT HANDLE input_context_handle  = 0
+     INTERNAL NAME  targ_name             = "DNS@<target_server_name>"
+     OBJECT IDENTIFIER mech_type          = Underlying security
+         mechanism chosen by implementers.  To guarantee
+         interoperability of the implementations of the GSS-TSIG
+         mechanism client MUST specify a valid underlying security
+         mechanism that enables use of Kerberos v5 (see Section 9 for
+         more information).
+     OCTET STRING   input_token           = NULL
+     BOOLEAN        replay_det_req_flag   = TRUE
+     BOOLEAN        mutual_req_flag       = TRUE
+     BOOLEAN        deleg_req_flag        = TRUE
+     BOOLEAN        sequence_req_flag     = TRUE
+     BOOLEAN        anon_req_flag         = FALSE
+     BOOLEAN        integ_req_flag        = TRUE
+     INTEGER        lifetime_req          = 0 (0 requests a default
+         value).  Client MAY instead specify another upper bound for the
+         lifetime of the context to be established in seconds.
+     OCTET STRING   chan_bindings         = Any valid channel bindings
+         as specified in Section 1.1.6 "Channel Bindings" in [RFC2743]
+
+   OUTPUTS
+     INTEGER        major_status
+     CONTEXT HANDLE output_context_handle
+     OCTET STRING   output_token
+     BOOLEAN        replay_det_state
+     BOOLEAN        mutual_state
+     INTEGER        minor_status
+     OBJECT IDENTIFIER mech_type
+     BOOLEAN        deleg_state
+
+
+
+Kwan, et al.                Standards Track                     [Page 6]
+
+RFC 3645                        GSS-TSIG                    October 2003
+
+
+     BOOLEAN        sequence_state
+     BOOLEAN        anon_state
+     BOOLEAN        trans_state
+     BOOLEAN        prot_ready_state
+     BOOLEAN        conf_avail
+     BOOLEAN        integ_avail
+     INTEGER        lifetime_rec
+
+   If returned major_status is set to one of the following errors:
+
+     GSS_S_DEFECTIVE_TOKEN
+     GSS_S_DEFECTIVE_CREDENTIAL
+     GSS_S_BAD_SIG (GSS_S_BAD_MIC)
+     GSS_S_NO_CRED
+     GSS_S_CREDENTIALS_EXPIRED
+     GSS_S_BAD_BINDINGS
+     GSS_S_OLD_TOKEN
+     GSS_S_DUPLICATE_TOKEN
+     GSS_S_NO_CONTEXT
+     GSS_S_BAD_NAMETYPE
+     GSS_S_BAD_NAME
+     GSS_S_BAD_MECH
+     GSS_S_FAILURE
+
+   then the client MUST abandon the algorithm and MUST NOT use the GSS-
+   TSIG algorithm to establish this security context.  This document
+   does not prescribe which other mechanism could be used to establish a
+   security context.  Next time when this client needs to establish
+   security context, the client MAY use GSS-TSIG algorithm.
+
+   Success values of major_status are GSS_S_CONTINUE_NEEDED and
+   GSS_S_COMPLETE.  The exact success code is important during later
+   processing.
+
+   The values of replay_det_state and mutual_state indicate if the
+   security package provides replay detection and mutual authentication,
+   respectively.  If returned major_status is GSS_S_COMPLETE AND one or
+   both of these values are FALSE, the client MUST abandon this
+   algorithm.
+
+   Client's behavior MAY depend on other OUTPUT parameters according to
+   the policy local to the client.
+
+   The handle output_context_handle is unique to this negotiation and is
+   stored in the client's mapping table as the context_handle that maps
+   to target_name.
+
+
+
+
+
+Kwan, et al.                Standards Track                     [Page 7]
+
+RFC 3645                        GSS-TSIG                    October 2003
+
+
+3.1.2.  Send TKEY Query to Server
+
+   An opaque output_token returned by GSS_Init_sec_context is
+   transmitted to the server in a query request with QTYPE=TKEY.  The
+   token itself will be placed in a Key Data field of the RDATA field in
+   the TKEY resource record in the additional records section of the
+   query.  The owner name of the TKEY resource record set queried for
+   and the owner name of the supplied TKEY resource record in the
+   additional records section MUST be the same.  This name uniquely
+   identifies the security context to both the client and server, and
+   thus the client SHOULD use a value which is globally unique as
+   described in [RFC2930].  To achieve global uniqueness, the name MAY
+   contain a UUID/GUID [ISO11578].
+
+      TKEY Record
+        NAME = client-generated globally unique domain name string
+               (as described in [RFC2930])
+        RDATA
+           Algorithm Name      = gss-tsig
+           Mode                = 3 (GSS-API negotiation - per [RFC2930])
+           Key Size            = size of output_token in octets
+           Key Data            = output_token
+
+   The remaining fields in the TKEY RDATA, i.e., Inception, Expiration,
+   Error, Other Size and Data Fields, MUST be set according to
+   [RFC2930].
+
+   The query is transmitted to the server.
+
+   Note: if the original client call to GSS_Init_sec_context returned
+   any major_status other than GSS_S_CONTINUE_NEEDED or GSS_S_COMPLETE,
+   then the client MUST NOT send TKEY query.  Client's behavior in this
+   case is described above in Section 3.1.1.
+
+3.1.3.  Receive TKEY Query-Response from Server
+
+   Upon the reception of the TKEY query the DNS server MUST respond
+   according to the description in Section 4.  This section specifies
+   the behavior of the client after it receives the matching response to
+   its query.
+
+   The next processing step depends on the value of major_status from
+   the most recent call that client performed to GSS_Init_sec_context:
+   either GSS_S_COMPLETE or GSS_S_CONTINUE.
+
+
+
+
+
+
+
+Kwan, et al.                Standards Track                     [Page 8]
+
+RFC 3645                        GSS-TSIG                    October 2003
+
+
+3.1.3.1.  Value of major_status == GSS_S_COMPLETE
+
+   If the last call to GSS_Init_sec_context yielded a major_status value
+   of GSS_S_COMPLETE and a non-NULL output_token was sent to the server,
+   then the client side component of the negotiation is complete and the
+   client is awaiting confirmation from the server.
+
+   Confirmation is in the form of a query response with RCODE=NOERROR
+   and with the last client supplied TKEY record in the answer section
+   of the query.  The response MUST be signed with a TSIG record.  Note
+   that the server is allowed to sign a response to unsigned client's
+   query due to modification to the RFC 2845 specified in Section 2.2
+   above.  The signature in the TSIG record MUST be verified using the
+   procedure detailed in section 5, Sending and Verifying Signed
+   Messages.  If the response is not signed, OR if the response is
+   signed but the signature is invalid, then an attacker has tampered
+   with the message in transit or has attempted to send the client a
+   false response.  In this case, the client MAY continue waiting for a
+   response to its last TKEY query until the time period since the
+   client sent last TKEY query expires.  Such a time period is specified
+   by the policy local to the client.  This is a new option that allows
+   the DNS client to accept multiple answers for one query ID and select
+   one (not necessarily the first one) based on some criteria.
+
+   If the signature is verified, the context state is advanced to
+   Context Established.  Proceed to section 3.2 for usage of the
+   security context.
+
+3.1.3.2.  Value of major_status == GSS_S_CONTINUE_NEEDED
+
+   If the last call to GSS_Init_sec_context yielded a major_status value
+   of GSS_S_CONTINUE_NEEDED, then the negotiation is not yet complete.
+   The server will return to the client a query response with a TKEY
+   record in the Answer section.  If the DNS message error is not
+   NO_ERROR or error field in the TKEY record is not 0 (i.e., no error),
+   then the client MUST abandon this negotiation sequence.  The client
+   MUST delete an active context by calling GSS_Delete_sec_context
+   providing the associated context_handle.  The client MAY repeat the
+   negotiation sequence starting with the uninitialized state as
+   described in section 3.1.  To prevent infinite looping the number of
+   attempts to establish a security context MUST be limited to ten or
+   less.
+
+   If the DNS message error is NO_ERROR and the error field in the TKEY
+   record is 0 (i.e., no error), then the client MUST pass a token
+   specified in the Key Data field in the TKEY resource record to
+
+
+
+
+
+Kwan, et al.                Standards Track                     [Page 9]
+
+RFC 3645                        GSS-TSIG                    October 2003
+
+
+   GSS_Init_sec_context using the same parameters values as in previous
+   call except values for CONTEXT HANDLE input_context_handle and OCTET
+   STRING input_token as described below:
+
+   INPUTS
+     CONTEXT HANDLE input_context_handle  = context_handle (this is the
+          context_handle corresponding to the key_name which is the
+          owner name of the TKEY record in the answer section in the
+          TKEY query response)
+
+     OCTET STRING   input_token           = token from Key field of
+                                            TKEY record
+
+   Depending on the following OUTPUT values of GSS_Init_sec_context
+
+        INTEGER        major_status
+        OCTET STRING   output_token
+
+   the client MUST take one of the following actions:
+
+   If OUTPUT major_status is set to one of the following values:
+
+        GSS_S_DEFECTIVE_TOKEN
+        GSS_S_DEFECTIVE_CREDENTIAL
+        GSS_S_BAD_SIG (GSS_S_BAD_MIC)
+        GSS_S_NO_CRED
+        GSS_S_CREDENTIALS_EXPIRED
+        GSS_S_BAD_BINDINGS
+        GSS_S_OLD_TOKEN
+        GSS_S_DUPLICATE_TOKEN
+        GSS_S_NO_CONTEXT
+        GSS_S_BAD_NAMETYPE
+        GSS_S_BAD_NAME
+        GSS_S_BAD_MECH
+        GSS_S_FAILURE
+
+   the client MUST abandon this negotiation sequence.  This means that
+   the client MUST delete an active context by calling
+   GSS_Delete_sec_context providing the associated context_handle.  The
+   client MAY repeat the negotiation sequence starting with the
+   uninitialized state as described in section 3.1.  To prevent infinite
+   looping the number of attempts to establish a security context MUST
+   be limited to ten or less.
+
+   If OUTPUT major_status is GSS_S_CONTINUE_NEEDED OR GSS_S_COMPLETE
+   then client MUST act as described below.
+
+
+
+
+
+Kwan, et al.                Standards Track                    [Page 10]
+
+RFC 3645                        GSS-TSIG                    October 2003
+
+
+   If the response from the server was signed, and the OUTPUT
+   major_status is GSS_S_COMPLETE,then the signature in the TSIG record
+   MUST be verified using the procedure detailed in section 5, Sending
+   and Verifying Signed Messages.  If the signature is invalid, then the
+   client MUST abandon this negotiation sequence.  This means that the
+   client MUST delete an active context by calling
+   GSS_Delete_sec_context providing the associated context_handle.  The
+   client MAY repeat the negotiation sequence starting with the
+   uninitialized state as described in section 3.1.  To prevent infinite
+   looping the number of attempts to establish a security context MUST
+   be limited to ten or less.
+
+   If major_status is GSS_S_CONTINUE_NEEDED the negotiation is not yet
+   finished.  The token output_token MUST be passed to the server in a
+   TKEY record by repeating the negotiation sequence beginning with
+   section 3.1.2.  The client MUST place a limit on the number of
+   continuations in a context negotiation to prevent endless looping.
+   Such limit SHOULD NOT exceed value of 10.
+
+   If major_status is GSS_S_COMPLETE and output_token is non-NULL, the
+   client-side component of the negotiation is complete but the token
+   output_token MUST be passed to the server by repeating the
+   negotiation sequence beginning with section 3.1.2.
+
+   If major_status is GSS_S_COMPLETE and output_token is NULL, context
+   negotiation is complete.  The context state is advanced to Context
+   Established.  Proceed to section 3.2 for usage of the security
+   context.
+
+3.2.  Context Established
+
+   When context negotiation is complete, the handle context_handle MUST
+   be used for the generation and verification of transaction
+   signatures.
+
+   The procedures for sending and receiving signed messages are
+   described in section 5, Sending and Verifying Signed Messages.
+
+3.2.1.  Terminating a Context
+
+   When the client is not intended to continue using the established
+   security context, the client SHOULD delete an active context by
+   calling GSS_Delete_sec_context providing the associated
+   context_handle, AND client SHOULD delete the established context on
+   the DNS server by using TKEY RR with the Mode field set to 5, i.e.,
+   "key deletion" [RFC2930].
+
+
+
+
+
+Kwan, et al.                Standards Track                    [Page 11]
+
+RFC 3645                        GSS-TSIG                    October 2003
+
+
+4.  Server Protocol Details
+
+   As on the client-side, the result of a successful context negotiation
+   is a context handle used in future generation and verification of the
+   transaction signatures.
+
+   A server MAY be managing several contexts with several clients.
+   Clients identify their contexts by providing a key name in their
+   request.  The server maintains a mapping of key names to handles:
+
+      (key_name, context_handle)
+
+4.1.  Negotiating Context
+
+   A server MUST recognize TKEY queries as security context negotiation
+   messages.
+
+4.1.1.  Receive TKEY Query from Client
+
+   Upon receiving a query with QTYPE = TKEY, the server MUST examine
+   whether the Mode and Algorithm Name fields of the TKEY record in the
+   additional records section of the message contain values of 3 and
+   gss-tsig, respectively.  If they do, then the (key_name,
+   context_handle) mapping table is searched for the key_name matching
+   the owner name of the TKEY record in the additional records section
+   of the query.  If the name is found in the table and the security
+   context for this name is established and not expired, then the server
+   MUST respond to the query with BADNAME error in the TKEY error field.
+   If the name is found in the table and the security context is not
+   established, the corresponding context_handle is used in subsequent
+   GSS operations.  If the name is found but the security context is
+   expired, then the server deletes this security context, as described
+   in Section 4.2.1, and interprets this query as a start of new
+   security context negotiation and performs operations described in
+   Section 4.1.2 and 4.1.3.  If the name is not found, then the server
+   interprets this query as a start of new security context negotiation
+   and performs operations described in Section 4.1.2 and 4.1.3.
+
+4.1.2.  Call GSS_Accept_sec_context
+
+   The server performs its side of a context negotiation by calling
+   GSS_Accept_sec_context.  The following input parameters MUST be used.
+   The outcome of the call is indicated with the output values below.
+   Consult Sections 2.2.2 "GSS_Accept_sec_context call" of the RFC 2743
+   [RFC2743] for syntax definitions.
+
+
+
+
+
+
+Kwan, et al.                Standards Track                    [Page 12]
+
+RFC 3645                        GSS-TSIG                    October 2003
+
+
+   INPUTS
+     CONTEXT HANDLE input_context_handle  = 0 if new negotiation,
+                                            context_handle matching
+                                         key_name if ongoing negotiation
+     OCTET STRING   input_token           = token specified in the Key
+           field from TKEY RR (from Additional records Section of
+           the client's query)
+
+     CREDENTIAL HANDLE acceptor_cred_handle = NULL (NULL specifies "use
+           default").  Server MAY instead specify some other valid
+           handle to its credentials.
+     OCTET STRING   chan_bindings          = Any valid channel bindings
+           as specified in Section 1.1.6 "Channel Bindings" in [RFC2743]
+
+   OUTPUTS
+     INTEGER        major_status
+     CONTEXT_HANDLE output_context_handle
+     OCTET STRING   output_token
+     INTEGER        minor_status
+     INTERNAL NAME  src_name
+     OBJECT IDENTIFIER  mech_type
+     BOOLEAN        deleg_state
+     BOOLEAN        mutual_state
+     BOOLEAN        replay_det_state
+     BOOLEAN        sequence_state
+     BOOLEAN        anon_state
+     BOOLEAN        trans_state
+     BOOLEAN        prot_ready_state
+     BOOLEAN        conf_avail
+     BOOLEAN        integ_avail
+     INTEGER        lifetime_rec
+     CONTEXT_HANDLE delegated_cred_handle
+
+   If this is the first call to GSS_Accept_sec_context in a new
+   negotiation, then output_context_handle is stored in the server's
+   key-mapping table as the context_handle that maps to the name of the
+   TKEY record.
+
+4.1.3.  Send TKEY Query-Response to Client
+
+   The server MUST respond to the client with a TKEY query response with
+   RCODE = NOERROR, that contains a TKEY record in the answer section.
+
+   If OUTPUT major_status is one of the following errors the error field
+   in the TKEY record set to BADKEY.
+
+
+
+
+
+
+Kwan, et al.                Standards Track                    [Page 13]
+
+RFC 3645                        GSS-TSIG                    October 2003
+
+
+        GSS_S_DEFECTIVE_TOKEN
+        GSS_S_DEFECTIVE_CREDENTIAL
+        GSS_S_BAD_SIG (GSS_S_BAD_MIC)
+        GSS_S_DUPLICATE_TOKEN
+        GSS_S_OLD_TOKEN
+        GSS_S_NO_CRED
+        GSS_S_CREDENTIALS_EXPIRED
+        GSS_S_BAD_BINDINGS
+        GSS_S_NO_CONTEXT
+        GSS_S_BAD_MECH
+        GSS_S_FAILURE
+
+   If OUTPUT major_status is set to  GSS_S_COMPLETE or
+   GSS_S_CONTINUE_NEEDED then server MUST act as described below.
+
+   If major_status is GSS_S_COMPLETE the server component of the
+   negotiation is finished.  If output_token is non-NULL, then it MUST
+   be returned to the client in a Key Data field of the RDATA in TKEY.
+   The error field in the TKEY record is set to NOERROR.  The message
+   MUST be signed with a TSIG record as described in section 5, Sending
+   and Verifying Signed Messages.  Note that server is allowed to sign a
+   response to unsigned client's query due to modification to the RFC
+   2845 specified in Section 2.2 above.  The context state is advanced
+   to Context Established.  Section 4.2 discusses the usage of the
+   security context.
+
+   If major_status is GSS_S_COMPLETE and output_token is NULL, then the
+   TKEY record received from the client MUST be returned in the Answer
+   section of the response.  The message MUST be signed with a TSIG
+   record as described in section 5, Sending and Verifying Signed
+   Messages.  Note that server is allowed to sign a response to unsigned
+   client's query due to modification to the RFC 2845 specified in
+   section 2.2 above.  The context state is advanced to Context
+   Established.  Section 4.2 discusses the usage of the security
+   context.
+
+   If major_status is GSS_S_CONTINUE_NEEDED, the server component of the
+   negotiation is not yet finished.  The server responds to the TKEY
+   query with a standard query response, placing in the answer section a
+   TKEY record containing output_token in the Key Data RDATA field.  The
+   error field in the TKEY record is set to NOERROR.  The server MUST
+   limit the number of times that a given context is allowed to repeat,
+   to prevent endless looping.  Such limit SHOULD NOT exceed value of
+   10.
+
+
+
+
+
+
+
+Kwan, et al.                Standards Track                    [Page 14]
+
+RFC 3645                        GSS-TSIG                    October 2003
+
+
+   In all cases, except if major_status is GSS_S_COMPLETE and
+   output_token is NULL, other TKEY record fields MUST contain the
+   following values:
+
+        NAME = key_name
+        RDATA
+           Algorithm Name      = gss-tsig
+           Mode                = 3 (GSS-API negotiation - per [RFC2930])
+           Key Size            = size of output_token in octets
+
+   The remaining fields in the TKEY RDATA, i.e., Inception, Expiration,
+   Error, Other Size and Data Fields, MUST be set according to
+   [RFC2930].
+
+4.2.  Context Established
+
+   When context negotiation is complete, the handle context_handle is
+   used for the generation and verification of transaction signatures.
+   The handle is valid for a finite amount of time determined by the
+   underlying security mechanism.  A server MAY unilaterally terminate a
+   context at any time (see section 4.2.1).
+
+   Server SHOULD limit the amount of memory used to cache established
+   contexts.
+
+   The procedures for sending and receiving signed messages are given in
+   section 5, Sending and Verifying Signed Messages.
+
+4.2.1.  Terminating a Context
+
+   A server can terminate any established context at any time.  The
+   server MAY hint to the client that the context is being deleted by
+   including a TKEY RR in a response with the Mode field set to 5, i.e.,
+   "key deletion" [RFC2930].  An active context is deleted by calling
+   GSS_Delete_sec_context providing the associated context_handle.
+
+5.  Sending and Verifying Signed Messages
+
+5.1.  Sending a Signed Message - Call GSS_GetMIC
+
+   The procedure for sending a signature-protected message is specified
+   in [RFC2845].  The data to be passed to the signature routine
+   includes the whole DNS message with specific TSIG variables appended.
+   For the exact format, see [RFC2845].  For this protocol, use the
+   following TSIG variable values:
+
+
+
+
+
+
+Kwan, et al.                Standards Track                    [Page 15]
+
+RFC 3645                        GSS-TSIG                    October 2003
+
+
+      TSIG Record
+        NAME = key_name that identifies this context
+        RDATA
+           Algorithm Name = gss-tsig
+
+   Assign the remaining fields in the TSIG RDATA appropriate values as
+   described in [RFC2845].
+
+   The signature is generated by calling GSS_GetMIC.  The following
+   input parameters MUST be used.  The outcome of the call is indicated
+   with the output values specified below.  Consult Sections 2.3.1
+   "GSS_GetMIC call" of the RFC 2743[RFC2743] for syntax definitions.
+
+   INPUTS
+     CONTEXT HANDLE context_handle = context_handle for key_name
+     OCTET STRING   message        = outgoing message plus TSIG
+                                     variables (per [RFC2845])
+     INTEGER qop_req               = 0 (0 requests a default
+         value).  Caller MAY instead specify other valid value (for
+         details see Section 1.2.4 in [RFC2743])
+
+   OUTPUTS
+     INTEGER        major_status
+     INTEGER        minor_status
+     OCTET STRING   per_msg_token
+
+   If major_status is GSS_S_COMPLETE, then signature generation
+   succeeded.  The signature in per_msg_token is inserted into the
+   Signature field of the TSIG RR and the message is transmitted.
+
+   If major_status is GSS_S_CONTEXT_EXPIRED, GSS_S_CREDENTIALS_EXPIRED
+   or GSS_S_FAILURE the caller MUST delete the security context, return
+   to the uninitialized state and SHOULD negotiate a new security
+   context, as described above in Section 3.1
+
+   If major_status is GSS_S_NO_CONTEXT, the caller MUST remove the entry
+   for key_name from the (target_ name, key_name, context_handle)
+   mapping table, return to the uninitialized state and SHOULD negotiate
+   a new security context, as described above in Section 3.1
+
+   If major_status is GSS_S_BAD_QOP, the caller SHOULD repeat the
+   GSS_GetMIC call with allowed QOP value.  The number of such
+   repetitions MUST be limited to prevent infinite loops.
+
+5.2.  Verifying a Signed Message - Call GSS_VerifyMIC
+
+   The procedure for verifying a signature-protected message is
+   specified in [RFC2845].
+
+
+
+Kwan, et al.                Standards Track                    [Page 16]
+
+RFC 3645                        GSS-TSIG                    October 2003
+
+
+   The NAME of the TSIG record determines which context_handle maps to
+   the context that MUST be used to verify the signature.  If the NAME
+   does not map to an established context, the server MUST send a
+   standard TSIG error response to the client indicating BADKEY in the
+   TSIG error field (as described in [RFC2845]).
+
+   For the GSS algorithm, a signature is verified by using
+   GSS_VerifyMIC:
+
+   INPUTS
+     CONTEXT HANDLE context_handle = context_handle for key_name
+     OCTET STRING   message        = incoming message plus TSIG
+                                     variables (per [RFC2845])
+     OCTET STRING   per_msg_token  = Signature field from TSIG RR
+
+   OUTPUTS
+     INTEGER        major_status
+     INTEGER        minor_status
+     INTEGER        qop_state
+
+   If major_status is GSS_S_COMPLETE, the signature is authentic and the
+   message was delivered intact.  Per [RFC2845], the timer values of the
+   TSIG record MUST also be valid before considering the message to be
+   authentic.  The caller MUST not act on the request or response in the
+   message until these checks are verified.
+
+   When a server is processing a client request, the server MUST send a
+   standard TSIG error response to the client indicating BADKEY in the
+   TSIG error field as described in [RFC2845], if major_status is set to
+   one of the following values
+
+        GSS_S_DEFECTIVE_TOKEN
+        GSS_S_BAD_SIG (GSS_S_BAD_MIC)
+        GSS_S_DUPLICATE_TOKEN
+        GSS_S_OLD_TOKEN
+        GSS_S_UNSEQ_TOKEN
+        GSS_S_GAP_TOKEN
+        GSS_S_CONTEXT_EXPIRED
+        GSS_S_NO_CONTEXT
+        GSS_S_FAILURE
+
+   If the timer values of the TSIG record are invalid, the message MUST
+   NOT be considered authentic.  If this error checking fails when a
+   server is processing a client request, the appropriate error response
+   MUST be sent to the client according to [RFC2845].
+
+
+
+
+
+
+Kwan, et al.                Standards Track                    [Page 17]
+
+RFC 3645                        GSS-TSIG                    October 2003
+
+
+6.  Example usage of GSS-TSIG algorithm
+
+   This Section describes an example where a Client, client.example.com,
+   and a Server, server.example.com, establish a security context
+   according to the algorithm described above.
+
+  I.  Client initializes security context negotiation
+
+  To establish a security context with a server, server.example.com, the
+  Client calls GSS_Init_sec_context with the following parameters.
+  (Note that some INPUT and OUTPUT parameters not critical for this
+  algorithm are not described in this example.)
+
+     CONTEXT HANDLE input_context_handle  = 0
+     INTERNAL NAME  targ_name             = "DNS@server.example.com"
+     OCTET STRING   input_token           = NULL
+     BOOLEAN        replay_det_req_flag   = TRUE
+     BOOLEAN        mutual_req_flag       = TRUE
+
+  The OUTPUTS parameters returned by GSS_Init_sec_context include
+     INTEGER        major_status = GSS_S_CONTINUE_NEEDED
+     CONTEXT HANDLE output_context_handle context_handle
+     OCTET STRING   output_token output_token
+     BOOLEAN        replay_det_state = TRUE
+     BOOLEAN        mutual_state = TRUE
+
+  Client verifies that replay_det_state and mutual_state values are
+  TRUE.  Since the major_status is GSS_S_CONTINUE_NEEDED, which is a
+  success OUTPUT major_status value, client stores context_handle that
+  maps to "DNS@server.example.com" and proceeds to the next step.
+
+  II.  Client sends a query with QTYPE = TKEY to server
+
+  Client sends a query with QTYPE = TKEY for a client-generated globally
+  unique domain name string, 789.client.example.com.server.example.com.
+  Query contains a TKEY record in its Additional records section with
+  the following fields.  (Note that some fields not specific to this
+  algorithm are not specified.)
+
+     NAME = 789.client.example.com.server.example.com.
+     RDATA
+        Algorithm Name      = gss-tsig
+        Mode                = 3 (GSS-API negotiation - per [RFC2930])
+        Key Size            = size of output_token in octets
+        Key Data            = output_token
+
+
+
+
+
+
+Kwan, et al.                Standards Track                    [Page 18]
+
+RFC 3645                        GSS-TSIG                    October 2003
+
+
+  After the key_name 789.client.example.com.server.example.com.
+  is generated it is stored in the client's (target_name, key_name,
+  context_handle) mapping table.
+
+  III.  Server receives a query with QTYPE = TKEY
+
+  When server receives a query with QTYPE = TKEY, the server verifies
+  that Mode and Algorithm fields in the TKEY record in the Additional
+  records section of the query are set to 3 and "gss-tsig" respectively.
+  It finds that the key_name 789.client.example.com.server.example.com.
+  is not listed in its (key_name, context_handle) mapping table.
+
+  IV.  Server calls GSS_Accept_sec_context
+
+  To continue security context negotiation server calls
+  GSS_Accept_sec_context with the following parameters.  (Note that
+  some INPUT and OUTPUT parameters not critical for this algorithm
+  are not described in this example.)
+
+   INPUTS
+     CONTEXT HANDLE input_context_handle  = 0
+     OCTET STRING   input_token           = token specified in the Key
+                              field from TKEY RR (from Additional
+                              records section of the client's query)
+
+  The OUTPUTS parameters returned by GSS_Accept_sec_context include
+     INTEGER        major_status = GSS_S_CONTINUE_NEEDED
+     CONTEXT_HANDLE output_context_handle context_handle
+     OCTET STRING   output_token output_token
+
+  Server stores the mapping of the
+  789.client.example.com.server.example.com. to OUTPUT context_handle
+  in its (key_name, context_handle) mapping table.
+
+  V.  Server responds to the TKEY query
+
+  Since the major_status = GSS_S_CONTINUE_NEEDED in the last server's
+  call to GSS_Accept_sec_context, the server responds to the TKEY query
+  placing in the answer section a TKEY record containing output_token in
+  the Key Data RDATA field.  The error field in the TKEY record is set
+  to 0.  The RCODE in the query response is set to NOERROR.
+
+  VI.  Client processes token returned by server
+
+  When the client receives the TKEY query response from the server, the
+  client calls GSS_Init_sec_context with the following parameters.
+  (Note that some INPUT and OUTPUT parameters not critical for this
+  algorithm are not described in this example.)
+
+
+
+Kwan, et al.                Standards Track                    [Page 19]
+
+RFC 3645                        GSS-TSIG                    October 2003
+
+
+     CONTEXT HANDLE input_context_handle  = the context_handle stored
+          in the client's mapping table entry (DNS@server.example.com.,
+          789.client.example.com.server.example.com., context_handle)
+     INTERNAL NAME  targ_name             = "DNS@server.example.com"
+     OCTET STRING   input_token           = token from Key field of TKEY
+          record from the Answer section of the server's response
+     BOOLEAN        replay_det_req_flag   = TRUE
+     BOOLEAN        mutual_req_flag       = TRUE
+
+  The OUTPUTS parameters returned by GSS_Init_sec_context include
+     INTEGER        major_status = GSS_S_COMPLETE
+     CONTEXT HANDLE output_context_handle = context_handle
+     OCTET STRING   output_token = output_token
+     BOOLEAN        replay_det_state = TRUE
+     BOOLEAN        mutual_state = TRUE
+
+  Since the major_status is set to GSS_S_COMPLETE the client side
+  security context is established, but since the output_token is not
+  NULL client MUST send a TKEY query to the server as described below.
+
+  VII.  Client sends a query with QTYPE = TKEY to server
+
+  Client sends to the server a TKEY query for the
+  789.client.example.com.server.example.com. name.  Query contains a
+  TKEY record in its Additional records section with the following
+  fields.  (Note that some INPUT and OUTPUT parameters not critical to
+  this algorithm are not described in this example.)
+
+     NAME = 789.client.example.com.server.example.com.
+     RDATA
+        Algorithm Name      = gss-tsig
+        Mode                = 3 (GSS-API negotiation - per [RFC2930])
+        Key Size            = size of output_token in octets
+        Key Data            = output_token
+
+  VIII.  Server receives a TKEY query
+
+  When the server receives a TKEY query, the server verifies that Mode
+  and Algorithm fields in the TKEY record in the Additional records
+  section of the query are set to 3 and gss-tsig, respectively.  It
+  finds that the key_name 789.client.example.com.server.example.com. is
+  listed in its (key_name, context_handle) mapping table.
+
+
+
+
+
+
+
+
+
+Kwan, et al.                Standards Track                    [Page 20]
+
+RFC 3645                        GSS-TSIG                    October 2003
+
+
+  IX.  Server calls GSS_Accept_sec_context
+
+  To continue security context negotiation server calls
+  GSS_Accept_sec_context with the following parameters (Note that some
+  INPUT and OUTPUT parameters not critical for this algorithm are not
+  described in this example)
+
+   INPUTS
+     CONTEXT HANDLE input_context_handle  = context_handle from the
+           (789.client.example.com.server.example.com., context_handle)
+           entry in the server's mapping table
+     OCTET STRING   input_token           = token specified in the Key
+           field of TKEY RR (from Additional records Section of
+           the client's query)
+
+  The OUTPUTS parameters returned by GSS_Accept_sec_context include
+     INTEGER        major_status = GSS_S_COMPLETE
+     CONTEXT_HANDLE output_context_handle = context_handle
+     OCTET STRING   output_token = NULL
+
+  Since major_status = GSS_S_COMPLETE, the security context on the
+  server side is established, but the server still needs to respond to
+  the client's TKEY query, as described below.  The security context
+  state is advanced to Context Established.
+
+  X.  Server responds to the TKEY query
+
+  Since the major_status = GSS_S_COMPLETE in the last server's call to
+  GSS_Accept_sec_context and the output_token is NULL, the server
+  responds to the TKEY query placing in the answer section a TKEY record
+  that was sent by the client in the Additional records section of the
+  client's latest TKEY query.  In addition, this server places a
+  TSIG record in additional records section of its response.  Server
+  calls GSS_GetMIC to generate a signature to include it in the TSIG
+  record.  The server specifies the following GSS_GetMIC INPUT
+  parameters:
+
+     CONTEXT HANDLE context_handle = context_handle from the
+           (789.client.example.com.server.example.com., context_handle)
+           entry in the server's mapping table
+     OCTET STRING   message        = outgoing message plus TSIG
+                                   variables (as described in [RFC2845])
+
+  The OUTPUTS parameters returned by GSS_GetMIC include
+     INTEGER        major_status = GSS_S_COMPLETE
+     OCTET STRING   per_msg_token
+
+  Signature field in the TSIG record is set to per_msg_token.
+
+
+
+Kwan, et al.                Standards Track                    [Page 21]
+
+RFC 3645                        GSS-TSIG                    October 2003
+
+
+  XI.  Client processes token returned by server
+
+  Client receives the TKEY query response from the server.  Since the
+  major_status was GSS_S_COMPLETE in the last client's call to
+  GSS_Init_sec_context, the client verifies that the server's response
+  is signed.  To validate the signature, the client calls
+  GSS_VerifyMIC with the following parameters:
+
+   INPUTS
+     CONTEXT HANDLE context_handle = context_handle for
+                  789.client.example.com.server.example.com. key_name
+     OCTET STRING   message        = incoming message plus TSIG
+                                  variables (as described in [RFC2845])
+     OCTET STRING   per_msg_token  = Signature field from TSIG RR
+                  included in the server's query response
+
+  Since the OUTPUTS parameter major_status = GSS_S_COMPLETE, the
+  signature is validated, security negotiation is complete and the
+  security context state is advanced to Context Established.  These
+  client and server will use the established security context to sign
+  and validate the signatures when they exchange packets with each
+  other until the context expires.
+
+7.  Security Considerations
+
+   This document describes a protocol for DNS security using GSS-API.
+   The security provided by this protocol is only as effective as the
+   security provided by the underlying GSS mechanisms.
+
+   All the security considerations from RFC 2845, RFC 2930 and RFC 2743
+   apply to the protocol described in this document.
+
+8.  IANA Considerations
+
+   The IANA has reserved the TSIG Algorithm name gss-tsig for the use in
+   the Algorithm fields of TKEY and TSIG resource records.  This
+   Algorithm name refers to the algorithm described in this document.
+   The requirement to have this name registered with IANA is specified
+   in RFC 2845.
+
+9.  Conformance
+
+   The GSS API using SPNEGO [RFC2478] provides maximum flexibility to
+   choose the underlying security mechanisms that enables security
+   context negotiation.  GSS API using SPNEGO [RFC2478] enables client
+   and server to negotiate and choose such underlying security
+   mechanisms on the fly.  To support such flexibility, DNS clients and
+   servers SHOULD specify SPNEGO mech_type in their GSS API calls.  At
+
+
+
+Kwan, et al.                Standards Track                    [Page 22]
+
+RFC 3645                        GSS-TSIG                    October 2003
+
+
+   the same time, in order to guarantee interoperability between DNS
+   clients and servers that support GSS-TSIG it is required that
+
+   -  DNS servers specify SPNEGO mech_type
+   -  GSS APIs called by DNS client support Kerberos v5
+   -  GSS APIs called by DNS server support SPNEGO [RFC2478] and
+      Kerberos v5.
+
+   In addition to these, GSS APIs used by DNS client and server MAY also
+   support other underlying security mechanisms.
+
+10.  Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   intellectual property or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; neither does it represent that it
+   has made any effort to identify any such rights.  Information on the
+   IETF's procedures with respect to rights in standards-track and
+   standards-related documentation can be found in BCP-11.  Copies of
+   claims of rights made available for publication and any assurances of
+   licenses to be made available, or the result of an attempt made to
+   obtain a general license or permission for the use of such
+   proprietary rights by implementors or users of this specification can
+   be obtained from the IETF Secretariat.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights which may cover technology that may be required to practice
+   this standard.  Please address the information to the IETF Executive
+   Director.
+
+11.  Acknowledgements
+
+   The authors of this document would like to thank the following people
+   for their contribution to this specification:  Chuck Chan, Mike
+   Swift, Ram Viswanathan, Olafur Gudmundsson, Donald E. Eastlake, 3rd
+   and Erik Nordmark.
+
+
+
+
+
+
+
+
+
+
+
+
+Kwan, et al.                Standards Track                    [Page 23]
+
+RFC 3645                        GSS-TSIG                    October 2003
+
+
+12.  References
+
+12.1.  Normative References
+
+   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+             Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2478] Baize, E. and D. Pinkas, "The Simple and Protected GSS-API
+             Negotiation Mechanism", RFC 2478, December 1998.
+
+   [RFC2743] Linn, J., "Generic Security Service Application Program
+             Interface, Version 2 , Update 1", RFC 2743, January 2000.
+
+   [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D. and B.
+             Wellington, "Secret Key Transaction Authentication for DNS
+             (TSIG)", RFC 2845, May 2000.
+
+   [RFC2930] Eastlake 3rd, D., "Secret Key Establishment for DNS (TKEY
+             RR)", RFC 2930, September 2000.
+
+12.2.  Informative References
+
+
+   [ISO11578] "Information technology", "Open Systems Interconnection",
+              "Remote Procedure Call", ISO/IEC 11578:1996,
+              http://www.iso.ch/cate/d2229.html.
+
+   [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
+             STD 13, RFC 1034, November 1987.
+
+   [RFC1035] Mockapetris, P., "Domain Names - Implementation and
+             Specification", STD 13, RFC 1034, November 1987.
+
+   [RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC
+             1964, June 1996.
+
+   [RFC2025] Adams, C., "The Simple Public-Key GSS-API Mechanism
+             (SPKM)", RFC 2025, October 1996.
+
+   [RFC2137] Eastlake 3rd, D., "Secure Domain Name System Dynamic
+             Update", RFC 2137, April 1997.
+
+   [RFC2535] Eastlake 3rd, D., "Domain Name System Security Extensions",
+             RFC 2535, March 1999.
+
+
+
+
+
+
+
+Kwan, et al.                Standards Track                    [Page 24]
+
+RFC 3645                        GSS-TSIG                    October 2003
+
+
+13.  Authors' Addresses
+
+   Stuart Kwan
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   USA
+   EMail: skwan@microsoft.com
+
+   Praerit Garg
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   USA
+   EMail: praeritg@microsoft.com
+
+   James Gilroy
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   USA
+   EMail: jamesg@microsoft.com
+
+   Levon Esibov
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   USA
+   EMail: levone@microsoft.com
+
+   Randy Hall
+   Lucent Technologies
+   400 Lapp Road
+   Malvern PA 19355
+   USA
+   EMail: randyhall@lucent.com
+
+   Jeff Westhead
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA  98052
+   USA
+   EMail: jwesth@microsoft.com
+
+
+
+
+
+
+
+
+Kwan, et al.                Standards Track                    [Page 25]
+
+RFC 3645                        GSS-TSIG                    October 2003
+
+
+14.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assignees.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kwan, et al.                Standards Track                    [Page 26]
+
diff --git a/doc/rfc/rfc3655.txt b/doc/rfc/rfc3655.txt
new file mode 100644
index 0000000..13e586b
--- /dev/null
+++ b/doc/rfc/rfc3655.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Network Working Group                                      B. Wellington
+Request for Comments: 3655                                O. Gudmundsson
+Updates: 2535                                              November 2003
+Category: Standards Track
+
+
+            Redefinition of DNS Authenticated Data (AD) bit
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+Abstract
+
+   This document alters the specification defined in RFC 2535.  Based on
+   implementation experience, the Authenticated Data (AD) bit in the DNS
+   header is not useful.  This document redefines the AD bit such that
+   it is only set if all answers or records proving that no answers
+   exist in the response has been cryptographically verified or
+   otherwise meets the server's local security policy.
+
+1.  Introduction
+
+   Familiarity with the DNS system [RFC1035] and DNS security extensions
+   [RFC2535] is helpful but not necessary.
+
+   As specified in RFC 2535 (section 6.1), the AD (Authenticated Data)
+   bit indicates in a response that all data included in the answer and
+   authority sections of the response have been authenticated by the
+   server according to the policies of that server.  This is not
+   especially useful in practice, since a conformant server SHOULD never
+   reply with data that failed its security policy.
+
+   This document redefines the AD bit such that it is only set if all
+   data in the response has been cryptographically verified or otherwise
+   meets the server's local security policy.  Thus, neither a response
+   containing properly delegated insecure data, nor a server configured
+   without DNSSEC keys, will have the AD set.  As before, data that
+   failed to verify will not be returned.  An application running on a
+   host that has a trust relationship with the server performing the
+
+
+
+Wellington & Gudmundsson    Standards Track                     [Page 1]
+
+RFC 3655               Redefinition of DNS AD bit          November 2003
+
+
+   recursive query can now use the value of the AD bit to determine
+   whether the data is secure.
+
+1.1.  Motivation
+
+   A full DNSSEC capable resolver called directly from an application
+   can return to the application the security status of the RRsets in
+   the answer.  However, most applications use a limited stub resolver
+   that relies on an external recursive name server which incorporates a
+   full resolver.  The recursive nameserver can use the AD bit in a
+   response to indicate the security status of the data in the answer,
+   and the local resolver can pass this information to the application.
+   The application in this context can be either a human using a DNS
+   tool or a software application.
+
+   The AD bit SHOULD be used by the local resolver if and only if it has
+   been explicitly configured to trust the remote resolver.  The AD bit
+   SHOULD be ignored when the recursive name server is not trusted.
+
+   An alternate solution would be to embed a full DNSSEC resolver into
+   every application, but this has several disadvantages.
+
+   -  DNSSEC validation is both CPU and network intensive, and caching
+      SHOULD be used whenever possible.
+
+   -  DNSSEC requires non-trivial configuration - the root key must be
+      configured, as well as keys for any "islands of security" that
+      will exist until DNSSEC is fully deployed.  The number of
+      configuration points should be minimized.
+
+1.2.  Requirements
+
+   The key words "MAY", "MAY NOT" "MUST", "MUST NOT", "SHOULD", "SHOULD
+   NOT", "RECOMMENDED", in this document are to be interpreted as
+   described in BCP 14, RFC 2119 [RFC2119].
+
+1.3.  Updated documents and sections
+
+   The definition of the AD bit in RFC 2535, Section 6.1, is changed.
+
+2.  Setting of AD bit
+
+   The presence of the CD (Checking Disabled) bit in a query does not
+   affect the setting of the AD bit in the response.  If the CD bit is
+   set, the server will not perform checking, but SHOULD still set the
+   AD bit if the data has already been cryptographically verified or
+
+
+
+
+
+Wellington & Gudmundsson    Standards Track                     [Page 2]
+
+RFC 3655               Redefinition of DNS AD bit          November 2003
+
+
+   complies with local policy.  The AD bit MUST only be set if DNSSEC
+   records have been requested via the DO bit [RFC3225] and relevant SIG
+   records are returned.
+
+2.1.  Setting of AD bit by recursive servers
+
+   Section 6.1 of RFC 2535 says:
+
+   "The AD bit MUST NOT be set on a response unless all of the RRs in
+   the answer and authority sections of the response are either
+   Authenticated or Insecure."
+
+   The replacement text reads:
+
+   "The AD bit MUST NOT be set on a response unless all of the RRsets in
+   the answer and authority sections of the response are Authenticated."
+
+   "The AD bit SHOULD be set if and only if all RRs in the answer
+   section and any relevant negative response RRs in the authority
+   section are Authenticated."
+
+   A recursive DNS server following this modified specification will
+   only set the AD bit when it has cryptographically verified the data
+   in the answer.
+
+2.2.  Setting of AD bit by authoritative servers
+
+   A primary server for a secure zone MAY have the policy of treating
+   authoritative secure zones as Authenticated.  Secondary servers MAY
+   have the same policy, but SHOULD NOT consider zone data Authenticated
+   unless the zone was transferred securely and/or the data was
+   verified.  An authoritative server MUST only set the AD bit for
+   authoritative answers from a secure zone if it has been explicitly
+   configured to do so.  The default for this behavior SHOULD be off.
+
+   Note that having the AD bit clear on an authoritative answer is
+   normal and expected behavior.
+
+2.2.1.  Justification for setting AD bit w/o verifying data
+
+   The setting of the AD bit by authoritative servers affects only the
+   small set of resolvers that are configured to directly query and
+   trust authoritative servers.  This only affects servers that function
+   as both recursive and authoritative.  Iterative resolvers SHOULD
+   ignore the AD bit.
+
+   The cost of verifying all signatures on load by an authoritative
+   server can be high and increases the delay before it can begin
+
+
+
+Wellington & Gudmundsson    Standards Track                     [Page 3]
+
+RFC 3655               Redefinition of DNS AD bit          November 2003
+
+
+   answering queries.  Verifying signatures at query time is also
+   expensive and could lead to resolvers timing out on many queries
+   after the server reloads zones.
+
+   Organizations requiring that all DNS responses contain
+   cryptographically verified data will need to separate the
+   authoritative name server and signature verification functions, since
+   name servers are not required to validate signatures of data for
+   which they are authoritative.
+
+3.  Interpretation of the AD bit
+
+   A response containing data marked Insecure in the answer or authority
+   section MUST never have the AD bit set.  In this case, the resolver
+   SHOULD treat the data as Insecure whether or not SIG records are
+   present.
+
+   A resolver MUST NOT blindly trust the AD bit unless it communicates
+   with a recursive nameserver over a secure transport mechanism or
+   using a message authentication such as TSIG [RFC2845] or SIG(0)
+   [RFC2931] and is explicitly configured to trust this recursive name
+   server.
+
+4.  Applicability statement
+
+   The AD bit is intended to allow the transmission of the indication
+   that a resolver has verified the DNSSEC signatures accompanying the
+   records in the Answer and Authority section.  The AD bit MUST only be
+   trusted when the end consumer of the DNS data has confidence that the
+   intermediary resolver setting the AD bit is trustworthy.  This can
+   only be accomplished via an out of band mechanism such as:
+
+   -  Fiat: An organization that can dictate whether it is OK to trust
+      certain DNS servers.
+
+   -  Personal: Because of a personal relationship or the reputation of
+      a recursive nameserver operator, a DNS consumer can decide to
+      trust that recursive nameserver.
+
+   -  Knowledge: If a recursive nameserver operator posts the configured
+      policy of a recursive nameserver, a consumer can decide that
+      recursive nameserver is trustworthy.
+
+   In the absence of one or more of these factors AD bit from a
+   recursive name server SHOULD NOT be trusted.  For example, home users
+   frequently depend on their ISP to provide recursive DNS service; it
+
+
+
+
+
+Wellington & Gudmundsson    Standards Track                     [Page 4]
+
+RFC 3655               Redefinition of DNS AD bit          November 2003
+
+
+   is not advisable to trust these recursive nameservers.  A
+   roaming/traveling host SHOULD not use recursive DNS servers offered
+   by DHCP when looking up information where security status matters.
+
+   In the latter two cases, the end consumer must also completely trust
+   the path to the trusted recursive name servers, or a secure transport
+   must be employed to protect the traffic.
+
+   When faced with a situation where there are no satisfactory recursive
+   nameservers available, running one locally is RECOMMENDED.  This has
+   the advantage that it can be trusted, and the AD bit can still be
+   used to allow applications to use stub resolvers.
+
+5.  Security Considerations
+
+   This document redefines a bit in the DNS header.  If a resolver
+   trusts the value of the AD bit, it must be sure that the responder is
+   using the updated definition, which is any DNS server/resolver
+   supporting the DO bit [RFC3225].
+
+   Authoritative servers can be explicitly configured to set the AD bit
+   on answers without doing cryptographic checks.  This behavior MUST be
+   off by default.  The only affected resolvers are those that directly
+   query and trust the authoritative server, and this functionality
+   SHOULD only be used on servers that act both as authoritative and
+   recursive name servers.
+
+   Resolvers (full or stub) that blindly trust the AD bit without
+   knowing the security policy of the server generating the answer can
+   not be considered security aware.
+
+   A resolver MUST NOT blindly trust the AD bit unless it communicates
+   such as IPsec, or using message authentication such as TSIG [RFC2845]
+   or SIG(0) [RFC2931].  In addition, the resolver must have been
+   explicitly configured to trust this recursive name server.
+
+6.  IANA Considerations
+
+   None.
+
+7.  Internationalization Considerations
+
+   None.  This document does not change any textual data in any
+   protocol.
+
+
+
+
+
+
+
+Wellington & Gudmundsson    Standards Track                     [Page 5]
+
+RFC 3655               Redefinition of DNS AD bit          November 2003
+
+
+8.  Intellectual Property Rights Notice
+
+   The IETF takes no position regarding the validity or scope of any
+   intellectual property or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; neither does it represent that it
+   has made any effort to identify any such rights.  Information on the
+   IETF's procedures with respect to rights in standards-track and
+   standards-related documentation can be found in BCP-11.  Copies of
+   claims of rights made available for publication and any assurances of
+   licenses to be made available, or the result of an attempt made to
+   obtain a general license or permission for the use of such
+   proprietary rights by implementors or users of this specification can
+   be obtained from the IETF Secretariat.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights which may cover technology that may be required to practice
+   this standard.  Please address the information to the IETF Executive
+   Director.
+
+9.  Acknowledgments
+
+   The following people have provided input on this document: Robert
+   Elz, Andreas Gustafsson, Bob Halley, Steven Jacob, Erik Nordmark,
+   Edward Lewis, Jakob Schlyter, Roy Arends, Ted Lindgreen.
+
+10.  Normative References
+
+   [RFC1035] Mockapetris, P., "Domain Names - Implementation and
+             Specification", STD 13, RFC 1035, November 1987.
+
+   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+             Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC
+             2535, March 1999.
+
+   [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D. and B.
+             Wellington, "Secret Key Transaction Authentication for DNS
+             (TSIG)", RFC 2845, May 2000.
+
+   [RFC2931] Eastlake, D., "DNS Request and Transaction Signatures
+             (SIG(0))", RFC 2931, September 2000.
+
+   [RFC3225] Conrad, D., "Indicating Resolver Support of DNSSEC", RFC
+             3225, December 2001.
+
+
+
+Wellington & Gudmundsson    Standards Track                     [Page 6]
+
+RFC 3655               Redefinition of DNS AD bit          November 2003
+
+
+11.  Authors' Addresses
+
+   Brian Wellington
+   Nominum Inc.
+   2385 Bay Road
+   Redwood City, CA, 94063
+   USA
+
+   EMail: Brian.Wellington@nominum.com
+
+
+   Olafur Gudmundsson
+   3821 Village Park Drive
+   Chevy Chase, MD, 20815
+   USA
+
+   EMail: ogud@ogud.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wellington & Gudmundsson    Standards Track                     [Page 7]
+
+RFC 3655               Redefinition of DNS AD bit          November 2003
+
+
+12.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assignees.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wellington & Gudmundsson    Standards Track                     [Page 8]
+
diff --git a/doc/rfc/rfc3658.txt b/doc/rfc/rfc3658.txt
new file mode 100644
index 0000000..88cfb5a
--- /dev/null
+++ b/doc/rfc/rfc3658.txt
@@ -0,0 +1,1067 @@
+
+
+
+
+
+
+Network Working Group                                     O. Gudmundsson
+Request for Comments: 3658                                 December 2003
+Updates: 3090, 3008, 2535, 1035
+Category: Standards Track
+
+
+              Delegation Signer (DS) Resource Record (RR)
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+Abstract
+
+   The delegation signer (DS) resource record (RR) is inserted at a zone
+   cut (i.e., a delegation point) to indicate that the delegated zone is
+   digitally signed and that the delegated zone recognizes the indicated
+   key as a valid zone key for the delegated zone.  The DS RR is a
+   modification to the DNS Security Extensions definition, motivated by
+   operational considerations.  The intent is to use this resource
+   record as an explicit statement about the delegation, rather than
+   relying on inference.
+
+   This document defines the DS RR, gives examples of how it is used and
+   describes the implications on resolvers.  This change is not
+   backwards compatible with RFC 2535.  This document updates RFC 1035,
+   RFC 2535, RFC 3008 and RFC 3090.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gudmundsson                 Standards Track                     [Page 1]
+
+RFC 3658      Delegation Signer (DS) Resource Record (RR)  December 2003
+
+
+Table of Contents
+
+   1.  Introduction. . . . . . . . . . . . . . . . . . . . . . . . .   3
+       1.2.  Reserved Words. . . . . . . . . . . . . . . . . . . . .   4
+   2.  Specification of the Delegation key Signer. . . . . . . . . .   4
+       2.1.  Delegation Signer Record Model. . . . . . . . . . . . .   4
+       2.2.  Protocol Change . . . . . . . . . . . . . . . . . . . .   5
+             2.2.1.  RFC 2535 2.3.4 and 3.4: Special Considerations
+                     at Delegation Points  . . . . . . . . . . . . .   6
+                     2.2.1.1. Special processing for DS queries. . .   6
+                     2.2.1.2. Special processing when child and an
+                              ancestor share nameserver. . . . . . .   7
+                     2.2.1.3. Modification on use of KEY RR in the
+                              construction of Responses. . . . . . .   8
+             2.2.2.  Signer's Name (replaces RFC3008 section 2.7). .   9
+             2.2.3.  Changes to RFC 3090 . . . . . . . . . . . . . .   9
+                     2.2.3.1. RFC 3090: Updates to section 1:
+                              Introduction . . . . . . . . . . . . .   9
+                     2.2.3.2. RFC 3090 section 2.1: Globally
+                              Secured. . . . . . . . . . . . . . . .  10
+                     2.2.3.3. RFC 3090 section 3: Experimental
+                              Status . . . . . . . . . . . . . . . .  10
+             2.2.4.  NULL KEY elimination. . . . . . . . . . . . . .  10
+       2.3.  Comments on Protocol Changes. . . . . . . . . . . . . .  10
+       2.4.  Wire Format of the DS record. . . . . . . . . . . . . .  11
+             2.4.1.  Justifications for Fields . . . . . . . . . . .  12
+       2.5.  Presentation Format of the DS Record. . . . . . . . . .  12
+       2.6.  Transition Issues for Installed Base. . . . . . . . . .  12
+             2.6.1.  Backwards compatibility with RFC 2535 and
+                     RFC 1035. . . . . . . . . . . . . . . . . . . .  12
+       2.7.  KEY and corresponding DS record example . . . . . . . .  13
+   3.  Resolver. . . . . . . . . . . . . . . . . . . . . . . . . . .  14
+       3.1.  DS Example" . . . . . . . . . . . . . . . . . . . . . .  14
+       3.2.  Resolver Cost Estimates for DS Records" . . . . . . . .  15
+   4.  Security Considerations . . . . . . . . . . . . . . . . . . .  15
+   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  16
+   6.  Intellectual Property Statement . . . . . . . . . . . . . . .  16
+   7.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  17
+   8.  References. . . . . . . . . . . . . . . . . . . . . . . . . .  17
+       8.1.  Normative References. . . . . . . . . . . . . . . . . .  17
+       8.2.  Informational References. . . . . . . . . . . . . . . .  17
+   9.  Author's Address. . . . . . . . . . . . . . . . . . . . . . .  18
+   10. Full Copyright Statement. . . . . . . . . . . . . . . . . . .  19
+
+
+
+
+
+
+
+
+Gudmundsson                 Standards Track                     [Page 2]
+
+RFC 3658      Delegation Signer (DS) Resource Record (RR)  December 2003
+
+
+1.  Introduction
+
+   Familiarity with the DNS system [RFC1035], DNS security extensions
+   [RFC2535], and DNSSEC terminology [RFC3090] is important.
+
+   Experience shows that when the same data can reside in two
+   administratively different DNS zones, the data frequently gets out of
+   sync.  The presence of an NS RRset in a zone anywhere other than at
+   the apex indicates a zone cut or delegation.  The RDATA of the NS
+   RRset specifies the authoritative nameservers for the delegated or
+   "child" zone.  Based on actual measurements, 10-30% of all
+   delegations on the Internet have differing NS RRsets at parent and
+   child.  There are a number of reasons for this, including a lack of
+   communication between parent and child and bogus name servers being
+   listed to meet registry requirements.
+
+   DNSSEC [RFC2535, RFC3008, RFC3090] specifies that a child zone needs
+   to have its KEY RRset signed by its parent to create a verifiable
+   chain of KEYs.  There has been some debate on where the signed KEY
+   RRset should reside, whether at the child [RFC2535] or at the parent.
+   If the KEY RRset resides at the child, maintaining the signed KEY
+   RRset in the child requires frequent two-way communication between
+   the two parties.  First, the child transmits the KEY RRset to the
+   parent and then the parent sends the signature(s) to the child.
+   Storing the KEY RRset at the parent was thought to simplify the
+   communication.
+
+   DNSSEC [RFC2535] requires that the parent store a NULL KEY record for
+   an unsecure child zone to indicate that the child is unsecure.  A
+   NULL KEY record is a waste: an entire signed RRset is used to
+   communicate effectively one bit of information - that the child is
+   unsecure. Chasing down NULL KEY RRsets complicates the resolution
+   process in many cases, because nameservers for both parent and child
+   need to be queried for the KEY RRset if the child nameserver does not
+   return it.  Storing the KEY RRset only in the parent zone simplifies
+   this and would allow the elimination of the NULL KEY RRsets entirely.
+   For large delegation zones, the cost of NULL keys is a significant
+   barrier to deployment.
+
+   Prior to the restrictions imposed by RFC 3445 [RFC3445], another
+   implication of the DNSSEC key model is that the KEY record could be
+   used to store public keys for other protocols in addition to DNSSEC
+   keys.  There are a number of potential problems with this, including:
+
+   1. The KEY RRset can become quite large if many applications and
+      protocols store their keys at the zone apex.  Possible protocols
+      are IPSEC, HTTP, SMTP, SSH and others that use public key
+      cryptography.
+
+
+
+Gudmundsson                 Standards Track                     [Page 3]
+
+RFC 3658      Delegation Signer (DS) Resource Record (RR)  December 2003
+
+
+   2. The KEY RRset may require frequent updates.
+
+   3. The probability of compromised or lost keys, which trigger
+      emergency key roll-over procedures, increases.
+
+   4. The parent may refuse to sign KEY RRsets with non-DNSSEC zone
+      keys.
+
+   5. The parent may not meet the child's expectations of turnaround
+      time for resigning the KEY RRset.
+
+   Given these reasons, SIG@parent isn't any better than SIG/KEY@Child.
+
+1.2.  Reserved Words
+
+   The key words "MAY", "MAY NOT", "MUST", "MUST NOT", "REQUIRED",
+   "RECOMMENDED", "SHOULD", and "SHOULD NOT" in this document are to be
+   interpreted as described in BCP 14, RFC 2119 [RFC2119].
+
+2.  Specification of the Delegation key Signer
+
+   This section defines the Delegation Signer (DS) RR type (type code
+   43) and the changes to DNS to accommodate it.
+
+2.1.  Delegation Signer Record Model
+
+   This document presents a replacement for the DNSSEC KEY record chain
+   of trust [RFC2535] that uses a new RR that resides only at the
+   parent.  This record identifies the key(s) that the child uses to
+   self-sign its own KEY RRset.
+
+   Even though DS identifies two roles for KEYs, Key Signing Key (KSK)
+   and Zone Signing Key (ZSK), there is no requirement that zone uses
+   two different keys for these roles.  It is expected that many small
+   zones will only use one key, while larger zones will be more likely
+   to use multiple keys.
+
+   The chain of trust is now established by verifying the parent KEY
+   RRset, the DS RRset from the parent and the KEY RRset at the child.
+   This is cryptographically equivalent to using just KEY records.
+
+   Communication between the parent and child is greatly reduced, since
+   the child only needs to notify the parent about changes in keys that
+   sign its apex KEY RRset.  The parent is ignorant of all other keys in
+   the child's apex KEY RRset.  Furthermore, the child maintains full
+   control over the apex KEY RRset and its content.  The child can
+   maintain any policies regarding its KEY usage for DNSSEC with minimal
+   impact on the parent.  Thus, if the child wants to have frequent key
+
+
+
+Gudmundsson                 Standards Track                     [Page 4]
+
+RFC 3658      Delegation Signer (DS) Resource Record (RR)  December 2003
+
+
+   roll-over for its DNS zone keys, the parent does not need to be aware
+   of it.  The child can use one key to sign only its apex KEY RRset and
+   a different key to sign the other RRsets in the zone.
+
+   This model fits well with a slow roll out of DNSSEC and the islands
+   of security model.  In this model, someone who trusts "good.example."
+   can preconfigure a key from "good.example." as a trusted key, and
+   from then on trusts any data signed by that key or that has a chain
+   of trust to that key.  If "example." starts advertising DS records,
+   "good.example." does not have to change operations by suspending
+   self-signing.  DS records can be used in configuration files to
+   identify trusted keys instead of KEY records.  Another significant
+   advantage is that the amount of information stored in large
+   delegation zones is reduced: rather than the NULL KEY record at every
+   unsecure delegation demanded by RFC 2535, only secure delegations
+   require additional information in the form of a signed DS RRset.
+
+   The main disadvantage of this approach is that verifying a zone's KEY
+   RRset requires two signature verification operations instead of the
+   one in RFC 2535 chain of trust.  There is no impact on the number of
+   signatures verified for other types of RRsets.
+
+2.2.  Protocol Change
+
+   All DNS servers and resolvers that support DS MUST support the OK bit
+   [RFC3225] and a larger message size [RFC3226].  In order for a
+   delegation to be considered secure the delegation MUST contain a DS
+   RRset.  If a query contains the OK bit, a nameserver returning a
+   referral for the delegation MUST include the following RRsets in the
+   authority section in this order:
+
+   If DS RRset is present:
+      parent's copy of child's NS RRset
+      DS and SIG(DS)
+
+   If no DS RRset is present:
+      parent's copy of child's NS RRset
+      parent's zone NXT and SIG(NXT)
+
+   This increases the size of referral messages, possibly causing some
+   or all glue to be omitted.  If the DS or NXT RRsets with signatures
+   do not fit in the DNS message, the TC bit MUST be set.  Additional
+   section processing is not changed.
+
+   A DS RRset accompanying a NS RRset indicates that the child zone is
+   secure.  If a NS RRset exists without a DS RRset, the child zone is
+   unsecure (from the parents point of view).  DS RRsets MUST NOT appear
+   at non-delegation points or at a zone's apex.
+
+
+
+Gudmundsson                 Standards Track                     [Page 5]
+
+RFC 3658      Delegation Signer (DS) Resource Record (RR)  December 2003
+
+
+   Section 2.2.1 defines special considerations related to authoritative
+   nameservers responding to DS queries and replaces RFC 2535 sections
+   2.3.4 and 3.4.  Section 2.2.2 replaces RFC 3008 section 2.7, and
+   section 2.2.3 updates RFC 3090.
+
+2.2.1.  RFC 2535 2.3.4 and 3.4: Special Considerations at Delegation
+        Points
+
+   DNS security views each zone as a unit of data completely under the
+   control of the zone owner with each entry (RRset) signed by a special
+   private key held by the zone manager.  But the DNS protocol views the
+   leaf nodes in a zone that are also the apex nodes of a child zone
+   (i.e., delegation points) as "really" belonging to the child zone.
+   The corresponding domain names appear in two master files and might
+   have RRsets signed by both the parent and child zones' keys.  A
+   retrieval could get a mixture of these RRsets and SIGs, especially
+   since one nameserver could be serving both the zone above and below a
+   delegation point [RFC2181].
+
+   Each DS RRset stored in the parent zone MUST be signed by at least
+   one of the parent zone's private keys.  The parent zone MUST NOT
+   contain a KEY RRset at any delegation point.  Delegations in the
+   parent MAY contain only the following RR types: NS, DS, NXT and SIG.
+   The NS RRset MUST NOT be signed.  The NXT RRset is the exceptional
+   case: it will always appear differently and authoritatively in both
+   the parent and child zones, if both are secure.
+
+   A secure zone MUST contain a self-signed KEY RRset at its apex.  Upon
+   verifying the DS RRset from the parent, a resolver MAY trust any KEY
+   identified in the DS RRset as a valid signer of the child's apex KEY
+   RRset.  Resolvers configured to trust one of the keys signing the KEY
+   RRset MAY now treat any data signed by the zone keys in the KEY RRset
+   as secure.  In all other cases, resolvers MUST consider the zone
+   unsecure.
+
+   An authoritative nameserver queried for type DS MUST return the DS
+   RRset in the answer section.
+
+2.2.1.1.  Special processing for DS queries
+
+   When a nameserver is authoritative for the parent zone at a
+   delegation point and receives a query for the DS record at that name,
+   it MUST answer based on data in the parent zone, return DS or
+   negative answer.  This is true whether or not it is also
+   authoritative for the child zone.
+
+
+
+
+
+
+Gudmundsson                 Standards Track                     [Page 6]
+
+RFC 3658      Delegation Signer (DS) Resource Record (RR)  December 2003
+
+
+   When the nameserver is authoritative for the child zone at a
+   delegation point but not the parent zone, there is no natural
+   response, since the child zone is not authoritative for the DS record
+   at the zone's apex.  As these queries are only expected to originate
+   from recursive nameservers which are not DS-aware, the authoritative
+   nameserver MUST answer with:
+
+      RCODE:             NOERROR
+      AA bit:            set
+      Answer Section:    Empty
+      Authority Section: SOA [+ SIG(SOA) + NXT + SIG(NXT)]
+
+   That is, it answers as if it is authoritative and the DS record does
+   not exist.  DS-aware recursive nameservers will query the parent zone
+   at delegation points, so will not be affected by this.
+
+   A nameserver authoritative for only the child zone, that is also a
+   caching server MAY (if the RD bit is set in the query) perform
+   recursion to find the DS record at the delegation point, or MAY
+   return the DS record from its cache.  In this case, the AA bit MUST
+   NOT be set in the response.
+
+2.2.1.2.  Special processing when child and an ancestor share
+          nameserver
+
+   Special rules are needed to permit DS RR aware nameservers to
+   gracefully interact with older caches which otherwise might falsely
+   label a nameserver as lame because of the placement of the DS RR set.
+
+   Such a situation might arise when a nameserver is authoritative for
+   both a zone and it's grandparent, but not the parent.  This sounds
+   like an obscure example, but it is very real.  The root zone is
+   currently served on 13 machines, and "root-servers.net." is served on
+   4 of the 13, but "net." is severed on different nameservers.
+
+   When a nameserver receives a query for (<QNAME>, DS, <QCLASS>), the
+   response MUST be determined from reading these rules in order:
+
+   1) If the nameserver is authoritative for the zone that holds the DS
+      RR set (i.e., the zone that delegates <QNAME>, a.k.a. the "parent"
+      zone), the response contains the DS RR set as an authoritative
+      answer.
+
+   2) If the nameserver is offering recursive service and the RD bit is
+      set in the query, the nameserver performs the query itself
+      (according to the rules for resolvers described below) and returns
+      its findings.
+
+
+
+
+Gudmundsson                 Standards Track                     [Page 7]
+
+RFC 3658      Delegation Signer (DS) Resource Record (RR)  December 2003
+
+
+   3) If the nameserver is authoritative for the zone that holds the
+      <QNAME>'s SOA RR set, the response is an authoritative negative
+      answer as described in 2.2.1.1.
+
+   4) If the nameserver is authoritative for a zone or zones above the
+      QNAME, a referral to the most enclosing (deepest match) zone's
+      servers is made.
+
+   5) If the nameserver is not authoritative for any part of the QNAME,
+      a response indicating a lame nameserver for QNAME is given.
+
+   Using these rules will require some special processing on the part of
+   a DS RR aware resolver.  To illustrate this, an example is used.
+
+   Assuming a nameserver is authoritative for roots.example.net. and for
+   the root zone but not the intervening two zones (or the intervening
+   two label deep zone).  Assume that QNAME=roots.example.net.,
+   QTYPE=DS, and QCLASS=IN.
+
+   The resolver will issue this request (assuming no cached data)
+   expecting a referral to a nameserver for .net.  Instead, rule number
+   3 above applies and a negative answer is returned by the nameserver.
+   The reaction by the resolver is not to accept this answer as final,
+   as it can determine from the SOA RR in the negative answer the
+   context within which the nameserver has answered.
+
+   A solution would be to instruct the resolver to hunt for the
+   authoritative zone of the data in a brute force manner.
+
+   This can be accomplished by taking the owner name of the returned SOA
+   RR and striping off enough left-hand labels until a successful NS
+   response is obtained.  A successful response here means that the
+   answer has NS records in it.  (Entertaining the possibility that a
+   cut point can be two labels down in a zone.)
+
+   Returning to the example, the response will include a negative answer
+   with either the SOA RR for "roots.example.net." or "example.net."
+   depending on whether roots.example.net is a delegated domain.  In
+   either case, removing the left most label of the SOA owner name will
+   lead to the location of the desired data.
+
+2.2.1.3.  Modification on use of KEY RR in the construction of Responses
+
+   This section updates RFC 2535 section 3.5 by replacing it with the
+   following:
+
+
+
+
+
+
+Gudmundsson                 Standards Track                     [Page 8]
+
+RFC 3658      Delegation Signer (DS) Resource Record (RR)  December 2003
+
+
+   A query for KEY RR MUST NOT trigger any additional section
+   processing.  Security aware resolvers will include corresponding SIG
+   records in the answer section.
+
+   KEY records SHOULD NOT be added to the additional records section in
+   response to any query.
+
+   RFC 2535 specified that KEY records be added to the additional
+   section when SOA or NS records were included in an answer.  This was
+   done to reduce round trips (in the case of SOA) and to force out NULL
+   KEYs (in the NS case).  As this document obsoletes NULL keys, there
+   is no need for the inclusion of KEYs with NSs.  Furthermore, as SOAs
+   are included in the authority section of negative answers, including
+   the KEYs each time will cause redundant transfers of KEYs.
+
+   RFC 2535 section 3.5 also included a rule for adding the KEY RRset to
+   the response for a query for A and AAAA types.  As Restrict KEY
+   [RFC3445] eliminated use of KEY RR by all applications, this rule is
+   no longer needed.
+
+2.2.2.  Signer's Name (replaces RFC 3008 section 2.7)
+
+   The signer's name field of a SIG RR MUST contain the name of the zone
+   to which the data and signature belong.  The combination of signer's
+   name, key tag, and algorithm MUST identify a zone key if the SIG is
+   to be considered material.  This document defines a standard policy
+   for DNSSEC validation; local policy MAY override the standard policy.
+
+   There are no restrictions on the signer field of a SIG(0) record. The
+   combination of signer's name, key tag, and algorithm MUST identify a
+   key if this SIG(0) is to be processed.
+
+2.2.3.  Changes to RFC 3090
+
+   A number of sections in RFC 3090 need to be updated to reflect the DS
+   record.
+
+2.2.3.1.  RFC 3090: Updates to section 1: Introduction
+
+   Most of the text is still relevant but the words "NULL key" are to be
+   replaced with "missing DS RRset".  In section 1.3, the last three
+   paragraphs discuss the confusion in sections of RFC 2535 that are
+   replaced in section 2.2.1 above.  Therefore, these paragraphs are now
+   obsolete.
+
+
+
+
+
+
+
+Gudmundsson                 Standards Track                     [Page 9]
+
+RFC 3658      Delegation Signer (DS) Resource Record (RR)  December 2003
+
+
+2.2.3.2.  RFC 3090 section 2.1: Globally Secured
+
+   Rule 2.1.b is replaced by the following rule:
+
+   2.1.b. The KEY RRset at a zone's apex MUST be self-signed by a
+   private key whose public counterpart MUST appear in a zone signing
+   KEY RR (2.a) owned by the zone's apex and specifying a mandatory-to-
+   implement algorithm.  This KEY RR MUST be identified by a DS RR in a
+   signed DS RRset in the parent zone.
+
+   If a zone cannot get its parent to advertise a DS record for it, the
+   child zone cannot be considered globally secured.  The only exception
+   to this is the root zone, for which there is no parent zone.
+
+2.2.3.3.  RFC 3090 section 3: Experimental Status.
+
+   The only difference between experimental status and globally secured
+   is the missing DS RRset in the parent zone.  All locally secured
+   zones are experimental.
+
+2.2.4.  NULL KEY elimination
+
+   RFC 3445 section 3 eliminates the top two bits in the flags field of
+   KEY RR.  These two bits were used to indicate NULL KEY or NO KEY. RFC
+   3090 defines that zone as either secure or not and these rules
+   eliminate the need to put NULL keys in the zone apex to indicate that
+   the zone is not secured for a algorithm.  Along with this document,
+   these other two eliminate all uses for the NULL KEY.  This document
+   obsoletes NULL KEY.
+
+2.3.  Comments on Protocol Changes
+
+   Over the years, there have been various discussions surrounding the
+   DNS delegation model, declaring it to be broken because there is no
+   good way to assert if a delegation exists.  In the RFC 2535 version
+   of DNSSEC, the presence of the NS bit in the NXT bit map proves there
+   is a delegation at this name.  Something more explicit is required
+   and the DS record addresses this need for secure delegations.
+
+   The DS record is a major change to DNS: it is the first resource
+   record that can appear only on the upper side of a delegation.
+   Adding it will cause interoperability problems and requires a flag
+   day for DNSSEC.  Many old nameservers and resolvers MUST be upgraded
+   to take advantage of DS.  Some old nameservers will be able to be
+   authoritative for zones with DS records but will not add the NXT or
+   DS records to the authority section.  The same is true for caching
+   nameservers; in fact, some might even refuse to pass on the DS or NXT
+   records.
+
+
+
+Gudmundsson                 Standards Track                    [Page 10]
+
+RFC 3658      Delegation Signer (DS) Resource Record (RR)  December 2003
+
+
+2.4.  Wire Format of the DS record
+
+   The DS (type=43) record contains these fields: key tag, algorithm,
+   digest type, and the digest of a public key KEY record that is
+   allowed and/or used to sign the child's apex KEY RRset.  Other keys
+   MAY sign the child's apex KEY RRset.
+
+                        1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |           key tag             |  algorithm    |  Digest type  |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                digest  (length depends on type)               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                (SHA-1 digest is 20 bytes)                     |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   The key tag is calculated as specified in RFC 2535.  Algorithm MUST
+   be allowed to sign DNS data.  The digest type is an identifier for
+   the digest algorithm used.  The digest is calculated over the
+   canonical name of the delegated domain name followed by the whole
+   RDATA of the KEY record (all four fields).
+
+      digest = hash( canonical FQDN on KEY RR | KEY_RR_rdata)
+
+      KEY_RR_rdata = Flags | Protocol | Algorithm | Public Key
+
+   Digest type value 0 is reserved, value 1 is SHA-1, and reserving
+   other types requires IETF standards action.  For interoperability
+   reasons, keeping number of digest algorithms low is strongly
+   RECOMMENDED.  The only reason to reserve additional digest types is
+   to increase security.
+
+   DS records MUST point to zone KEY records that are allowed to
+   authenticate DNS data.  The indicated KEY records protocol field MUST
+   be set to 3; flag field bit 7 MUST be set to 1.  The value of other
+   flag bits is not significant for the purposes of this document.
+
+   The size of the DS RDATA for type 1 (SHA-1) is 24 bytes, regardless
+   of key size.  New digest types probably will have larger digests.
+
+
+
+
+
+Gudmundsson                 Standards Track                    [Page 11]
+
+RFC 3658      Delegation Signer (DS) Resource Record (RR)  December 2003
+
+
+2.4.1.  Justifications for Fields
+
+   The algorithm and key tag fields are present to allow resolvers to
+   quickly identify the candidate KEY records to examine.  SHA-1 is a
+   strong cryptographic checksum: it is computationally infeasible for
+   an attacker to generate a KEY record that has the same SHA-1 digest.
+   Combining the name of the key and the key rdata as input to the
+   digest provides stronger assurance of the binding.  Having the key
+   tag in the DS record adds greater assurance than the SHA-1 digest
+   alone, as there are now two different mapping functions.
+
+   This format allows concise representation of the keys that the child
+   will use, thus keeping down the size of the answer for the
+   delegation, reducing the probability of DNS message overflow.  The
+   SHA-1 hash is strong enough to uniquely identify the key and is
+   similar to the PGP key footprint.  The digest type field is present
+   for possible future expansion.
+
+   The DS record is well suited to listing trusted keys for islands of
+   security in configuration files.
+
+2.5.  Presentation Format of the DS Record
+
+   The presentation format of the DS record consists of three numbers
+   (key tag, algorithm, and digest type) followed by the digest itself
+   presented in hex:
+
+      example.   DS  12345 3 1 123456789abcdef67890123456789abcdef67890
+
+2.6.  Transition Issues for Installed Base
+
+   No backwards compatibility with RFC 2535 is provided.
+
+   RFC 2535-compliant resolvers will assume that all DS-secured
+   delegations are locally secure.  This is bad, but the DNSEXT Working
+   Group has determined that rather than dealing with both RFC 2535-
+   secured zones and DS-secured zones, a rapid adoption of DS is
+   preferable.  Thus, the only option for early adopters is to upgrade
+   to DS as soon as possible.
+
+2.6.1.  Backwards compatibility with RFC 2535 and RFC 1035
+
+   This section documents how a resolver determines the type of
+   delegation.
+
+
+
+
+
+
+
+Gudmundsson                 Standards Track                    [Page 12]
+
+RFC 3658      Delegation Signer (DS) Resource Record (RR)  December 2003
+
+
+   RFC 1035 delegation (in parent) has:
+
+   RFC 1035           NS
+
+   RFC 2535 adds the following two cases:
+
+   Secure RFC 2535:   NS + NXT + SIG(NXT)
+                      NXT bit map contains: NS SIG NXT
+   Unsecure RFC 2535: NS + KEY + SIG(KEY) + NXT + SIG(NXT)
+                      NXT bit map contains: NS SIG KEY NXT
+                      KEY must be a NULL key.
+
+   DNSSEC with DS has the following two states:
+
+   Secure DS:         NS + DS + SIG(DS)
+                      NXT bit map contains: NS SIG NXT DS
+   Unsecure DS:       NS + NXT + SIG(NXT)
+                      NXT bit map contains: NS SIG NXT
+
+   It is difficult for a resolver to determine if a delegation is secure
+   RFC 2535 or unsecure DS.  This could be overcome by adding a flag to
+   the NXT bit map, but only upgraded resolvers would understand this
+   flag, anyway.  Having both parent and child signatures for a KEY
+   RRset might allow old resolvers to accept a zone as secure, but the
+   cost of doing this for a long time is much higher than just
+   prohibiting RFC 2535-style signatures at child zone apexes and
+   forcing rapid deployment of DS-enabled nameservers and resolvers.
+
+   RFC 2535 and DS can, in theory, be deployed in parallel, but this
+   would require resolvers to deal with RFC 2535 configurations forever.
+   This document obsoletes the NULL KEY in parent zones, which is a
+   difficult enough change that to cause a flag day.
+
+2.7.  KEY and corresponding DS record example
+
+   This is an example of a KEY record and the corresponding DS record.
+
+   dskey.example. KEY  256 3 1 (
+                  AQPwHb4UL1U9RHaU8qP+Ts5bVOU1s7fYbj2b3CCbzNdj
+                  4+/ECd18yKiyUQqKqQFWW5T3iVc8SJOKnueJHt/Jb/wt
+                  ) ; key id = 28668
+             DS   28668 1  1  49FD46E6C4B45C55D4AC69CBD3CD34AC1AFE51DE
+
+
+
+
+
+
+
+
+
+Gudmundsson                 Standards Track                    [Page 13]
+
+RFC 3658      Delegation Signer (DS) Resource Record (RR)  December 2003
+
+
+3.  Resolver
+
+3.1.  DS Example
+
+   To create a chain of trust, a resolver goes from trusted KEY to DS to
+   KEY.
+
+      Assume the key for domain "example." is trusted.  Zone "example."
+      contains at least the following records:
+      example.          SOA     <soa stuff>
+      example.          NS       ns.example.
+      example.          KEY     <stuff>
+      example.          NXT      secure.example. NS SOA KEY SIG NXT
+      example.          SIG(SOA)
+      example.          SIG(NS)
+      example.          SIG(NXT)
+      example.          SIG(KEY)
+      secure.example.   NS      ns1.secure.example.
+      secure.example.   DS      tag=12345 alg=3 digest_type=1 <foofoo>
+      secure.example.   NXT     unsecure.example. NS SIG NXT DS
+      secure.example.   SIG(NXT)
+      secure.example.   SIG(DS)
+      unsecure.example  NS      ns1.unsecure.example.
+      unsecure.example. NXT     example. NS SIG NXT
+      unsecure.example. SIG(NXT)
+
+      In zone "secure.example." following records exist:
+      secure.example.   SOA      <soa stuff>
+      secure.example.   NS       ns1.secure.example.
+      secure.example.   KEY      <tag=12345 alg=3>
+      secure.example.   KEY      <tag=54321 alg=5>
+      secure.example.   NXT      <nxt stuff>
+      secure.example.   SIG(KEY) <key-tag=12345 alg=3>
+      secure.example.   SIG(SOA) <key-tag=54321 alg=5>
+      secure.example.   SIG(NS)  <key-tag=54321 alg=5>
+      secure.example.   SIG(NXT) <key-tag=54321 alg=5>
+
+   In this example, the private key for "example." signs the DS record
+   for "secure.example.", making that a secure delegation.  The DS
+   record states which key is expected to sign the KEY RRset at
+   "secure.example.".  Here "secure.example." signs its KEY RRset with
+   the KEY identified in the DS RRset, thus the KEY RRset is validated
+   and trusted.
+
+   This example has only one DS record for the child, but parents MUST
+   allow multiple DS records to facilitate key roll-over and multiple
+   KEY algorithms.
+
+
+
+
+Gudmundsson                 Standards Track                    [Page 14]
+
+RFC 3658      Delegation Signer (DS) Resource Record (RR)  December 2003
+
+
+   The resolver determines the security status of "unsecure.example." by
+   examining the parent zone's NXT record for this name.  The absence of
+   the DS bit indicates an unsecure delegation.  Note the NXT record
+   SHOULD only be examined after verifying the corresponding signature.
+
+3.2.  Resolver Cost Estimates for DS Records
+
+   From a RFC 2535 recursive resolver point of view, for each delegation
+   followed to chase down an answer, one KEY RRset has to be verified.
+   Additional RRsets might also need to be verified based on local
+   policy (e.g., the contents of the NS RRset).  Once the resolver gets
+   to the appropriate delegation, validating the answer might require
+   verifying one or more signatures.  A simple A record lookup requires
+   at least N delegations to be verified and one RRset.  For a DS-
+   enabled recursive resolver, the cost is 2N+1.  For an MX record,
+   where the target of the MX record is in the same zone as the MX
+   record, the costs are N+2 and 2N+2, for RFC 2535 and DS,
+   respectively.  In the case of a negative answer, the same ratios hold
+   true.
+
+   The recursive resolver has to do an extra query to get the DS record,
+   which will increase the overall cost of resolving this question, but
+   it will never be worse than chasing down NULL KEY records from the
+   parent in RFC 2535 DNSSEC.
+
+   DS adds processing overhead on resolvers and increases the size of
+   delegation answers, but much less than storing signatures in the
+   parent zone.
+
+4.  Security Considerations
+
+   This document proposes a change to the validation chain of KEY
+   records in DNSSEC.  The change is not believed to reduce security in
+   the overall system.  In RFC 2535 DNSSEC, the child zone has to
+   communicate keys to its parent and prudent parents will require some
+   authentication with that transaction.  The modified protocol will
+   require the same authentication, but allows the child to exert more
+   local control over its own KEY RRset.
+
+   There is a remote possibility that an attacker could generate a valid
+   KEY that matches all the DS fields, of a specific DS set, and thus
+   forge data from the child.  This possibility is considered
+   impractical, as on average more than
+
+      2 ^ (160 - <Number of keys in DS set>)
+
+   keys would have to be generated before a match would be found.
+
+
+
+
+Gudmundsson                 Standards Track                    [Page 15]
+
+RFC 3658      Delegation Signer (DS) Resource Record (RR)  December 2003
+
+
+   An attacker that wants to match any DS record will have to generate
+   on average at least 2^80 keys.
+
+   The DS record represents a change to the DNSSEC protocol and there is
+   an installed base of implementations, as well as textbooks on how to
+   set up secure delegations.  Implementations that do not understand
+   the DS record will not be able to follow the KEY to DS to KEY chain
+   and will consider all zones secured that way as unsecure.
+
+5.  IANA Considerations
+
+   IANA has allocated an RR type code for DS from the standard RR type
+   space (type 43).
+
+   IANA has established a new registry for the DS RR type for digest
+   algorithms.  Defined types are:
+
+      0 is Reserved,
+      1 is SHA-1.
+
+   Adding new reservations requires IETF standards action.
+
+6.  Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   intellectual property or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; neither does it represent that it
+   has made any effort to identify any such rights.  Information on the
+   IETF's procedures with respect to rights in standards-track and
+   standards-related documentation can be found in BCP-11.  Copies of
+   claims of rights made available for publication and any assurances of
+   licenses to be made available, or the result of an attempt made to
+   obtain a general license or permission for the use of such
+   proprietary rights by implementors or users of this specification can
+   be obtained from the IETF Secretariat.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights which may cover technology that may be required to practice
+   this standard.  Please address the information to the IETF Executive
+   Director.
+
+
+
+
+
+
+
+
+Gudmundsson                 Standards Track                    [Page 16]
+
+RFC 3658      Delegation Signer (DS) Resource Record (RR)  December 2003
+
+
+7.  Acknowledgments
+
+   Over the last few years a number of people have contributed ideas
+   that are captured in this document.  The core idea of using one key
+   to sign only the KEY RRset comes from discussions with Bill Manning
+   and Perry Metzger on how to put in a single root key in all
+   resolvers. Alexis Yushin, Brian Wellington, Sam Weiler, Paul Vixie,
+   Jakob Schlyter, Scott Rose, Edward Lewis, Lars-Johan Liman, Matt
+   Larson, Mark Kosters, Dan Massey, Olaf Kolman, Phillip Hallam-Baker,
+   Miek Gieben, Havard Eidnes, Donald Eastlake 3rd., Randy Bush, David
+   Blacka, Steve Bellovin, Rob Austein, Derek Atkins, Roy Arends, Mark
+   Andrews, Harald Alvestrand, and others have provided useful comments.
+
+8.  References
+
+8.1.  Normative References
+
+   [RFC1035]  Mockapetris, P., "Domain Names - Implementation and
+              Specification", STD 13, RFC 1035, November 1987.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2535]  Eastlake, D., "Domain Name System Security Extensions",
+              RFC 2535, March 1999.
+
+   [RFC3008]  Wellington, B., "Domain Name System Security (DNSSEC)
+              Signing Authority", RFC 3008, November 2000.
+
+   [RFC3090]  Lewis, E., "DNS Security Extension Clarification on Zone
+              Status", RFC 3090, March 2001.
+
+   [RFC3225]  Conrad, D., "Indicating Resolver Support of DNSSEC", RFC
+              3225, December 2001.
+
+   [RFC3445]  Massey, D. and S. Rose, "Limiting the scope of the KEY
+              Resource Record (RR)", RFC 3445, December 2002.
+
+8.2.  Informational References
+
+   [RFC2181]  Elz, R. and R. Bush, "Clarifications to the DNS
+              Specification", RFC 2181, July 1997.
+
+   [RFC3226]  Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver
+              message size requirements", RFC 3226, December 2001.
+
+
+
+
+
+
+Gudmundsson                 Standards Track                    [Page 17]
+
+RFC 3658      Delegation Signer (DS) Resource Record (RR)  December 2003
+
+
+9.  Author's Address
+
+   Olafur Gudmundsson
+   3821 Village Park Drive
+   Chevy Chase, MD,  20815
+
+   EMail: ds-rfc@ogud.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gudmundsson                 Standards Track                    [Page 18]
+
+RFC 3658      Delegation Signer (DS) Resource Record (RR)  December 2003
+
+
+10.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assignees.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gudmundsson                 Standards Track                    [Page 19]
+
diff --git a/doc/rfc/rfc3757.txt b/doc/rfc/rfc3757.txt
new file mode 100644
index 0000000..31890a4
--- /dev/null
+++ b/doc/rfc/rfc3757.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Network Working Group                                         O. Kolkman
+Request for Comments: 3757                                      RIPE NCC
+Updates: 3755, 2535                                          J. Schlyter
+Category: Standards Track                                         NIC-SE
+                                                                E. Lewis
+                                                                    ARIN
+                                                              April 2004
+
+
+         Domain Name System KEY (DNSKEY) Resource Record (RR)
+                     Secure Entry Point (SEP) Flag
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2004).  All Rights Reserved.
+
+Abstract
+
+   With the Delegation Signer (DS) resource record (RR), the concept of
+   a public key acting as a secure entry point (SEP) has been
+   introduced.  During exchanges of public keys with the parent there is
+   a need to differentiate SEP keys from other public keys in the Domain
+   Name System KEY (DNSKEY) resource record set.  A flag bit in the
+   DNSKEY RR is defined to indicate that DNSKEY is to be used as a SEP.
+   The flag bit is intended to assist in operational procedures to
+   correctly generate DS resource records, or to indicate what DNSKEYs
+   are intended for static configuration.  The flag bit is not to be
+   used in the DNS verification protocol.  This document updates RFC
+   2535 and RFC 3755.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kolkman, et al.              Standard Track                     [Page 1]
+
+RFC 3757                   DNSKEY RR SEP Flag                 April 2004
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
+   2.  The Secure Entry Point (SEP) Flag. . . . . . . . . . . . . . .  4
+   3.  DNSSEC Protocol Changes. . . . . . . . . . . . . . . . . . . .  4
+   4.  Operational Guidelines . . . . . . . . . . . . . . . . . . . .  4
+   5.  Security Considerations. . . . . . . . . . . . . . . . . . . .  5
+   6.  IANA Considerations. . . . . . . . . . . . . . . . . . . . . .  6
+   7.  Internationalization Considerations. . . . . . . . . . . . . .  6
+   8.  Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . .  6
+   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  6
+       9.1.  Normative References . . . . . . . . . . . . . . . . . .  6
+       9.2.  Informative References . . . . . . . . . . . . . . . . .  6
+   10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . .  7
+   11. Full Copyright Statement . . . . . . . . . . . . . . . . . . .  8
+
+1.  Introduction
+
+   "All keys are equal but some keys are more equal than others" [6].
+
+   With the definition of the Delegation Signer Resource Record (DS RR)
+   [5], it has become important to differentiate between the keys in the
+   DNSKEY RR set that are (to be) pointed to by parental DS RRs and the
+   other keys in the DNSKEY RR set.  We refer to these public keys as
+   Secure Entry Point (SEP) keys.  A SEP key either used to generate a
+   DS RR or is distributed to resolvers that use the key as the root of
+   a trusted subtree [3].
+
+   In early deployment tests, the use of two (kinds of) key pairs for
+   each zone has been prevalent.  For one kind of key pair the private
+   key is used to sign just the zone's DNSKEY resource record (RR) set.
+   Its public key is intended to be referenced by a DS RR at the parent
+   or configured statically in a resolver.  The private key of the other
+   kind of key pair is used to sign the rest of the zone's data sets.
+   The former key pair is called a key-signing key (KSK) and the latter
+   is called a zone-signing key (ZSK).  In practice there have been
+   usually one of each kind of key pair, but there will be multiples of
+   each at times.
+
+   It should be noted that division of keys pairs into KSK's and ZSK's
+   is not mandatory in any definition of DNSSEC, not even with the
+   introduction of the DS RR.  But, in testing, this distinction has
+   been helpful when designing key roll over (key super-cession)
+   schemes.  Given that the distinction has proven helpful, the labels
+   KSK and ZSK have begun to stick.
+
+
+
+
+
+
+Kolkman, et al.              Standard Track                     [Page 2]
+
+RFC 3757                   DNSKEY RR SEP Flag                 April 2004
+
+
+   There is a need to differentiate the public keys for the key pairs
+   that are used for key signing from keys that are not used key signing
+   (KSKs vs ZSKs).  This need is driven by knowing which DNSKEYs are to
+   be sent for generating DS RRs, which DNSKEYs are to be distributed to
+   resolvers, and which keys are fed to the signer application at the
+   appropriate time.
+
+   In other words, the SEP bit provides an in-band method to communicate
+   a DNSKEY RR's intended use to third parties.  As an example we
+   present 3 use cases in which the bit is useful:
+
+      The parent is a registry, the parent and the child use secured DNS
+      queries and responses, with a preexisting trust-relation, or plain
+      DNS over a secured channel to exchange the child's DNSKEY RR sets.
+      Since a DNSKEY RR set will contain a complete DNSKEY RRset the SEP
+      bit can be used to isolate the DNSKEYs for which a DS RR needs to
+      be created.
+
+      An administrator has configured a DNSKEY as root for a trusted
+      subtree into security aware resolver.  Using a special purpose
+      tool that queries for the KEY RRs from that domain's apex, the
+      administrator will be able to notice the roll over of the trusted
+      anchor by a change of the subset of KEY RRs with the DS flag set.
+
+      A signer might use the SEP bit on the public key to determine
+      which private key to use to exclusively sign the DNSKEY RRset and
+      which private key to use to sign the other RRsets in the zone.
+
+   As demonstrated in the above examples it is important to be able to
+   differentiate the SEP keys from the other keys in a DNSKEY RR set in
+   the flow between signer and (parental) key-collector and in the flow
+   between the signer and the resolver configuration.  The SEP flag is
+   to be of no interest to the flow between the verifier and the
+   authoritative data store.
+
+   The reason for the term "SEP" is a result of the observation that the
+   distinction between KSK and ZSK key pairs is made by the signer, a
+   key pair could be used as both a KSK and a ZSK at the same time.  To
+   be clear, the term SEP was coined to lessen the confusion caused by
+   the overlap.  (Once this label was applied, it had the side effect of
+   removing the temptation to have both a KSK flag bit and a ZSK flag
+   bit.)
+
+   The key words "MAY","MAY NOT", "MUST", "MUST NOT", "REQUIRED",
+   "RECOMMENDED", "SHOULD", and "SHOULD NOT" in this document are to be
+   interpreted as described in BCP 14, RFC 2119 [1].
+
+
+
+
+
+Kolkman, et al.              Standard Track                     [Page 3]
+
+RFC 3757                   DNSKEY RR SEP Flag                 April 2004
+
+
+2.  The Secure Entry Point (SEP) Flag
+
+                        1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |              flags          |S|   protocol    |   algorithm   |
+   |                             |E|               |               |
+   |                             |P|               |               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                                                               /
+   /                        public key                             /
+   /                                                               /
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                          DNSKEY RR Format
+   This document assigns the 15th bit in the flags field as the secure
+   entry point (SEP) bit.  If the bit is set to 1 the key is intended to
+   be used as secure entry point key.  One SHOULD NOT assign special
+   meaning to the key if the bit is set to 0.  Operators can recognize
+   the secure entry point key by the even or odd-ness of the decimal
+   representation of the flag field.
+
+3.  DNSSEC Protocol Changes
+
+   The bit MUST NOT be used during the resolving and verification
+   process.  The SEP flag is only used to provide a hint about the
+   different administrative properties of the key and therefore the use
+   of the SEP flag does not change the DNS resolution protocol or the
+   resolution process.
+
+4.  Operational Guidelines
+
+   The SEP bit is set by the key-pair-generator and MAY be used by the
+   zone signer to decide whether the public part of the key pair is to
+   be prepared for input to a DS RR generation function.  The SEP bit is
+   recommended to be set (to 1) whenever the public key of the key pair
+   will be distributed to the parent zone to build the authentication
+   chain or if the public key is to be distributed for static
+   configuration in verifiers.
+
+   When a key pair is created, the operator needs to indicate whether
+   the SEP bit is to be set in the DNSKEY RR.  As the SEP bit is within
+   the data that is used to compute the 'key tag field' in the SIG RR,
+   changing the SEP bit will change the identity of the key within DNS.
+   In other words, once a key is used to generate signatures, the
+   setting of the SEP bit is to remain constant.  If not, a verifier
+   will not be able to find the relevant KEY RR.
+
+
+
+
+Kolkman, et al.              Standard Track                     [Page 4]
+
+RFC 3757                   DNSKEY RR SEP Flag                 April 2004
+
+
+   When signing a zone, it is intended that the key(s) with the SEP bit
+   set (if such keys exist) are used to sign the KEY RR set of the zone.
+   The same key can be used to sign the rest of the zone data too.  It
+   is conceivable that not all keys with a SEP bit set will sign the
+   DNSKEY RR set, such keys might be pending retirement or not yet in
+   use.
+
+   When verifying a RR set, the SEP bit is not intended to play a role.
+   How the key is used by the verifier is not intended to be a
+   consideration at key creation time.
+
+   Although the SEP flag provides a hint on which public key is to be
+   used as trusted root, administrators can choose to ignore the fact
+   that a DNSKEY has its SEP bit set or not when configuring a trusted
+   root for their resolvers.
+
+   Using the SEP flag a key roll over can be automated.  The parent can
+   use an existing trust relation to verify DNSKEY RR sets in which a
+   new DNSKEY RR with the SEP flag appears.
+
+5.  Security Considerations
+
+   As stated in Section 3 the flag is not to be used in the resolution
+   protocol or to determine the security status of a key.  The flag is
+   to be used for administrative purposes only.
+
+   No trust in a key should be inferred from this flag - trust MUST be
+   inferred from an existing chain of trust or an out-of-band exchange.
+
+   Since this flag might be used for automating public key exchanges, we
+   think the following consideration is in place.
+
+   Automated mechanisms for roll over of the DS RR might be vulnerable
+   to a class of replay attacks.  This might happen after a public key
+   exchange where a DNSKEY RR set, containing two DNSKEY RRs with the
+   SEP flag set, is sent to the parent.  The parent verifies the DNSKEY
+   RR set with the existing trust relation and creates the new DS RR
+   from the DNSKEY RR that the current DS RR is not pointing to.  This
+   key exchange might be replayed.  Parents are encouraged to implement
+   a replay defense.  A simple defense can be based on a registry of
+   keys that have been used to generate DS RRs during the most recent
+   roll over.  These same considerations apply to entities that
+   configure keys in resolvers.
+
+
+
+
+
+
+
+
+Kolkman, et al.              Standard Track                     [Page 5]
+
+RFC 3757                   DNSKEY RR SEP Flag                 April 2004
+
+
+6.  IANA Considerations
+
+   IANA has assigned the 15th bit in the DNSKEY Flags Registry (see
+   Section 4.3 of [4]) as the Secure Entry Point (SEP) bit.
+
+7.  Internationalization Considerations
+
+   Although SEP is a popular acronym in many different languages, there
+   are no internationalization considerations.
+
+8.  Acknowledgments
+
+   The ideas documented in this document are inspired by communications
+   we had with numerous people and ideas published by other folk.  Among
+   others Mark Andrews, Rob Austein, Miek Gieben, Olafur Gudmundsson,
+   Daniel Karrenberg, Dan Massey, Scott Rose, Marcos Sanz and Sam Weiler
+   have contributed ideas and provided feedback.
+
+   This document saw the light during a workshop on DNSSEC operations
+   hosted by USC/ISI in August 2002.
+
+9.  References
+
+9.1.  Normative References
+
+   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", BCP 14, RFC 2119, March 1997.
+
+   [2]  Eastlake, D., "Domain Name System Security Extensions", RFC
+        2535, March 1999.
+
+   [3]  Lewis, E., "DNS Security Extension Clarification on Zone
+        Status", RFC 3090, March 2001.
+
+   [4]  Weiler, S., "Legacy Resolver Compatibility for Delegation Signer
+        (DS)", RFC 3755, April 2004.
+
+9.2.  Informative References
+
+   [5]  Gudmundsson, O., "Delegation Signer (DS) Resource Record (RR)",
+        RFC 3658, December 2003.
+
+   [6]  Orwell, G. and R. Steadman (illustrator), "Animal Farm; a Fairy
+        Story", ISBN 0151002177 (50th anniversary edition), April 1996.
+
+
+
+
+
+
+
+Kolkman, et al.              Standard Track                     [Page 6]
+
+RFC 3757                   DNSKEY RR SEP Flag                 April 2004
+
+
+10.  Authors' Addresses
+
+   Olaf M. Kolkman
+   RIPE NCC
+   Singel 256
+   Amsterdam  1016 AB
+   NL
+
+   Phone: +31 20 535 4444
+   EMail: olaf@ripe.net
+   URI:   http://www.ripe.net/
+
+
+   Jakob Schlyter
+   NIC-SE
+   Box 5774
+   SE-114 87 Stockholm
+   Sweden
+
+   EMail: jakob@nic.se
+   URI:   http://www.nic.se/
+
+
+   Edward P. Lewis
+   ARIN
+   3635 Concorde Parkway Suite 200
+   Chantilly, VA  20151
+   US
+
+   Phone: +1 703 227 9854
+   EMail: edlewis@arin.net
+   URI:   http://www.arin.net/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kolkman, et al.              Standard Track                     [Page 7]
+
+RFC 3757                   DNSKEY RR SEP Flag                 April 2004
+
+
+11.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2004).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78 and
+   except as set forth therein, the authors retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
+   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
+   INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
+   IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
+   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed
+   to pertain to the implementation or use of the technology
+   described in this document or the extent to which any license
+   under such rights might or might not be available; nor does it
+   represent that it has made any independent effort to identify any
+   such rights.  Information on the procedures with respect to
+   rights in RFC documents can be found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use
+   of such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository
+   at http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention
+   any copyrights, patents or patent applications, or other
+   proprietary rights that may cover technology that may be required
+   to implement this standard.  Please address the information to the
+   IETF at ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+Kolkman, et al.              Standard Track                     [Page 8]
+
diff --git a/doc/rfc/rfc3833.txt b/doc/rfc/rfc3833.txt
new file mode 100644
index 0000000..8ce4d34
--- /dev/null
+++ b/doc/rfc/rfc3833.txt
@@ -0,0 +1,899 @@
+
+
+
+
+
+
+Network Working Group                                          D. Atkins
+Request for Comments: 3833                              IHTFP Consulting
+Category: Informational                                       R. Austein
+                                                                     ISC
+                                                             August 2004
+
+
+            Threat Analysis of the Domain Name System (DNS)
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2004).
+
+Abstract
+
+   Although the DNS Security Extensions (DNSSEC) have been under
+   development for most of the last decade, the IETF has never written
+   down the specific set of threats against which DNSSEC is designed to
+   protect.  Among other drawbacks, this cart-before-the-horse situation
+   has made it difficult to determine whether DNSSEC meets its design
+   goals, since its design goals are not well specified.  This note
+   attempts to document some of the known threats to the DNS, and, in
+   doing so, attempts to measure to what extent (if any) DNSSEC is a
+   useful tool in defending against these threats.
+
+1. Introduction
+
+   The earliest organized work on DNSSEC within the IETF was an open
+   design team meeting organized by members of the DNS working group in
+   November 1993 at the 28th IETF meeting in Houston.  The broad
+   outlines of DNSSEC as we know it today are already clear in Jim
+   Galvin's summary of the results of that meeting [Galvin93]:
+
+   - While some participants in the meeting were interested in
+     protecting against disclosure of DNS data to unauthorized parties,
+     the design team made an explicit decision that "DNS data is
+     `public'", and ruled all threats of data disclosure explicitly out
+     of scope for DNSSEC.
+
+   - While some participants in the meeting were interested in
+     authentication of DNS clients and servers as a basis for access
+     control, this work was also ruled out of scope for DNSSEC per se.
+
+
+
+Atkins & Austein             Informational                      [Page 1]
+
+RFC 3833                  DNS Threat Analysis                August 2004
+
+
+   - Backwards compatibility and co-existence with "insecure DNS" was
+     listed as an explicit requirement.
+
+   - The resulting list of desired security services was
+     1) data integrity, and
+     2) data origin authentication.
+
+   - The design team noted that a digital signature mechanism would
+     support the desired services.
+
+   While a number of detail decisions were yet to be made (and in some
+   cases remade after implementation experience) over the subsequent
+   decade, the basic model and design goals have remained fixed.
+
+   Nowhere, however, does any of the DNSSEC work attempt to specify in
+   any detail the sorts of attacks against which DNSSEC is intended to
+   protect, or the reasons behind the list of desired security services
+   that came out of the Houston meeting.  For that, we have to go back
+   to a paper originally written by Steve Bellovin in 1990 but not
+   published until 1995, for reasons that Bellovin explained in the
+   paper's epilogue [Bellovin95].
+
+   While it may seem a bit strange to publish the threat analysis a
+   decade after starting work on the protocol designed to defend against
+   it, that is, nevertheless, what this note attempts to do.  Better
+   late than never.
+
+   This note assumes that the reader is familiar with both the DNS and
+   with DNSSEC, and does not attempt to provide a tutorial on either.
+   The DNS documents most relevant to the subject of this note are:
+   [RFC1034], [RFC1035], section 6.1 of [RFC1123], [RFC2181], [RFC2308],
+   [RFC2671], [RFC2845], [RFC2930], [RFC3007], and [RFC2535].
+
+   For purposes of discussion, this note uses the term "DNSSEC" to refer
+   to the core hierarchical public key and signature mechanism specified
+   in the DNSSEC documents, and refers to TKEY and TSIG as separate
+   mechanisms, even though channel security mechanisms such as TKEY and
+   TSIG are also part of the larger problem of "securing DNS" and thus
+   are often considered part of the overall set of "DNS security
+   extensions".  This is an arbitrary distinction that in part reflects
+   the way in which the protocol has evolved (introduction of a
+   putatively simpler channel security model for certain operations such
+   as zone transfers and dynamic update requests), and perhaps should be
+   changed in a future revision of this note.
+
+
+
+
+
+
+
+Atkins & Austein             Informational                      [Page 2]
+
+RFC 3833                  DNS Threat Analysis                August 2004
+
+
+2.  Known Threats
+
+   There are several distinct classes of threats to the DNS, most of
+   which are DNS-related instances of more general problems, but a few
+   of which are specific to peculiarities of the DNS protocol.
+
+2.1.  Packet Interception
+
+   Some of the simplest threats against DNS are various forms of packet
+   interception: monkey-in-the-middle attacks, eavesdropping on requests
+   combined with spoofed responses that beat the real response back to
+   the resolver, and so forth.  In any of these scenarios, the attacker
+   can simply tell either party (usually the resolver) whatever it wants
+   that party to believe.  While packet interception attacks are far
+   from unique to DNS, DNS's usual behavior of sending an entire query
+   or response in a single unsigned, unencrypted UDP packet makes these
+   attacks particularly easy for any bad guy with the ability to
+   intercept packets on a shared or transit network.
+
+   To further complicate things, the DNS query the attacker intercepts
+   may just be a means to an end for the attacker: the attacker might
+   even choose to return the correct result in the answer section of a
+   reply message while using other parts of the message to set the stage
+   for something more complicated, for example, a name chaining attack
+   (see section 2.3).
+
+   While it certainly would be possible to sign DNS messages using a
+   channel security mechanism such as TSIG or IPsec, or even to encrypt
+   them using IPsec, this would not be a very good solution for
+   interception attacks.  First, this approach would impose a fairly
+   high processing cost per DNS message, as well as a very high cost
+   associated with establishing and maintaining bilateral trust
+   relationships between all the parties that might be involved in
+   resolving any particular query.  For heavily used name servers (such
+   as the servers for the root zone), this cost would almost certainly
+   be prohibitively high.  Even more important, however, is that the
+   underlying trust model in such a design would be wrong, since at best
+   it would only provide a hop-by-hop integrity check on DNS messages
+   and would not provide any sort of end-to-end integrity check between
+   the producer of DNS data (the zone administrator) and the consumer of
+   DNS data (the application that triggered the query).
+
+   By contrast, DNSSEC (when used properly) does provide an end-to-end
+   data integrity check, and is thus a much better solution for this
+   class of problems during basic DNS lookup operations.
+
+
+
+
+
+
+Atkins & Austein             Informational                      [Page 3]
+
+RFC 3833                  DNS Threat Analysis                August 2004
+
+
+   TSIG does have its place in corners of the DNS protocol where there's
+   a specific trust relationship between a particular client and a
+   particular server, such as zone transfer, dynamic update, or a
+   resolver (stub or otherwise) that is not going to check all the
+   DNSSEC signatures itself.
+
+   Note that DNSSEC does not provide any protection against modification
+   of the DNS message header, so any properly paranoid resolver must:
+
+   - Perform all of the DNSSEC signature checking on its own,
+
+   - Use TSIG (or some equivalent mechanism) to ensure the integrity of
+     its communication with whatever name servers it chooses to trust,
+     or
+
+   - Resign itself to the possibility of being attacked via packet
+     interception (and via other techniques discussed below).
+
+2.2.  ID Guessing and Query Prediction
+
+   Since DNS is for the most part used over UDP/IP, it is relatively
+   easy for an attacker to generate packets which will match the
+   transport protocol parameters.  The ID field in the DNS header is
+   only a 16-bit field and the server UDP port associated with DNS is a
+   well-known value, so there are only 2**32 possible combinations of ID
+   and client UDP port for a given client and server.  This is not a
+   particularly large range, and is not sufficient to protect against a
+   brute force search; furthermore, in practice both the client UDP port
+   and the ID can often be predicted from previous traffic, and it is
+   not uncommon for the client port to be a known fixed value as well
+   (due to firewalls or other restrictions), thus frequently reducing
+   the search space to a range smaller than 2**16.
+
+   By itself, ID guessing is not enough to allow an attacker to inject
+   bogus data, but combined with knowledge (or guesses) about QNAMEs and
+   QTYPEs for which a resolver might be querying, this leaves the
+   resolver only weakly defended against injection of bogus responses.
+
+   Since this attack relies on predicting a resolver's behavior, it's
+   most likely to be successful when the victim is in a known state,
+   whether because the victim rebooted recently, or because the victim's
+   behavior has been influenced by some other action by the attacker, or
+   because the victim is responding (in a predictable way) to some third
+   party action known to the attacker.
+
+
+
+
+
+
+
+Atkins & Austein             Informational                      [Page 4]
+
+RFC 3833                  DNS Threat Analysis                August 2004
+
+
+   This attack is both more and less difficult for the attacker than the
+   simple interception attack described above: more difficult, because
+   the attack only works when the attacker guesses correctly; less
+   difficult, because the attacker doesn't need to be on a transit or
+   shared network.
+
+   In most other respects, this attack is similar to a packet
+   interception attack.  A resolver that checks DNSSEC signatures will
+   be able to detect the forged response; resolvers that do not perform
+   DNSSEC signature checking themselves should use TSIG or some
+   equivalent mechanism to ensure the integrity of their communication
+   with a recursive name server that does perform DNSSEC signature
+   checking.
+
+2.3.  Name Chaining
+
+   Perhaps the most interesting class of DNS-specific threats are the
+   name chaining attacks.  These are a subset of a larger class of
+   name-based attacks, sometimes called "cache poisoning" attacks.  Most
+   name-based attacks can be partially mitigated by the long-standing
+   defense of checking RRs in response messages for relevance to the
+   original query, but such defenses do not catch name chaining attacks.
+   There are several variations on the basic attack, but what they all
+   have in common is that they all involve DNS RRs whose RDATA portion
+   (right hand side) includes a DNS name (or, in a few cases, something
+   that is not a DNS name but which directly maps to a DNS name).  Any
+   such RR is, at least in principle, a hook that lets an attacker feed
+   bad data into a victim's cache, thus potentially subverting
+   subsequent decisions based on DNS names.
+
+   The worst examples in this class of RRs are CNAME, NS, and DNAME RRs
+   because they can redirect a victim's query to a location of the
+   attacker's choosing.  RRs like MX and SRV are somewhat less
+   dangerous, but in principle they can also be used to trigger further
+   lookups at a location of the attacker's choosing.  Address RR types
+   such as A or AAAA don't have DNS names in their RDATA, but since the
+   IN-ADDR.ARPA and IP6.ARPA trees are indexed using a DNS encoding of
+   IPv4 and IPv6 addresses, these record types can also be used in a
+   name chaining attack.
+
+   The general form of a name chaining attack is something like this:
+
+   - Victim issues a query, perhaps at the instigation of the attacker
+     or some third party; in some cases the query itself may be
+     unrelated to the name under attack (that is, the attacker is just
+     using this query as a means to inject false information about some
+     other name).
+
+
+
+
+Atkins & Austein             Informational                      [Page 5]
+
+RFC 3833                  DNS Threat Analysis                August 2004
+
+
+   - Attacker injects response, whether via packet interception, query
+     guessing, or by being a legitimate name server that's involved at
+     some point in the process of answering the query that the victim
+     issued.
+
+   - Attacker's response includes one or more RRs with DNS names in
+     their RDATA; depending on which particular form this attack takes,
+     the object may be to inject false data associated with those names
+     into the victim's cache via the Additional section of this
+     response, or may be to redirect the next stage of the query to a
+     server of the attacker's choosing (in order to inject more complex
+     lies into the victim's cache than will fit easily into a single
+     response, or in order to place the lies in the Authority or Answer
+     section of a response where they will have a better chance of
+     sneaking past a resolver's defenses).
+
+   Any attacker who can insert resource records into a victim's cache
+   can almost certainly do some kind of damage, so there are cache
+   poisoning attacks which are not name chaining attacks in the sense
+   discussed here.  However, in the case of name chaining attacks, the
+   cause and effect relationship between the initial attack and the
+   eventual result may be significantly more complex than in the other
+   forms of cache poisoning, so name chaining attacks merit special
+   attention.
+
+   The common thread in all of the name chaining attacks is that
+   response messages allow the attacker to introduce arbitrary DNS names
+   of the attacker's choosing and provide further information that the
+   attacker claims is associated with those names; unless the victim has
+   better knowledge of the data associated with those names, the victim
+   is going to have a hard time defending against this class of attacks.
+
+   This class of attack is particularly insidious given that it's quite
+   easy for an attacker to provoke a victim into querying for a
+   particular name of the attacker's choosing, for example, by embedding
+   a link to a 1x1-pixel "web bug" graphic in a piece of Text/HTML mail
+   to the victim.  If the victim's mail reading program attempts to
+   follow such a link, the result will be a DNS query for a name chosen
+   by the attacker.
+
+   DNSSEC should provide a good defense against most (all?) variations
+   on this class of attack.  By checking signatures, a resolver can
+   determine whether the data associated with a name really was inserted
+   by the delegated authority for that portion of the DNS name space.
+   More precisely, a resolver can determine whether the entity that
+   injected the data had access to an allegedly secret key whose
+
+
+
+
+
+Atkins & Austein             Informational                      [Page 6]
+
+RFC 3833                  DNS Threat Analysis                August 2004
+
+
+   corresponding public key appears at an expected location in the DNS
+   name space with an expected chain of parental signatures that start
+   with a public key of which the resolver has prior knowledge.
+
+   DNSSEC signatures do not cover glue records, so there's still a
+   possibility of a name chaining attack involving glue, but with DNSSEC
+   it is possible to detect the attack by temporarily accepting the glue
+   in order to fetch the signed authoritative version of the same data,
+   then checking the signatures on the authoritative version.
+
+2.4.  Betrayal By Trusted Server
+
+   Another variation on the packet interception attack is the trusted
+   server that turns out not to be so trustworthy, whether by accident
+   or by intent.  Many client machines are only configured with stub
+   resolvers, and use trusted servers to perform all of their DNS
+   queries on their behalf.  In many cases the trusted server is
+   furnished by the user's ISP and advertised to the client via DHCP or
+   PPP options.  Besides accidental betrayal of this trust relationship
+   (via server bugs, successful server break-ins, etc), the server
+   itself may be configured to give back answers that are not what the
+   user would expect, whether in an honest attempt to help the user or
+   to promote some other goal such as furthering a business partnership
+   between the ISP and some third party.
+
+   This problem is particularly acute for frequent travelers who carry
+   their own equipment and expect it to work in much the same way
+   wherever they go.  Such travelers need trustworthy DNS service
+   without regard to who operates the network into which their equipment
+   is currently plugged or what brand of middle boxes the local
+   infrastructure might use.
+
+   While the obvious solution to this problem would be for the client to
+   choose a more trustworthy server, in practice this may not be an
+   option for the client.  In many network environments a client machine
+   has only a limited set of recursive name servers from which to
+   choose, and none of them may be particularly trustworthy.  In extreme
+   cases, port filtering or other forms of packet interception may
+   prevent the client host from being able to run an iterative resolver
+   even if the owner of the client machine is willing and able to do so.
+   Thus, while the initial source of this problem is not a DNS protocol
+   attack per se, this sort of betrayal is a threat to DNS clients, and
+   simply switching to a different recursive name server is not an
+   adequate defense.
+
+   Viewed strictly from the DNS protocol standpoint, the only difference
+   between this sort of betrayal and a packet interception attack is
+   that in this case the client has voluntarily sent its request to the
+
+
+
+Atkins & Austein             Informational                      [Page 7]
+
+RFC 3833                  DNS Threat Analysis                August 2004
+
+
+   attacker.  The defense against this is the same as with a packet
+   interception attack: the resolver must either check DNSSEC signatures
+   itself or use TSIG (or equivalent) to authenticate the server that it
+   has chosen to trust.  Note that use of TSIG does not by itself
+   guarantee that a name server is at all trustworthy: all TSIG can do
+   is help a resolver protect its communication with a name server that
+   it has already decided to trust for other reasons.  Protecting a
+   resolver's communication with a server that's giving out bogus
+   answers is not particularly useful.
+
+   Also note that if the stub resolver does not trust the name server
+   that is doing work on its behalf and wants to check the DNSSEC
+   signatures itself, the resolver really does need to have independent
+   knowledge of the DNSSEC public key(s) it needs in order to perform
+   the check.  Usually the public key for the root zone is enough, but
+   in some cases knowledge of additional keys may also be appropriate.
+
+   It is difficult to escape the conclusion that a properly paranoid
+   resolver must always perform its own signature checking, and that
+   this rule even applies to stub resolvers.
+
+2.5.  Denial of Service
+
+   As with any network service (or, indeed, almost any service of any
+   kind in any domain of discourse), DNS is vulnerable to denial of
+   service attacks.  DNSSEC does not help this, and may in fact make the
+   problem worse for resolvers that check signatures, since checking
+   signatures both increases the processing cost per DNS message and in
+   some cases can also increase the number of messages needed to answer
+   a query.  TSIG (and similar mechanisms) have equivalent problems.
+
+   DNS servers are also at risk of being used as denial of service
+   amplifiers, since DNS response packets tend to be significantly
+   longer than DNS query packets.  Unsurprisingly, DNSSEC doesn't help
+   here either.
+
+2.6.  Authenticated Denial of Domain Names
+
+   Much discussion has taken place over the question of authenticated
+   denial of domain names.  The particular question is whether there is
+   a requirement for authenticating the non-existence of a name.  The
+   issue is whether the resolver should be able to detect when an
+   attacker removes RRs from a response.
+
+   General paranoia aside, the existence of RR types whose absence
+   causes an action other than immediate failure (such as missing MX and
+   SRV RRs, which fail over to A RRs) constitutes a real threat.
+   Arguably, in some cases, even the absence of an RR might be
+
+
+
+Atkins & Austein             Informational                      [Page 8]
+
+RFC 3833                  DNS Threat Analysis                August 2004
+
+
+   considered a problem.  The question remains: how serious is this
+   threat?  Clearly the threat does exist; general paranoia says that
+   some day it'll be on the front page of some major newspaper, even if
+   we cannot conceive of a plausible scenario involving this attack
+   today.  This implies that some mitigation of this risk is required.
+
+   Note that it's necessary to prove the non-existence of applicable
+   wildcard RRs as part of the authenticated denial mechanism, and that,
+   in a zone that is more than one label deep, such a proof may require
+   proving the non-existence of multiple discrete sets of wildcard RRs.
+
+   DNSSEC does include mechanisms which make it possible to determine
+   which authoritative names exist in a zone, and which authoritative
+   resource record types exist at those names.  The DNSSEC protections
+   do not cover non-authoritative data such as glue records.
+
+2.7.  Wildcards
+
+   Much discussion has taken place over whether and how to provide data
+   integrity and data origin authentication for "wildcard" DNS names.
+   Conceptually, RRs with wildcard names are patterns for synthesizing
+   RRs on the fly according to the matching rules described in section
+   4.3.2 of RFC 1034.  While the rules that control the behavior of
+   wildcard names have a few quirks that can make them a trap for the
+   unwary zone administrator, it's clear that a number of sites make
+   heavy use of wildcard RRs, particularly wildcard MX RRs.
+
+   In order to provide the desired services for wildcard RRs, we need to
+   do two things:
+
+   - We need a way to attest to the existence of the wildcard RR itself
+     (that is, we need to show that the synthesis rule exists), and
+
+   - We need a way to attest to the non-existence of any RRs which, if
+     they existed, would make the wildcard RR irrelevant according to
+     the synthesis rules that govern the way in which wildcard RRs are
+     used (that is, we need to show that the synthesis rule is
+     applicable).
+
+   Note that this makes the wildcard mechanisms dependent upon the
+   authenticated denial mechanism described in the previous section.
+
+   DNSSEC includes mechanisms along the lines described above, which
+   make it possible for a resolver to verify that a name server applied
+   the wildcard expansion rules correctly when generating an answer.
+
+
+
+
+
+
+Atkins & Austein             Informational                      [Page 9]
+
+RFC 3833                  DNS Threat Analysis                August 2004
+
+
+3.  Weaknesses of DNSSEC
+
+   DNSSEC has some problems of its own:
+
+   - DNSSEC is complex to implement and includes some nasty edge cases
+     at the zone cuts that require very careful coding.  Testbed
+     experience to date suggests that trivial zone configuration errors
+     or expired keys can cause serious problems for a DNSSEC-aware
+     resolver, and that the current protocol's error reporting
+     capabilities may leave something to be desired.
+
+   - DNSSEC significantly increases the size of DNS response packets;
+     among other issues, this makes DNSSEC-aware DNS servers even more
+     effective as denial of service amplifiers.
+
+   - DNSSEC answer validation increases the resolver's work load, since
+     a DNSSEC-aware resolver will need to perform signature validation
+     and in some cases will also need to issue further queries.  This
+     increased workload will also increase the time it takes to get an
+     answer back to the original DNS client, which is likely to trigger
+     both timeouts and re-queries in some cases.  Arguably, many current
+     DNS clients are already too impatient even before taking the
+     further delays that DNSSEC will impose into account, but that topic
+     is beyond the scope of this note.
+
+   - Like DNS itself, DNSSEC's trust model is almost totally
+     hierarchical.  While DNSSEC does allow resolvers to have special
+     additional knowledge of public keys beyond those for the root, in
+     the general case the root key is the one that matters.  Thus any
+     compromise in any of the zones between the root and a particular
+     target name can damage DNSSEC's ability to protect the integrity of
+     data owned by that target name.  This is not a change, since
+     insecure DNS has the same model.
+
+   - Key rollover at the root is really hard.  Work to date has not even
+     come close to adequately specifying how the root key rolls over, or
+     even how it's configured in the first place.
+
+   - DNSSEC creates a requirement of loose time synchronization between
+     the validating resolver and the entity creating the DNSSEC
+     signatures.  Prior to DNSSEC, all time-related actions in DNS could
+     be performed by a machine that only knew about "elapsed" or
+     "relative" time.  Because the validity period of a DNSSEC signature
+     is based on "absolute" time, a validating resolver must have the
+     same concept of absolute time as the zone signer in order to
+     determine whether the signature is within its validity period or
+     has expired.  An attacker that can change a resolver's opinion of
+     the current absolute time can fool the resolver using expired
+
+
+
+Atkins & Austein             Informational                     [Page 10]
+
+RFC 3833                  DNS Threat Analysis                August 2004
+
+
+     signatures.  An attacker that can change the zone signer's opinion
+     of the current absolute time can fool the zone signer into
+     generating signatures whose validity period does not match what the
+     signer intended.
+
+   - The possible existence of wildcard RRs in a zone complicates the
+     authenticated denial mechanism considerably.  For most of the
+     decade that DNSSEC has been under development these issues were
+     poorly understood.  At various times there have been questions as
+     to whether the authenticated denial mechanism is completely
+     airtight and whether it would be worthwhile to optimize the
+     authenticated denial mechanism for the common case in which
+     wildcards are not present in a zone.  However, the main problem is
+     just the inherent complexity of the wildcard mechanism itself.
+     This complexity probably makes the code for generating and checking
+     authenticated denial attestations somewhat fragile, but since the
+     alternative of giving up wildcards entirely is not practical due to
+     widespread use, we are going to have to live with wildcards. The
+     question just becomes one of whether or not the proposed
+     optimizations would make DNSSEC's mechanisms more or less fragile.
+
+   - Even with DNSSEC, the class of attacks discussed in section 2.4 is
+     not easy to defeat.  In order for DNSSEC to be effective in this
+     case, it must be possible to configure the resolver to expect
+     certain categories of DNS records to be signed.  This may require
+     manual configuration of the resolver, especially during the initial
+     DNSSEC rollout period when the resolver cannot reasonably expect
+     the root and TLD zones to be signed.
+
+4.  Topics for Future Work
+
+   This section lists a few subjects not covered above which probably
+   need additional study, additional mechanisms, or both.
+
+4.1.  Interactions With Other Protocols
+
+   The above discussion has concentrated exclusively on attacks within
+   the boundaries of the DNS protocol itself, since those are (some of)
+   the problems against which DNSSEC was intended to protect.  There
+   are, however, other potential problems at the boundaries where DNS
+   interacts with other protocols.
+
+4.2.  Securing DNS Dynamic Update
+
+   DNS dynamic update opens a number of potential problems when combined
+   with DNSSEC.  Dynamic update of a non-secure zone can use TSIG to
+   authenticate the updating client to the server.  While TSIG does not
+   scale very well (it requires manual configuration of shared keys
+
+
+
+Atkins & Austein             Informational                     [Page 11]
+
+RFC 3833                  DNS Threat Analysis                August 2004
+
+
+   between the DNS name server and each TSIG client), it works well in a
+   limited or closed environment such as a DHCP server updating a local
+   DNS name server.
+
+   Major issues arise when trying to use dynamic update on a secure
+   zone.  TSIG can similarly be used in a limited fashion to
+   authenticate the client to the server, but TSIG only protects DNS
+   transactions, not the actual data, and the TSIG is not inserted into
+   the DNS zone, so resolvers cannot use the TSIG as a way of verifying
+   the changes to the zone.  This means that either:
+
+   a) The updating client must have access to a zone-signing key in
+      order to sign the update before sending it to the server, or
+
+   b) The DNS name server must have access to an online zone-signing key
+      in order to sign the update.
+
+   In either case, a zone-signing key must be available to create signed
+   RRsets to place in the updated zone.  The fact that this key must be
+   online (or at least available) is a potential security risk.
+
+   Dynamic update also requires an update to the SERIAL field of the
+   zone's SOA RR.  In theory, this could also be handled via either of
+   the above options, but in practice (a) would almost certainly be
+   extremely fragile, so (b) is the only workable mechanism.
+
+   There are other threats in terms of describing the policy of who can
+   make what changes to which RRsets in the zone.  The current access
+   control scheme in Secure Dynamic Update is fairly limited.  There is
+   no way to give fine-grained access to updating DNS zone information
+   to multiple entities, each of whom may require different kinds of
+   access.  For example, Alice may need to be able to add new nodes to
+   the zone or change existing nodes, but not remove them; Bob may need
+   to be able to remove zones but not add them; Carol may need to be
+   able to add, remove, or modify nodes, but only A records.
+
+   Scaling properties of the key management problem here are a
+   particular concern that needs more study.
+
+4.3.  Securing DNS Zone Replication
+
+   As discussed in previous sections, DNSSEC per se attempts to provide
+   data integrity and data origin authentication services on top of the
+   normal DNS query protocol.  Using the terminology discussed in
+   [RFC3552], DNSSEC provides "object security" for the normal DNS query
+   protocol.  For purposes of replicating entire DNS zones, however,
+   DNSSEC does not provide object security, because zones include
+   unsigned NS RRs and glue at delegation points.  Use of TSIG to
+
+
+
+Atkins & Austein             Informational                     [Page 12]
+
+RFC 3833                  DNS Threat Analysis                August 2004
+
+
+   protect zone transfer (AXFR or IXFR) operations provides "channel
+   security", but still does not provide object security for complete
+   zones. The trust relationships involved in zone transfer are still
+   very much a hop-by-hop matter of name server operators trusting other
+   name server operators rather than an end-to-end matter of name server
+   operators trusting zone administrators.
+
+   Zone object security was not an explicit design goal of DNSSEC, so
+   failure to provide this service should not be a surprise.
+   Nevertheless, there are some zone replication scenarios for which
+   this would be a very useful additional service, so this seems like a
+   useful area for future work.  In theory it should not be difficult to
+   add zone object security as a backwards compatible enhancement to the
+   existing DNSSEC model, but the DNSEXT WG has not yet discussed either
+   the desirability of or the requirements for such an enhancement.
+
+5.  Conclusion
+
+   Based on the above analysis, the DNSSEC extensions do appear to solve
+   a set of problems that do need to be solved, and are worth deploying.
+
+Security Considerations
+
+   This entire document is about security considerations of the DNS.
+   The authors believe that deploying DNSSEC will help to address some,
+   but not all, of the known threats to the DNS.
+
+Acknowledgments
+
+   This note is based both on previous published works by others and on
+   a number of discussions both public and private over a period of many
+   years, but particular thanks go to
+
+   Jaap Akkerhuis,
+   Steve Bellovin,
+   Dan Bernstein,
+   Randy Bush,
+   Steve Crocker,
+   Olafur Gudmundsson,
+   Russ Housley,
+   Rip Loomis,
+   Allison Mankin,
+   Paul Mockapetris,
+   Thomas Narten
+   Mans Nilsson,
+   Pekka Savola,
+   Paul Vixie,
+   Xunhua Wang,
+
+
+
+Atkins & Austein             Informational                     [Page 13]
+
+RFC 3833                  DNS Threat Analysis                August 2004
+
+
+   and any other members of the DNS, DNSSEC, DNSIND, and DNSEXT working
+   groups whose names and contributions the authors have forgotten, none
+   of whom are responsible for what the authors did with their ideas.
+
+   As with any work of this nature, the authors of this note acknowledge
+   that we are standing on the toes of those who have gone before us.
+   Readers interested in this subject may also wish to read
+   [Bellovin95], [Schuba93], and [Vixie95].
+
+Normative References
+
+   [RFC1034]    Mockapetris, P., "Domain names - concepts and
+                facilities", STD 13, RFC 1034, November 1987.
+
+   [RFC1035]    Mockapetris, P., "Domain names - implementation and
+                specification", STD 13, RFC 1035, November 1987.
+
+   [RFC1123]    Braden, R., "Requirements for Internet Hosts -
+                Application and Support", STD 3, RFC 1123, October 1989.
+
+   [RFC2181]    Elz, R. and R. Bush, "Clarifications to the DNS
+                Specification", RFC 2181, July 1997.
+
+   [RFC2308]    Andrews, M., "Negative Caching of DNS Queries (DNS
+                NCACHE)", RFC 2308, March 1998.
+
+   [RFC2671]    Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
+                2671, August 1999.
+
+   [RFC2845]    Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
+                Wellington, "Secret Key Transaction Authentication for
+                DNS (TSIG)", RFC 2845, May 2000.
+
+   [RFC2930]    Eastlake 3rd, D., "Secret Key Establishment for DNS
+                (TKEY RR)", RFC 2930, September 2000.
+
+   [RFC3007]    Wellington, B., "Secure Domain Name System (DNS) Dynamic
+                Update", RFC 3007, November 2000.
+
+   [RFC2535]    Eastlake 3rd, D., "Domain Name System Security
+                Extensions", RFC 2535, March 1999.
+
+
+
+
+
+
+
+
+
+
+Atkins & Austein             Informational                     [Page 14]
+
+RFC 3833                  DNS Threat Analysis                August 2004
+
+
+Informative References
+
+   [RFC3552]    Rescorla, E. and B. Korver, "Guidelines for Writing RFC
+                Text on Security Considerations", BCP 72, RFC 3552, July
+                2003.
+
+   [Bellovin95] Bellovin, S., "Using the Domain Name System for System
+                Break-Ins", Proceedings of the Fifth Usenix Unix
+                Security Symposium, June 1995.
+
+   [Galvin93]   Design team meeting summary message posted to dns-
+                security@tis.com mailing list by Jim Galvin on 19
+                November 1993.
+
+   [Schuba93]   Schuba, C., "Addressing Weaknesses in the Domain Name
+                System Protocol", Master's thesis, Purdue University
+                Department of Computer Sciences,  August 1993.
+
+   [Vixie95]    Vixie, P, "DNS and BIND Security Issues", Proceedings of
+                the Fifth Usenix Unix Security Symposium, June 1995.
+
+Authors' Addresses
+
+   Derek Atkins
+   IHTFP Consulting, Inc.
+   6 Farragut Ave
+   Somerville, MA  02144
+   USA
+
+   EMail: derek@ihtfp.com
+
+
+   Rob Austein
+   Internet Systems Consortium
+   950 Charter Street
+   Redwood City, CA 94063
+   USA
+
+   EMail: sra@isc.org
+
+
+
+
+
+
+
+
+
+
+
+
+Atkins & Austein             Informational                     [Page 15]
+
+RFC 3833                  DNS Threat Analysis                August 2004
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2004).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at ietf-
+   ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+Atkins & Austein             Informational                     [Page 16]
+
diff --git a/doc/rfc/rfc3845.txt b/doc/rfc/rfc3845.txt
new file mode 100644
index 0000000..9887a20
--- /dev/null
+++ b/doc/rfc/rfc3845.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Network Working Group                                   J. Schlyter, Ed.
+Request for Comments: 3845                                   August 2004
+Updates: 3755, 2535
+Category: Standards Track
+
+
+          DNS Security (DNSSEC) NextSECure (NSEC) RDATA Format
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2004).
+
+Abstract
+
+   This document redefines the wire format of the "Type Bit Map" field
+   in the DNS NextSECure (NSEC) resource record RDATA format to cover
+   the full resource record (RR) type space.
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
+   2.  The NSEC Resource Record . . . . . . . . . . . . . . . . . . .  2
+       2.1.  NSEC RDATA Wire Format . . . . . . . . . . . . . . . . .  3
+             2.1.1.  The Next Domain Name Field . . . . . . . . . . .  3
+             2.1.2.  The List of Type Bit Map(s) Field  . . . . . . .  3
+             2.1.3.  Inclusion of Wildcard Names in NSEC RDATA  . . .  4
+       2.2.  The NSEC RR Presentation Format  . . . . . . . . . . . .  4
+       2.3.  NSEC RR Example  . . . . . . . . . . . . . . . . . . . .  5
+   3.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  5
+   4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  5
+   5.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  6
+       5.1.  Normative References . . . . . . . . . . . . . . . . . .  6
+       5.2.  Informative References . . . . . . . . . . . . . . . . .  6
+   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  6
+   7.  Author's Address . . . . . . . . . . . . . . . . . . . . . . .  6
+   8.  Full Copyright Statement . . . . . . . . . . . . . . . . . . .  7
+
+
+
+
+
+
+
+Schlyter, Ed.               Standards Track                     [Page 1]
+
+RFC 3845                DNSSEC NSEC RDATA Format             August 2004
+
+
+1.  Introduction
+
+   The DNS [6][7] NSEC [5] Resource Record (RR) is used for
+   authenticated proof of the non-existence of DNS owner names and
+   types.  The NSEC RR is based on the NXT RR as described in RFC 2535
+   [2], and is similar except for the name and typecode.  The RDATA
+   format for the NXT RR has the limitation in that the RDATA could only
+   carry information about the existence of the first 127 types.  RFC
+   2535 did reserve a bit to specify an extension mechanism, but the
+   mechanism was never actually defined.
+
+   In order to avoid needing to develop an extension mechanism into a
+   deployed base of DNSSEC aware servers and resolvers once the first
+   127 type codes are allocated, this document redefines the wire format
+   of the "Type Bit Map" field in the NSEC RDATA to cover the full RR
+   type space.
+
+   This document introduces a new format for the type bit map.  The
+   properties of the type bit map format are that it can cover the full
+   possible range of typecodes, that it is relatively economical in the
+   amount of space it uses for the common case of a few types with an
+   owner name, that it can represent owner names with all possible types
+   present in packets of approximately 8.5 kilobytes, and that the
+   representation is simple to implement.  Efficient searching of the
+   type bitmap for the presence of certain types is not a requirement.
+
+   For convenience and completeness, this document presents the syntax
+   and semantics for the NSEC RR based on the specification in RFC 2535
+   [2] and as updated by RFC 3755 [5], thereby not introducing changes
+   except for the syntax of the type bit map.
+
+   This document updates RFC 2535 [2] and RFC 3755 [5].
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in BCP 14, RFC 2119 [1].
+
+2.  The NSEC Resource Record
+
+   The NSEC resource record lists two separate things: the owner name of
+   the next RRset in the canonical ordering of the zone, and the set of
+   RR types present at the NSEC RR's owner name.  The complete set of
+   NSEC RRs in a zone indicate which RRsets exist in a zone, and form a
+   chain of owner names in the zone.  This information is used to
+   provide authenticated denial of existence for DNS data, as described
+   in RFC 2535 [2].
+
+   The type value for the NSEC RR is 47.
+
+
+
+Schlyter, Ed.               Standards Track                     [Page 2]
+
+RFC 3845                DNSSEC NSEC RDATA Format             August 2004
+
+
+   The NSEC RR RDATA format is class independent and defined for all
+   classes.
+
+   The NSEC RR SHOULD have the same TTL value as the SOA minimum TTL
+   field.  This is in the spirit of negative caching [8].
+
+2.1.  NSEC RDATA Wire Format
+
+   The RDATA of the NSEC RR is as shown below:
+
+                         1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
+     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    /                      Next Domain Name                         /
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    /                   List of Type Bit Map(s)                     /
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+2.1.1.  The Next Domain Name Field
+
+   The Next Domain Name field contains the owner name of the next RR in
+   the canonical ordering of the zone.  The value of the Next Domain
+   Name field in the last NSEC record in the zone is the name of the
+   zone apex (the owner name of the zone's SOA RR).
+
+   A sender MUST NOT use DNS name compression on the Next Domain Name
+   field when transmitting an NSEC RR.
+
+   Owner names of RRsets that are not authoritative for the given zone
+   (such as glue records) MUST NOT be listed in the Next Domain Name
+   unless at least one authoritative RRset exists at the same owner
+   name.
+
+2.1.2.  The List of Type Bit Map(s) Field
+
+   The RR type space is split into 256 window blocks, each representing
+   the low-order 8 bits of the 16-bit RR type space.  Each block that
+   has at least one active RR type is encoded using a single octet
+   window number (from 0 to 255), a single octet bitmap length (from 1
+   to 32) indicating the number of octets used for the window block's
+   bitmap, and up to 32 octets (256 bits) of bitmap.
+
+   Window blocks are present in the NSEC RR RDATA in increasing
+   numerical order.
+
+   "|" denotes concatenation
+
+   Type Bit Map(s) Field = ( Window Block # | Bitmap Length | Bitmap ) +
+
+
+
+Schlyter, Ed.               Standards Track                     [Page 3]
+
+RFC 3845                DNSSEC NSEC RDATA Format             August 2004
+
+
+   Each bitmap encodes the low-order 8 bits of RR types within the
+   window block, in network bit order.  The first bit is bit 0.  For
+   window block 0, bit 1 corresponds to RR type 1 (A), bit 2 corresponds
+   to RR type 2 (NS), and so forth.  For window block 1, bit 1
+   corresponds to RR type 257, and bit 2 to RR type 258.  If a bit is
+   set to 1, it indicates that an RRset of that type is present for the
+   NSEC RR's owner name.  If a bit is set to 0, it indicates that no
+   RRset of that type is present for the NSEC RR's owner name.
+
+   Since bit 0 in window block 0 refers to the non-existing RR type 0,
+   it MUST be set to 0.  After verification, the validator MUST ignore
+   the value of bit 0 in window block 0.
+
+   Bits representing Meta-TYPEs or QTYPEs, as specified in RFC 2929 [3]
+   (section 3.1), or within the range reserved for assignment only to
+   QTYPEs and Meta-TYPEs MUST be set to 0, since they do not appear in
+   zone data.  If encountered, they must be ignored upon reading.
+
+   Blocks with no types present MUST NOT be included.  Trailing zero
+   octets in the bitmap MUST be omitted.  The length of each block's
+   bitmap is determined by the type code with the largest numerical
+   value within that block, among the set of RR types present at the
+   NSEC RR's owner name.  Trailing zero octets not specified MUST be
+   interpreted as zero octets.
+
+2.1.3.  Inclusion of Wildcard Names in NSEC RDATA
+
+   If a wildcard owner name appears in a zone, the wildcard label ("*")
+   is treated as a literal symbol and is treated the same as any other
+   owner name for purposes of generating NSEC RRs.  Wildcard owner names
+   appear in the Next Domain Name field without any wildcard expansion.
+   RFC 2535 [2] describes the impact of wildcards on authenticated
+   denial of existence.
+
+2.2.  The NSEC RR Presentation Format
+
+   The presentation format of the RDATA portion is as follows:
+
+   The Next Domain Name field is represented as a domain name.
+
+   The List of Type Bit Map(s) Field is represented as a sequence of RR
+   type mnemonics.  When the mnemonic is not known, the TYPE
+   representation as described in RFC 3597 [4] (section 5) MUST be used.
+
+
+
+
+
+
+
+
+Schlyter, Ed.               Standards Track                     [Page 4]
+
+RFC 3845                DNSSEC NSEC RDATA Format             August 2004
+
+
+2.3.  NSEC RR Example
+
+   The following NSEC RR identifies the RRsets associated with
+   alfa.example.com. and the next authoritative name after
+   alfa.example.com.
+
+   alfa.example.com. 86400 IN NSEC host.example.com. A MX RRSIG NSEC
+   TYPE1234
+
+   The first four text fields specify the name, TTL, Class, and RR type
+   (NSEC).  The entry host.example.com. is the next authoritative name
+   after alfa.example.com. in canonical order.  The A, MX, RRSIG, NSEC,
+   and TYPE1234 mnemonics indicate there are A, MX, RRSIG, NSEC, and
+   TYPE1234 RRsets associated with the name alfa.example.com.
+
+   The RDATA section of the NSEC RR above would be encoded as:
+
+      0x04 'h'  'o'  's'  't'
+      0x07 'e'  'x'  'a'  'm'  'p'  'l'  'e'
+      0x03 'c'  'o'  'm'  0x00
+      0x00 0x06 0x40 0x01 0x00 0x00 0x00 0x03
+      0x04 0x1b 0x00 0x00 0x00 0x00 0x00 0x00
+      0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
+      0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
+      0x00 0x00 0x00 0x00 0x20
+
+   Assuming that the resolver can authenticate this NSEC record, it
+   could be used to prove that beta.example.com does not exist, or could
+   be used to prove that there is no AAAA record associated with
+   alfa.example.com.  Authenticated denial of existence is discussed in
+   RFC 2535 [2].
+
+3.  IANA Considerations
+
+   This document introduces no new IANA considerations, because all of
+   the protocol parameters used in this document have already been
+   assigned by RFC 3755 [5].
+
+4.  Security Considerations
+
+   The update of the RDATA format and encoding does not affect the
+   security of the use of NSEC RRs.
+
+
+
+
+
+
+
+
+
+Schlyter, Ed.               Standards Track                     [Page 5]
+
+RFC 3845                DNSSEC NSEC RDATA Format             August 2004
+
+
+5.  References
+
+5.1.  Normative References
+
+   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", BCP 14, RFC 2119, March 1997.
+
+   [2]  Eastlake 3rd, D., "Domain Name System Security Extensions", RFC
+        2535, March 1999.
+
+   [3]  Eastlake 3rd, D., Brunner-Williams, E., and B. Manning, "Domain
+        Name System (DNS) IANA Considerations", BCP 42, RFC 2929,
+        September 2000.
+
+   [4]  Gustafsson, A., "Handling of Unknown DNS Resource Record (RR)
+        Types", RFC 3597, September 2003.
+
+   [5]  Weiler, S., "Legacy Resolver Compatibility for Delegation Signer
+        (DS)", RFC 3755, May 2004.
+
+5.2.  Informative References
+
+   [6]  Mockapetris, P., "Domain names - concepts and facilities", STD
+        13, RFC 1034, November 1987.
+
+   [7]  Mockapetris, P., "Domain names - implementation and
+        specification", STD 13, RFC 1035, November 1987.
+
+   [8]  Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC
+        2308, March 1998.
+
+6.  Acknowledgements
+
+   The encoding described in this document was initially proposed by
+   Mark Andrews.  Other encodings where proposed by David Blacka and
+   Michael Graff.
+
+7.  Author's Address
+
+   Jakob Schlyter (editor)
+   NIC-SE
+   Box 5774
+   Stockholm  SE-114 87
+   Sweden
+
+   EMail: jakob@nic.se
+   URI: http://www.nic.se/
+
+
+
+
+Schlyter, Ed.               Standards Track                     [Page 6]
+
+RFC 3845                DNSSEC NSEC RDATA Format             August 2004
+
+
+8.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2004).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE
+   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
+   INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
+   IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
+   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the IETF's procedures with respect to rights in IETF Documents can
+   be found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at ietf-
+   ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+Schlyter, Ed.               Standards Track                     [Page 7]
+
diff --git a/doc/rfc/rfc3901.txt b/doc/rfc/rfc3901.txt
new file mode 100644
index 0000000..43b7356
--- /dev/null
+++ b/doc/rfc/rfc3901.txt
@@ -0,0 +1,283 @@
+
+
+
+
+
+
+Network Working Group                                          A. Durand
+Request for Comments: 3901                        SUN Microsystems, Inc.
+BCP: 91                                                         J. Ihren
+Category: Best Current Practice                               Autonomica
+                                                          September 2004
+
+
+               DNS IPv6 Transport Operational Guidelines
+
+Status of this Memo
+
+   This document specifies an Internet Best Current Practices for the
+   Internet Community, and requests discussion and suggestions for
+   improvements.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2004).
+
+Abstract
+
+   This memo provides guidelines and Best Current Practice for operating
+   DNS in a world where queries and responses are carried in a mixed
+   environment of IPv4 and IPv6 networks.
+
+1.  Introduction to the Problem of Name Space Fragmentation:
+    following the referral chain
+
+   A resolver that tries to look up a name starts out at the root, and
+   follows referrals until it is referred to a name server that is
+   authoritative for the name.  If somewhere down the chain of referrals
+   it is referred to a name server that is only accessible over a
+   transport which the resolver cannot use, the resolver is unable to
+   finish the task.
+
+   When the Internet moves from IPv4 to a mixture of IPv4 and IPv6 it is
+   only a matter of time until this starts to happen.  The complete DNS
+   hierarchy then starts to fragment into a graph where authoritative
+   name servers for certain nodes are only accessible over a certain
+   transport.  The concern is that a resolver using only a particular
+   version of IP and querying information about another node using the
+   same version of IP can not do it because somewhere in the chain of
+   servers accessed during the resolution process, one or more of them
+   will only be accessible with the other version of IP.
+
+   With all DNS data only available over IPv4 transport everything is
+   simple.  IPv4 resolvers can use the intended mechanism of following
+   referrals from the root and down while IPv6 resolvers have to work
+
+
+
+Durand & Ihren           Best Current Practice                  [Page 1]
+
+RFC 3901             DNS IPv6 Transport Guidelines        September 2004
+
+
+   through a "translator", i.e., they have to use a recursive name
+   server on a so-called "dual stack" host as a "forwarder" since they
+   cannot access the DNS data directly.
+
+   With all DNS data only available over IPv6 transport everything would
+   be equally simple, with the exception of IPv4 recursive name servers
+   having to switch to a forwarding configuration.
+
+   However, the second situation will not arise in the foreseeable
+   future.  Instead, the transition will be from IPv4 only to a mixture
+   of IPv4 and IPv6, with three categories of DNS data depending on
+   whether the information is available only over IPv4 transport, only
+   over IPv6 or both.
+
+   Having DNS data available on both transports is the best situation.
+   The major question is how to ensure that it becomes the norm as
+   quickly as possible.  However, while it is obvious that some DNS data
+   will only be available over v4 transport for a long time it is also
+   obvious that it is important to avoid fragmenting the name space
+   available to IPv4 only hosts.  For example, during transition it is
+   not acceptable to break the name space that we presently have
+   available for IPv4-only hosts.
+
+2.  Terminology
+
+   The phrase "IPv4 name server" indicates a name server available over
+   IPv4 transport.  It does not imply anything about what DNS [1,2] data
+   is served.  Likewise, "IPv6 [4,5,6] name server" indicates a name
+   server available over IPv6 transport.  The phrase "dual-stack name
+   server" indicates a name server that is actually configured to run
+   both protocols, IPv4 and IPv6, and not merely a server running on a
+   system capable of running both but actually configured to run only
+   one.
+
+3.  Policy Based Avoidance of Name Space Fragmentation
+
+   Today there are only a few DNS "zones" on the public Internet that
+   are available over IPv6 transport, and most of them can be regarded
+   as "experimental".  However, as soon as the root and top level
+   domains are available over IPv6 transport, it is reasonable to expect
+   that it will become more common to have zones served by IPv6 servers.
+
+   Having those zones served only by IPv6-only name server would not be
+   a good development, since this will fragment the previously
+   unfragmented IPv4 name space and there are strong reasons to find a
+   mechanism to avoid it.
+
+
+
+
+
+Durand & Ihren           Best Current Practice                  [Page 2]
+
+RFC 3901             DNS IPv6 Transport Guidelines        September 2004
+
+
+   The recommended approach to maintain name space continuity is to use
+   administrative policies, as described in the next section.
+
+4.  DNS IPv6 Transport recommended Guidelines
+
+   In order to preserve name space continuity, the following
+   administrative policies are recommended:
+
+      - every recursive name server SHOULD be either IPv4-only or dual
+        stack,
+
+         This rules out IPv6-only recursive servers.  However, one might
+         design configurations where a chain of IPv6-only name server
+         forward queries to a set of dual stack recursive name server
+         actually performing those recursive queries.
+
+      - every DNS zone SHOULD be served by at least one IPv4-reachable
+        authoritative name server.
+
+         This rules out DNS zones served only by IPv6-only authoritative
+         name servers.
+
+   Note: zone validation processes SHOULD ensure that there is at least
+   one IPv4 address record available for the name servers of any child
+   delegations within the zone.
+
+5.  Security Considerations
+
+   The guidelines described in this memo introduce no new security
+   considerations into the DNS protocol or associated operational
+   scenarios.
+
+6.  Acknowledgment
+
+   This document is the result of many conversations that happened in
+   the DNS community at IETF and elsewhere since 2001.  During that
+   period of time, a number of Internet drafts have been published to
+   clarify various aspects of the issues at stake.  This document
+   focuses on the conclusion of those discussions.
+
+   The authors would like to acknowledge the role of Pekka Savola in his
+   thorough review of the document.
+
+
+
+
+
+
+
+
+
+Durand & Ihren           Best Current Practice                  [Page 3]
+
+RFC 3901             DNS IPv6 Transport Guidelines        September 2004
+
+
+7.  Normative References
+
+   [1]  Mockapetris, P., "Domain names - concepts and facilities", STD
+        13, RFC 1034, November 1987.
+
+   [2]  Mockapetris, P., "Domain names - implementation and
+        specification", STD 13, RFC 1035, November 1987.
+
+   [3]  Bradner, S., "The Internet Standards Process -- Revision 3", BCP
+        9, RFC 2026, October 1996.
+
+   [4]  Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
+        Specification", RFC 2460, December 1998.
+
+   [5]  Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6)
+        Addressing Architecture", RFC 3513, April 2003.
+
+   [6]  Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS
+        Extensions to Support IP Version 6", RFC 3596, October 2003.
+
+8.  Authors' Addresses
+
+   Alain Durand
+   SUN Microsystems, Inc
+   17 Network circle UMPK17-202
+   Menlo Park, CA, 94025
+   USA
+
+   EMail: Alain.Durand@sun.com
+
+
+   Johan Ihren
+   Autonomica
+   Bellmansgatan 30
+   SE-118 47 Stockholm
+   Sweden
+
+   EMail: johani@autonomica.se
+
+
+
+
+
+
+
+
+
+
+
+
+
+Durand & Ihren           Best Current Practice                  [Page 4]
+
+RFC 3901             DNS IPv6 Transport Guidelines        September 2004
+
+
+9.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2004).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE
+   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
+   INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
+   IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
+   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the IETF's procedures with respect to rights in IETF Documents can
+   be found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at ietf-
+   ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+Durand & Ihren           Best Current Practice                  [Page 5]
+
diff --git a/doc/rfc/rfc4025.txt b/doc/rfc/rfc4025.txt
new file mode 100644
index 0000000..92e7f40
--- /dev/null
+++ b/doc/rfc/rfc4025.txt
@@ -0,0 +1,675 @@
+
+
+
+
+
+
+Network Working Group                                      M. Richardson
+Request for Comments: 4025                                           SSW
+Category: Standards Track                                   February 2005
+
+
+           A Method for Storing IPsec Keying Material in DNS
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   This document describes a new resource record for the Domain Name
+   System (DNS).  This record may be used to store public keys for use
+   in IP security (IPsec) systems.  The record also includes provisions
+   for indicating what system should be contacted when an IPsec tunnel
+   is established with the entity in question.
+
+   This record replaces the functionality of the sub-type #4 of the KEY
+   Resource Record, which has been obsoleted by RFC 3445.
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
+       1.1.  Overview . . . . . . . . . . . . . . . . . . . . . . . .  2
+       1.2.  Use of DNS Address-to-Name Maps (IN-ADDR.ARPA and
+             IP6.ARPA)  . . . . . . . . . . . . . . . . . . . . . . .  3
+       1.3.  Usage Criteria . . . . . . . . . . . . . . . . . . . . .  3
+   2.  Storage Formats  . . . . . . . . . . . . . . . . . . . . . . .  3
+       2.1.  IPSECKEY RDATA Format  . . . . . . . . . . . . . . . . .  3
+       2.2.  RDATA Format - Precedence  . . . . . . . . . . . . . . .  4
+       2.3.  RDATA Format - Gateway Type  . . . . . . . . . . . . . .  4
+       2.4.  RDATA Format - Algorithm Type  . . . . . . . . . . . . .  4
+       2.5.  RDATA Format - Gateway . . . . . . . . . . . . . . . . .  5
+       2.6.  RDATA Format - Public Keys . . . . . . . . . . . . . . .  5
+   3.  Presentation Formats . . . . . . . . . . . . . . . . . . . . .  6
+       3.1.  Representation of IPSECKEY RRs . . . . . . . . . . . . .  6
+       3.2.  Examples . . . . . . . . . . . . . . . . . . . . . . . .  6
+   4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7
+
+
+
+Richardson                  Standards Track                     [Page 1]
+
+RFC 4025          Storing IPsec Keying Material in DNS     February 2005
+
+
+       4.1.  Active Attacks Against Unsecured IPSECKEY Resource
+             Records  . . . . . . . . . . . . . . . . . . . . . . . .  8
+             4.1.1.  Active Attacks Against IPSECKEY Keying
+                     Materials. . . . . . . . . . . . . . . . . . . .  8
+             4.1.2.  Active Attacks Against IPSECKEY Gateway
+                     Material. . . . . . . . . . . . . . . . . . . .   8
+   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
+   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
+   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
+       7.1.  Normative References . . . . . . . . . . . . . . . . . . 10
+       7.2.  Informative References . . . . . . . . . . . . . . . . . 10
+   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11
+   Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 12
+
+1.  Introduction
+
+   Suppose a host wishes (or is required by policy) to establish an
+   IPsec tunnel with some remote entity on the network prior to allowing
+   normal communication to take place.  In many cases, this end system
+   will be able to determine the DNS name for the remote entity (either
+   by having the DNS name given explicitly, by performing a DNS PTR
+   query for a particular IP address, or through some other means, e.g.,
+   by extracting the DNS portion of a "user@FQDN" name for a remote
+   entity).  In these cases, the host will need to obtain a public key
+   to authenticate the remote entity, and may also need some guidance
+   about whether it should contact the entity directly or use another
+   node as a gateway to the target entity.  The IPSECKEY RR provides a
+   mechanism for storing such information.
+
+   The type number for the IPSECKEY RR is 45.
+
+   This record replaces the functionality of the sub-type #4 of the KEY
+   Resource Record, which has been obsoleted by RFC 3445 [11].
+
+1.1.  Overview
+
+   The IPSECKEY resource record (RR) is used to publish a public key
+   that is to be associated with a Domain Name System (DNS) [1] name for
+   use with the IPsec protocol suite.  This can be the public key of a
+   host, network, or application (in the case of per-port keying).
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [3].
+
+
+
+
+
+
+
+Richardson                  Standards Track                     [Page 2]
+
+RFC 4025          Storing IPsec Keying Material in DNS     February 2005
+
+
+1.2.  Use of DNS Address-to-Name Maps (IN-ADDR.ARPA and IP6.ARPA)
+
+   Often a security gateway will only have access to the IP address of
+   the node with which communication is desired and will not know any
+   other name for the target node.  Because of this, frequently the best
+   way of looking up IPSECKEY RRs will be by using the IP address as an
+   index into one of the reverse mapping trees (IN-ADDR.ARPA for IPv4 or
+   IP6.ARPA for IPv6).
+
+   The lookup is done in the fashion usual for PTR records.  The IP
+   address' octets (IPv4) or nibbles (IPv6) are reversed and looked up
+   with the appropriate suffix.  Any CNAMEs or DNAMEs found MUST be
+   followed.
+
+   Note: even when the IPsec function is contained in the end-host,
+   often only the application will know the forward name used.  Although
+   the case where the application knows the forward name is common, the
+   user could easily have typed in a literal IP address.  This storage
+   mechanism does not preclude using the forward name when it is
+   available but does not require it.
+
+1.3.  Usage Criteria
+
+   An IPSECKEY resource record SHOULD be used in combination with DNSSEC
+   [8] unless some other means of authenticating the IPSECKEY resource
+   record is available.
+
+   It is expected that there will often be multiple IPSECKEY resource
+   records at the same name.  This will be due to the presence of
+   multiple gateways and a need to roll over keys.
+
+   This resource record is class independent.
+
+2.  Storage Formats
+
+2.1.  IPSECKEY RDATA Format
+
+   The RDATA for an IPSECKEY RR consists of a precedence value, a
+   gateway type, a public key, algorithm type, and an optional gateway
+   address.
+
+
+
+
+
+
+
+
+
+
+
+Richardson                  Standards Track                     [Page 3]
+
+RFC 4025          Storing IPsec Keying Material in DNS     February 2005
+
+
+       0                   1                   2                   3
+       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |  precedence   | gateway type  |  algorithm  |     gateway     |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------+                 +
+      ~                            gateway                            ~
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                                                               /
+      /                          public key                           /
+      /                                                               /
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
+
+2.2.  RDATA Format - Precedence
+
+   This is an 8-bit precedence for this record.  It is interpreted in
+   the same way as the PREFERENCE field described in section 3.3.9 of
+   RFC 1035 [2].
+
+   Gateways listed in IPSECKEY records with lower precedence are to be
+   attempted first.  Where there is a tie in precedence, the order
+   should be non-deterministic.
+
+2.3.  RDATA Format - Gateway Type
+
+   The gateway type field indicates the format of the information that
+   is stored in the gateway field.
+
+   The following values are defined:
+   0  No gateway is present.
+   1  A 4-byte IPv4 address is present.
+   2  A 16-byte IPv6 address is present.
+   3  A wire-encoded domain name is present.  The wire-encoded format is
+      self-describing, so the length is implicit.  The domain name MUST
+      NOT be compressed.  (See Section 3.3 of RFC 1035 [2].)
+
+2.4.  RDATA Format - Algorithm Type
+
+   The algorithm type field identifies the public key's cryptographic
+   algorithm and determines the format of the public key field.
+
+   A value of 0 indicates that no key is present.
+
+   The following values are defined:
+   1  A DSA key is present, in the format defined in RFC 2536 [9].
+   2  A RSA key is present, in the format defined in RFC 3110 [10].
+
+
+
+
+
+
+Richardson                  Standards Track                     [Page 4]
+
+RFC 4025          Storing IPsec Keying Material in DNS     February 2005
+
+
+2.5.  RDATA Format - Gateway
+
+   The gateway field indicates a gateway to which an IPsec tunnel may be
+   created in order to reach the entity named by this resource record.
+
+   There are three formats:
+
+   A 32-bit IPv4 address is present in the gateway field.  The data
+   portion is an IPv4 address as described in section 3.4.1 of RFC 1035
+   [2].  This is a 32-bit number in network byte order.
+
+   A 128-bit IPv6 address is present in the gateway field.  The data
+   portion is an IPv6 address as described in section 2.2 of RFC 3596
+   [12].  This is a 128-bit number in network byte order.
+
+   The gateway field is a normal wire-encoded domain name, as described
+   in section 3.3 of RFC 1035 [2].  Compression MUST NOT be used.
+
+2.6.  RDATA Format - Public Keys
+
+   Both the public key types defined in this document (RSA and DSA)
+   inherit their public key formats from the corresponding KEY RR
+   formats.  Specifically, the public key field contains the
+   algorithm-specific portion of the KEY RR RDATA, which is all the KEY
+   RR DATA after the first four octets.  This is the same portion of the
+   KEY RR that must be specified by documents that define a DNSSEC
+   algorithm.  Those documents also specify a message digest to be used
+   for generation of SIG RRs; that specification is not relevant for
+   IPSECKEY RRs.
+
+   Future algorithms, if they are to be used by both DNSSEC (in the KEY
+   RR) and IPSECKEY, are likely to use the same public key encodings in
+   both records.  Unless otherwise specified, the IPSECKEY public key
+   field will contain the algorithm-specific portion of the KEY RR RDATA
+   for the corresponding algorithm.  The algorithm must still be
+   designated for use by IPSECKEY, and an IPSECKEY algorithm type number
+   (which might be different from the DNSSEC algorithm number) must be
+   assigned to it.
+
+   The DSA key format is defined in RFC 2536 [9]
+
+   The RSA key format is defined in RFC 3110 [10], with the following
+   changes:
+
+   The earlier definition of RSA/MD5 in RFC 2065 [4] limited the
+   exponent and modulus to 2552 bits in length.  RFC 3110 extended that
+   limit to 4096 bits for RSA/SHA1 keys.  The IPSECKEY RR imposes no
+   length limit on RSA public keys, other than the 65535 octet limit
+
+
+
+Richardson                  Standards Track                     [Page 5]
+
+RFC 4025          Storing IPsec Keying Material in DNS     February 2005
+
+
+   imposed by the two-octet length encoding.  This length extension is
+   applicable only to IPSECKEY; it is not applicable to KEY RRs.
+
+3.  Presentation Formats
+
+3.1.  Representation of IPSECKEY RRs
+
+   IPSECKEY RRs may appear in a zone data master file.  The precedence,
+   gateway type, algorithm, and gateway fields are REQUIRED.  The base64
+   encoded public key block is OPTIONAL; if it is not present, the
+   public key field of the resource record MUST be construed to be zero
+   octets in length.
+
+   The algorithm field is an unsigned integer.  No mnemonics are
+   defined.
+
+   If no gateway is to be indicated, then the gateway type field MUST be
+   zero, and the gateway field MUST be "."
+
+   The Public Key field is represented as a Base64 encoding of the
+   Public Key.  Whitespace is allowed within the Base64 text.  For a
+   definition of Base64 encoding, see RFC 3548 [6], Section 5.2.
+
+   The general presentation for the record is as follows:
+
+   IN     IPSECKEY ( precedence gateway-type algorithm
+                     gateway base64-encoded-public-key )
+
+3.2.  Examples
+
+   An example of a node, 192.0.2.38, that will accept IPsec tunnels on
+   its own behalf.
+
+   38.2.0.192.in-addr.arpa. 7200 IN     IPSECKEY ( 10 1 2
+                    192.0.2.38
+                    AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== )
+
+   An example of a node, 192.0.2.38, that has published its key only.
+
+   38.2.0.192.in-addr.arpa. 7200 IN     IPSECKEY ( 10 0 2
+                    .
+                    AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== )
+
+
+
+
+
+
+
+
+
+Richardson                  Standards Track                     [Page 6]
+
+RFC 4025          Storing IPsec Keying Material in DNS     February 2005
+
+
+   An example of a node, 192.0.2.38, that has delegated authority to the
+   node 192.0.2.3.
+
+   38.2.0.192.in-addr.arpa. 7200 IN     IPSECKEY ( 10 1 2
+                    192.0.2.3
+                    AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== )
+
+   An example of a node, 192.0.1.38 that has delegated authority to the
+   node with the identity "mygateway.example.com".
+
+   38.1.0.192.in-addr.arpa. 7200 IN     IPSECKEY ( 10 3 2
+                    mygateway.example.com.
+                    AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== )
+
+   An example of a node, 2001:0DB8:0200:1:210:f3ff:fe03:4d0, that has
+   delegated authority to the node 2001:0DB8:c000:0200:2::1
+
+   $ORIGIN 1.0.0.0.0.0.2.8.B.D.0.1.0.0.2.ip6.arpa.
+   0.d.4.0.3.0.e.f.f.f.3.f.0.1.2.0 7200 IN     IPSECKEY ( 10 2 2
+                    2001:0DB8:0:8002::2000:1
+                    AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== )
+
+4.  Security Considerations
+
+   This entire memo pertains to the provision of public keying material
+   for use by key management protocols such as ISAKMP/IKE (RFC 2407)
+   [7].
+
+   The IPSECKEY resource record contains information that SHOULD be
+   communicated to the end client in an integral fashion; i.e., free
+   from modification.  The form of this channel is up to the consumer of
+   the data; there must be a trust relationship between the end consumer
+   of this resource record and the server.  This relationship may be
+   end-to-end DNSSEC validation, a TSIG or SIG(0) channel to another
+   secure source, a secure local channel on the host, or some
+   combination of the above.
+
+   The keying material provided by the IPSECKEY resource record is not
+   sensitive to passive attacks.  The keying material may be freely
+   disclosed to any party without any impact on the security properties
+   of the resulting IPsec session.  IPsec and IKE provide defense
+   against both active and passive attacks.
+
+   Any derivative specification that makes use of this resource record
+   MUST carefully document its trust model and why the trust model of
+   DNSSEC is appropriate, if that is the secure channel used.
+
+
+
+
+
+Richardson                  Standards Track                     [Page 7]
+
+RFC 4025          Storing IPsec Keying Material in DNS     February 2005
+
+
+   An active attack on the DNS that caused the wrong IP address to be
+   retrieved (via forged address), and therefore the wrong QNAME to be
+   queried, would also result in a man-in-the-middle attack.  This
+   situation is independent of whether the IPSECKEY RR is used.
+
+4.1.  Active Attacks Against Unsecured IPSECKEY Resource Records
+
+   This section deals with active attacks against the DNS.  These
+   attacks require that DNS requests and responses be intercepted and
+   changed.  DNSSEC is designed to defend against attacks of this kind.
+   This section deals with the situation in which DNSSEC is not
+   available.  This is not the recommended deployment scenario.
+
+4.1.1.  Active Attacks Against IPSECKEY Keying Materials
+
+   The first kind of active attack is when the attacker replaces the
+   keying material with either a key under its control or with garbage.
+
+   The gateway field is either untouched or is null.  The IKE
+   negotiation will therefore occur with the original end-system.  For
+   this attack to succeed, the attacker must perform a man-in-the-middle
+   attack on the IKE negotiation.  This attack requires that the
+   attacker be able to intercept and modify packets on the forwarding
+   path for the IKE and data packets.
+
+   If the attacker is not able to perform this man-in-the-middle attack
+   on the IKE negotiation, then a denial of service will result, as the
+   IKE negotiation will fail.
+
+   If the attacker is not only able to mount active attacks against DNS
+   but also in a position to perform a man-in-the-middle attack on IKE
+   and IPsec negotiations, then the attacker will be able to compromise
+   the resulting IPsec channel.  Note that an attacker must be able to
+   perform active DNS attacks on both sides of the IKE negotiation for
+   this to succeed.
+
+4.1.2.  Active Attacks Against IPSECKEY Gateway Material
+
+   The second kind of active attack is one in which the attacker
+   replaces the gateway address to point to a node under the attacker's
+   control.  The attacker then either replaces the public key or removes
+   it.  If the public key were removed, then the attacker could provide
+   an accurate public key of its own in a second record.
+
+   This second form creates a simple man-in-the-middle attacks since the
+   attacker can then create a second tunnel to the real destination.
+   Note that, as before, this requires that the attacker also mount an
+   active attack against the responder.
+
+
+
+Richardson                  Standards Track                     [Page 8]
+
+RFC 4025          Storing IPsec Keying Material in DNS     February 2005
+
+
+   Note that the man-in-the-middle cannot just forward cleartext packets
+   to the original destination.  While the destination may be willing to
+   speak in the clear, replying to the original sender, the sender will
+   already have created a policy expecting ciphertext.  Thus, the
+   attacker will need to intercept traffic in both directions.  In some
+   cases, the attacker may be able to accomplish the full intercept by
+   use of Network Address/Port Translation (NAT/NAPT) technology.
+
+   This attack is easier than the first one because the attacker does
+   NOT need to be on the end-to-end forwarding path.  The attacker need
+   only be able to modify DNS replies.  This can be done by packet
+   modification, by various kinds of race attacks, or through methods
+   that pollute DNS caches.
+
+   If the end-to-end integrity of the IPSECKEY RR is suspect, the end
+   client MUST restrict its use of the IPSECKEY RR to cases where the RR
+   owner name matches the content of the gateway field.  As the RR owner
+   name is assumed when the gateway field is null, a null gateway field
+   is considered a match.
+
+   Thus, any records obtained under unverified conditions (e.g., no
+   DNSSEC or trusted path to source) that have a non-null gateway field
+   MUST be ignored.
+
+   This restriction eliminates attacks against the gateway field, which
+   are considered much easier, as the attack does not need to be on the
+   forwarding path.
+
+   In the case of an IPSECKEY RR with a value of three in its gateway
+   type field, the gateway field contains a domain name.  The subsequent
+   query required to translate that name into an IP address or IPSECKEY
+   RR will also be subject to man-in-the-middle attacks.  If the
+   end-to-end integrity of this second query is suspect, then the
+   provisions above also apply.  The IPSECKEY RR MUST be ignored
+   whenever the resulting gateway does not match the QNAME of the
+   original IPSECKEY RR query.
+
+5.  IANA Considerations
+
+   This document updates the IANA Registry for DNS Resource Record Types
+   by assigning type 45 to the IPSECKEY record.
+
+   This document creates two new IANA registries, both specific to the
+   IPSECKEY Resource Record:
+
+   This document creates an IANA registry for the algorithm type field.
+
+
+
+
+
+Richardson                  Standards Track                     [Page 9]
+
+RFC 4025          Storing IPsec Keying Material in DNS     February 2005
+
+
+   Values 0, 1, and 2 are defined in Section 2.4.  Algorithm numbers 3
+   through 255 can be assigned by IETF Consensus (see RFC 2434 [5]).
+
+   This document creates an IANA registry for the gateway type field.
+
+   Values 0, 1, 2, and 3 are defined in Section 2.3.  Gateway type
+   numbers 4 through 255 can be assigned by Standards Action (see RFC
+   2434 [5]).
+
+6.  Acknowledgements
+
+   My thanks to Paul Hoffman, Sam Weiler, Jean-Jacques Puig, Rob
+   Austein, and Olafur Gudmundsson, who reviewed this document
+   carefully.  Additional thanks to Olafur Gurmundsson for a reference
+   implementation.
+
+7.  References
+
+7.1.  Normative References
+
+   [1]  Mockapetris, P., "Domain names - concepts and facilities", STD
+        13, RFC 1034, November 1987.
+
+   [2]  Mockapetris, P., "Domain names - implementation and
+        specification", STD 13, RFC 1035, November 1987.
+
+   [3]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", BCP 14, RFC 2119, March 1997.
+
+   [4]  Eastlake 3rd, D. and C. Kaufman, "Domain Name System Security
+        Extensions", RFC 2065, January 1997.
+
+   [5]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
+        Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
+
+   [6]  Josefsson, S., "The Base16, Base32, and Base64 Data Encodings",
+        RFC 3548, July 2003.
+
+7.2.  Informative References
+
+   [7]  Piper, D., "The Internet IP Security Domain of Interpretation
+        for ISAKMP", RFC 2407, November 1998.
+
+   [8]  Eastlake 3rd, D., "Domain Name System Security Extensions", RFC
+        2535, March 1999.
+
+   [9]  Eastlake 3rd, D., "DSA KEYs and SIGs in the Domain Name System
+        (DNS)", RFC 2536, March 1999.
+
+
+
+Richardson                  Standards Track                    [Page 10]
+
+RFC 4025          Storing IPsec Keying Material in DNS     February 2005
+
+
+   [10] Eastlake 3rd, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain
+        Name System (DNS)", RFC 3110, May 2001.
+
+   [11] Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource
+        Record (RR)", RFC 3445, December 2002.
+
+   [12] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS
+        Extensions to Support IP Version 6", RFC 3596, October 2003.
+
+Author's Address
+
+   Michael C. Richardson
+   Sandelman Software Works
+   470 Dawson Avenue
+   Ottawa, ON  K1Z 5V7
+   CA
+
+   EMail: mcr@sandelman.ottawa.on.ca
+   URI:   http://www.sandelman.ottawa.on.ca/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Richardson                  Standards Track                    [Page 11]
+
+RFC 4025          Storing IPsec Keying Material in DNS     February 2005
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2005).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the IETF's procedures with respect to rights in IETF Documents can
+   be found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at ietf-
+   ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+Richardson                  Standards Track                    [Page 12]
+
diff --git a/doc/rfc/rfc4033.txt b/doc/rfc/rfc4033.txt
new file mode 100644
index 0000000..7f0a464
--- /dev/null
+++ b/doc/rfc/rfc4033.txt
@@ -0,0 +1,1179 @@
+
+
+
+
+
+
+Network Working Group                                          R. Arends
+Request for Comments: 4033                          Telematica Instituut
+Obsoletes: 2535, 3008, 3090, 3445, 3655, 3658,                R. Austein
+           3755, 3757, 3845                                          ISC
+Updates: 1034, 1035, 2136, 2181, 2308, 3225,                   M. Larson
+         3007, 3597, 3226                                       VeriSign
+Category: Standards Track                                      D. Massey
+                                               Colorado State University
+                                                                 S. Rose
+                                                                    NIST
+                                                              March 2005
+
+
+               DNS Security Introduction and Requirements
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   The Domain Name System Security Extensions (DNSSEC) add data origin
+   authentication and data integrity to the Domain Name System.  This
+   document introduces these extensions and describes their capabilities
+   and limitations.  This document also discusses the services that the
+   DNS security extensions do and do not provide.  Last, this document
+   describes the interrelationships between the documents that
+   collectively describe DNSSEC.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al.              Standards Track                     [Page 1]
+
+RFC 4033       DNS Security Introduction and Requirements     March 2005
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . .   2
+   2.  Definitions of Important DNSSEC Terms  . . . . . . . . . . .   3
+   3.  Services Provided by DNS Security  . . . . . . . . . . . . .   7
+       3.1.  Data Origin Authentication and Data Integrity  . . . .   7
+       3.2.  Authenticating Name and Type Non-Existence . . . . . .   9
+   4.  Services Not Provided by DNS Security  . . . . . . . . . . .   9
+   5.  Scope of the DNSSEC Document Set and Last Hop Issues . . . .   9
+   6.  Resolver Considerations  . . . . . . . . . . . . . . . . . .  10
+   7.  Stub Resolver Considerations . . . . . . . . . . . . . . . .  11
+   8.  Zone Considerations  . . . . . . . . . . . . . . . . . . . .  12
+       8.1.  TTL Values vs. RRSIG Validity Period . . . . . . . . .  13
+       8.2.  New Temporal Dependency Issues for Zones . . . . . . .  13
+   9.  Name Server Considerations . . . . . . . . . . . . . . . . .  13
+   10. DNS Security Document Family . . . . . . . . . . . . . . . .  14
+   11. IANA Considerations  . . . . . . . . . . . . . . . . . . . .  15
+   12. Security Considerations  . . . . . . . . . . . . . . . . . .  15
+   13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . .  17
+   14. References . . . . . . . . . . . . . . . . . . . . . . . . .  17
+       14.1. Normative References . . . . . . . . . . . . . . . . .  17
+       14.2. Informative References . . . . . . . . . . . . . . . .  18
+   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . .  20
+   Full Copyright Statement . . . . . . . . . . . . . . . . . . . .  21
+
+1.  Introduction
+
+   This document introduces the Domain Name System Security Extensions
+   (DNSSEC).  This document and its two companion documents ([RFC4034]
+   and [RFC4035]) update, clarify, and refine the security extensions
+   defined in [RFC2535] and its predecessors.  These security extensions
+   consist of a set of new resource record types and modifications to
+   the existing DNS protocol ([RFC1035]).  The new records and protocol
+   modifications are not fully described in this document, but are
+   described in a family of documents outlined in Section 10.  Sections
+   3 and 4 describe the capabilities and limitations of the security
+   extensions in greater detail.  Section 5 discusses the scope of the
+   document set.  Sections 6, 7, 8, and 9 discuss the effect that these
+   security extensions will have on resolvers, stub resolvers, zones,
+   and name servers.
+
+   This document and its two companions obsolete [RFC2535], [RFC3008],
+   [RFC3090], [RFC3445], [RFC3655], [RFC3658], [RFC3755], [RFC3757], and
+   [RFC3845].  This document set also updates but does not obsolete
+   [RFC1034], [RFC1035], [RFC2136], [RFC2181], [RFC2308], [RFC3225],
+   [RFC3007], [RFC3597], and the portions of [RFC3226] that deal with
+   DNSSEC.
+
+
+
+
+Arends, et al.              Standards Track                     [Page 2]
+
+RFC 4033       DNS Security Introduction and Requirements     March 2005
+
+
+   The DNS security extensions provide origin authentication and
+   integrity protection for DNS data, as well as a means of public key
+   distribution.  These extensions do not provide confidentiality.
+
+2.  Definitions of Important DNSSEC Terms
+
+   This section defines a number of terms used in this document set.
+   Because this is intended to be useful as a reference while reading
+   the rest of the document set, first-time readers may wish to skim
+   this section quickly, read the rest of this document, and then come
+   back to this section.
+
+   Authentication Chain: An alternating sequence of DNS public key
+      (DNSKEY) RRsets and Delegation Signer (DS) RRsets forms a chain of
+      signed data, with each link in the chain vouching for the next.  A
+      DNSKEY RR is used to verify the signature covering a DS RR and
+      allows the DS RR to be authenticated.  The DS RR contains a hash
+      of another DNSKEY RR and this new DNSKEY RR is authenticated by
+      matching the hash in the DS RR.  This new DNSKEY RR in turn
+      authenticates another DNSKEY RRset and, in turn, some DNSKEY RR in
+      this set may be used to authenticate another DS RR, and so forth
+      until the chain finally ends with a DNSKEY RR whose corresponding
+      private key signs the desired DNS data.  For example, the root
+      DNSKEY RRset can be used to authenticate the DS RRset for
+      "example."  The "example." DS RRset contains a hash that matches
+      some "example." DNSKEY, and this DNSKEY's corresponding private
+      key signs the "example." DNSKEY RRset.  Private key counterparts
+      of the "example." DNSKEY RRset sign data records such as
+      "www.example." and DS RRs for delegations such as
+      "subzone.example."
+
+   Authentication Key: A public key that a security-aware resolver has
+      verified and can therefore use to authenticate data.  A
+      security-aware resolver can obtain authentication keys in three
+      ways.  First, the resolver is generally configured to know about
+      at least one public key; this configured data is usually either
+      the public key itself or a hash of the public key as found in the
+      DS RR (see "trust anchor").  Second, the resolver may use an
+      authenticated public key to verify a DS RR and the DNSKEY RR to
+      which the DS RR refers.  Third, the resolver may be able to
+      determine that a new public key has been signed by the private key
+      corresponding to another public key that the resolver has
+      verified.  Note that the resolver must always be guided by local
+      policy when deciding whether to authenticate a new public key,
+      even if the local policy is simply to authenticate any new public
+      key for which the resolver is able verify the signature.
+
+
+
+
+
+Arends, et al.              Standards Track                     [Page 3]
+
+RFC 4033       DNS Security Introduction and Requirements     March 2005
+
+
+   Authoritative RRset: Within the context of a particular zone, an
+      RRset is "authoritative" if and only if the owner name of the
+      RRset lies within the subset of the name space that is at or below
+      the zone apex and at or above the cuts that separate the zone from
+      its children, if any.  All RRsets at the zone apex are
+      authoritative, except for certain RRsets at this domain name that,
+      if present, belong to this zone's parent.  These RRset could
+      include a DS RRset, the NSEC RRset referencing this DS RRset (the
+      "parental NSEC"), and RRSIG RRs associated with these RRsets, all
+      of which are authoritative in the parent zone.  Similarly, if this
+      zone contains any delegation points, only the parental NSEC RRset,
+      DS RRsets, and any RRSIG RRs associated with these RRsets are
+      authoritative for this zone.
+
+   Delegation Point: Term used to describe the name at the parental side
+      of a zone cut.  That is, the delegation point for "foo.example"
+      would be the foo.example node in the "example" zone (as opposed to
+      the zone apex of the "foo.example" zone).  See also zone apex.
+
+   Island of Security: Term used to describe a signed, delegated zone
+      that does not have an authentication chain from its delegating
+      parent.  That is, there is no DS RR containing a hash of a DNSKEY
+      RR for the island in its delegating parent zone (see [RFC4034]).
+      An island of security is served by security-aware name servers and
+      may provide authentication chains to any delegated child zones.
+      Responses from an island of security or its descendents can only
+      be authenticated if its authentication keys can be authenticated
+      by some trusted means out of band from the DNS protocol.
+
+   Key Signing Key (KSK): An authentication key that corresponds to a
+      private key used to sign one or more other authentication keys for
+      a given zone.  Typically, the private key corresponding to a key
+      signing key will sign a zone signing key, which in turn has a
+      corresponding private key that will sign other zone data.  Local
+      policy may require that the zone signing key be changed
+      frequently, while the key signing key may have a longer validity
+      period in order to provide a more stable secure entry point into
+      the zone.  Designating an authentication key as a key signing key
+      is purely an operational issue: DNSSEC validation does not
+      distinguish between key signing keys and other DNSSEC
+      authentication keys, and it is possible to use a single key as
+      both a key signing key and a zone signing key.  Key signing keys
+      are discussed in more detail in [RFC3757].  Also see zone signing
+      key.
+
+
+
+
+
+
+
+Arends, et al.              Standards Track                     [Page 4]
+
+RFC 4033       DNS Security Introduction and Requirements     March 2005
+
+
+   Non-Validating Security-Aware Stub Resolver: A security-aware stub
+      resolver that trusts one or more security-aware recursive name
+      servers to perform most of the tasks discussed in this document
+      set on its behalf.  In particular, a non-validating security-aware
+      stub resolver is an entity that sends DNS queries, receives DNS
+      responses, and is capable of establishing an appropriately secured
+      channel to a security-aware recursive name server that will
+      provide these services on behalf of the security-aware stub
+      resolver.  See also security-aware stub resolver, validating
+      security-aware stub resolver.
+
+   Non-Validating Stub Resolver: A less tedious term for a
+      non-validating security-aware stub resolver.
+
+   Security-Aware Name Server: An entity acting in the role of a name
+      server (defined in section 2.4 of [RFC1034]) that understands the
+      DNS security extensions defined in this document set.  In
+      particular, a security-aware name server is an entity that
+      receives DNS queries, sends DNS responses, supports the EDNS0
+      ([RFC2671]) message size extension and the DO bit ([RFC3225]), and
+      supports the RR types and message header bits defined in this
+      document set.
+
+   Security-Aware Recursive Name Server: An entity that acts in both the
+      security-aware name server and security-aware resolver roles.  A
+      more cumbersome but equivalent phrase would be "a security-aware
+      name server that offers recursive service".
+
+   Security-Aware Resolver: An entity acting in the role of a resolver
+      (defined in section 2.4 of [RFC1034]) that understands the DNS
+      security extensions defined in this document set.  In particular,
+      a security-aware resolver is an entity that sends DNS queries,
+      receives DNS responses, supports the EDNS0 ([RFC2671]) message
+      size extension and the DO bit ([RFC3225]), and is capable of using
+      the RR types and message header bits defined in this document set
+      to provide DNSSEC services.
+
+   Security-Aware Stub Resolver: An entity acting in the role of a stub
+      resolver (defined in section 5.3.1 of [RFC1034]) that has enough
+      of an understanding the DNS security extensions defined in this
+      document set to provide additional services not available from a
+      security-oblivious stub resolver.  Security-aware stub resolvers
+      may be either "validating" or "non-validating", depending on
+      whether the stub resolver attempts to verify DNSSEC signatures on
+      its own or trusts a friendly security-aware name server to do so.
+      See also validating stub resolver, non-validating stub resolver.
+
+
+
+
+
+Arends, et al.              Standards Track                     [Page 5]
+
+RFC 4033       DNS Security Introduction and Requirements     March 2005
+
+
+   Security-Oblivious <anything>: An <anything> that is not
+      "security-aware".
+
+   Signed Zone: A zone whose RRsets are signed and that contains
+      properly constructed DNSKEY, Resource Record Signature (RRSIG),
+      Next Secure (NSEC), and (optionally) DS records.
+
+   Trust Anchor: A configured DNSKEY RR or DS RR hash of a DNSKEY RR.  A
+      validating security-aware resolver uses this public key or hash as
+      a starting point for building the authentication chain to a signed
+      DNS response.  In general, a validating resolver will have to
+      obtain the initial values of its trust anchors via some secure or
+      trusted means outside the DNS protocol.  Presence of a trust
+      anchor also implies that the resolver should expect the zone to
+      which the trust anchor points to be signed.
+
+   Unsigned Zone: A zone that is not signed.
+
+   Validating Security-Aware Stub Resolver: A security-aware resolver
+      that sends queries in recursive mode but that performs signature
+      validation on its own rather than just blindly trusting an
+      upstream security-aware recursive name server.  See also
+      security-aware stub resolver, non-validating security-aware stub
+      resolver.
+
+   Validating Stub Resolver: A less tedious term for a validating
+      security-aware stub resolver.
+
+   Zone Apex: Term used to describe the name at the child's side of a
+      zone cut.  See also delegation point.
+
+   Zone Signing Key (ZSK): An authentication key that corresponds to a
+      private key used to sign a zone.  Typically, a zone signing key
+      will be part of the same DNSKEY RRset as the key signing key whose
+      corresponding private key signs this DNSKEY RRset, but the zone
+      signing key is used for a slightly different purpose and may
+      differ from the key signing key in other ways, such as validity
+      lifetime.  Designating an authentication key as a zone signing key
+      is purely an operational issue; DNSSEC validation does not
+      distinguish between zone signing keys and other DNSSEC
+      authentication keys, and it is possible to use a single key as
+      both a key signing key and a zone signing key.  See also key
+      signing key.
+
+
+
+
+
+
+
+
+Arends, et al.              Standards Track                     [Page 6]
+
+RFC 4033       DNS Security Introduction and Requirements     March 2005
+
+
+3.  Services Provided by DNS Security
+
+   The Domain Name System (DNS) security extensions provide origin
+   authentication and integrity assurance services for DNS data,
+   including mechanisms for authenticated denial of existence of DNS
+   data.  These mechanisms are described below.
+
+   These mechanisms require changes to the DNS protocol.  DNSSEC adds
+   four new resource record types: Resource Record Signature (RRSIG),
+   DNS Public Key (DNSKEY), Delegation Signer (DS), and Next Secure
+   (NSEC).  It also adds two new message header bits: Checking Disabled
+   (CD) and Authenticated Data (AD).  In order to support the larger DNS
+   message sizes that result from adding the DNSSEC RRs, DNSSEC also
+   requires EDNS0 support ([RFC2671]).  Finally, DNSSEC requires support
+   for the DNSSEC OK (DO) EDNS header bit ([RFC3225]) so that a
+   security-aware resolver can indicate in its queries that it wishes to
+   receive DNSSEC RRs in response messages.
+
+   These services protect against most of the threats to the Domain Name
+   System described in [RFC3833].  Please see Section 12 for a
+   discussion of the limitations of these extensions.
+
+3.1.  Data Origin Authentication and Data Integrity
+
+   DNSSEC provides authentication by associating cryptographically
+   generated digital signatures with DNS RRsets.  These digital
+   signatures are stored in a new resource record, the RRSIG record.
+   Typically, there will be a single private key that signs a zone's
+   data, but multiple keys are possible.  For example, there may be keys
+   for each of several different digital signature algorithms.  If a
+   security-aware resolver reliably learns a zone's public key, it can
+   authenticate that zone's signed data.  An important DNSSEC concept is
+   that the key that signs a zone's data is associated with the zone
+   itself and not with the zone's authoritative name servers.  (Public
+   keys for DNS transaction authentication mechanisms may also appear in
+   zones, as described in [RFC2931], but DNSSEC itself is concerned with
+   object security of DNS data, not channel security of DNS
+   transactions.  The keys associated with transaction security may be
+   stored in different RR types.  See [RFC3755] for details.)
+
+   A security-aware resolver can learn a zone's public key either by
+   having a trust anchor configured into the resolver or by normal DNS
+   resolution.  To allow the latter, public keys are stored in a new
+   type of resource record, the DNSKEY RR.  Note that the private keys
+   used to sign zone data must be kept secure and should be stored
+   offline when practical.  To discover a public key reliably via DNS
+   resolution, the target key itself has to be signed by either a
+   configured authentication key or another key that has been
+
+
+
+Arends, et al.              Standards Track                     [Page 7]
+
+RFC 4033       DNS Security Introduction and Requirements     March 2005
+
+
+   authenticated previously.  Security-aware resolvers authenticate zone
+   information by forming an authentication chain from a newly learned
+   public key back to a previously known authentication public key,
+   which in turn either has been configured into the resolver or must
+   have been learned and verified previously.  Therefore, the resolver
+   must be configured with at least one trust anchor.
+
+   If the configured trust anchor is a zone signing key, then it will
+   authenticate the associated zone; if the configured key is a key
+   signing key, it will authenticate a zone signing key.  If the
+   configured trust anchor is the hash of a key rather than the key
+   itself, the resolver may have to obtain the key via a DNS query.  To
+   help security-aware resolvers establish this authentication chain,
+   security-aware name servers attempt to send the signature(s) needed
+   to authenticate a zone's public key(s) in the DNS reply message along
+   with the public key itself, provided that there is space available in
+   the message.
+
+   The Delegation Signer (DS) RR type simplifies some of the
+   administrative tasks involved in signing delegations across
+   organizational boundaries.  The DS RRset resides at a delegation
+   point in a parent zone and indicates the public key(s) corresponding
+   to the private key(s) used to self-sign the DNSKEY RRset at the
+   delegated child zone's apex.  The administrator of the child zone, in
+   turn, uses the private key(s) corresponding to one or more of the
+   public keys in this DNSKEY RRset to sign the child zone's data.  The
+   typical authentication chain is therefore
+   DNSKEY->[DS->DNSKEY]*->RRset, where "*" denotes zero or more
+   DS->DNSKEY subchains.  DNSSEC permits more complex authentication
+   chains, such as additional layers of DNSKEY RRs signing other DNSKEY
+   RRs within a zone.
+
+   A security-aware resolver normally constructs this authentication
+   chain from the root of the DNS hierarchy down to the leaf zones based
+   on configured knowledge of the public key for the root.  Local
+   policy, however, may also allow a security-aware resolver to use one
+   or more configured public keys (or hashes of public keys) other than
+   the root public key, may not provide configured knowledge of the root
+   public key, or may prevent the resolver from using particular public
+   keys for arbitrary reasons, even if those public keys are properly
+   signed with verifiable signatures.  DNSSEC provides mechanisms by
+   which a security-aware resolver can determine whether an RRset's
+   signature is "valid" within the meaning of DNSSEC.  In the final
+   analysis, however, authenticating both DNS keys and data is a matter
+   of local policy, which may extend or even override the protocol
+   extensions defined in this document set.  See Section 5 for further
+   discussion.
+
+
+
+
+Arends, et al.              Standards Track                     [Page 8]
+
+RFC 4033       DNS Security Introduction and Requirements     March 2005
+
+
+3.2.  Authenticating Name and Type Non-Existence
+
+   The security mechanism described in Section 3.1 only provides a way
+   to sign existing RRsets in a zone.  The problem of providing negative
+   responses with the same level of authentication and integrity
+   requires the use of another new resource record type, the NSEC
+   record.  The NSEC record allows a security-aware resolver to
+   authenticate a negative reply for either name or type non-existence
+   with the same mechanisms used to authenticate other DNS replies.  Use
+   of NSEC records requires a canonical representation and ordering for
+   domain names in zones.  Chains of NSEC records explicitly describe
+   the gaps, or "empty space", between domain names in a zone and list
+   the types of RRsets present at existing names.  Each NSEC record is
+   signed and authenticated using the mechanisms described in Section
+   3.1.
+
+4.  Services Not Provided by DNS Security
+
+   DNS was originally designed with the assumptions that the DNS will
+   return the same answer to any given query regardless of who may have
+   issued the query, and that all data in the DNS is thus visible.
+   Accordingly, DNSSEC is not designed to provide confidentiality,
+   access control lists, or other means of differentiating between
+   inquirers.
+
+   DNSSEC provides no protection against denial of service attacks.
+   Security-aware resolvers and security-aware name servers are
+   vulnerable to an additional class of denial of service attacks based
+   on cryptographic operations.  Please see Section 12 for details.
+
+   The DNS security extensions provide data and origin authentication
+   for DNS data.  The mechanisms outlined above are not designed to
+   protect operations such as zone transfers and dynamic update
+   ([RFC2136], [RFC3007]).  Message authentication schemes described in
+   [RFC2845] and [RFC2931] address security operations that pertain to
+   these transactions.
+
+5.  Scope of the DNSSEC Document Set and Last Hop Issues
+
+   The specification in this document set defines the behavior for zone
+   signers and security-aware name servers and resolvers in such a way
+   that the validating entities can unambiguously determine the state of
+   the data.
+
+   A validating resolver can determine the following 4 states:
+
+   Secure: The validating resolver has a trust anchor, has a chain of
+      trust, and is able to verify all the signatures in the response.
+
+
+
+Arends, et al.              Standards Track                     [Page 9]
+
+RFC 4033       DNS Security Introduction and Requirements     March 2005
+
+
+   Insecure: The validating resolver has a trust anchor, a chain of
+      trust, and, at some delegation point, signed proof of the
+      non-existence of a DS record.  This indicates that subsequent
+      branches in the tree are provably insecure.  A validating resolver
+      may have a local policy to mark parts of the domain space as
+      insecure.
+
+   Bogus: The validating resolver has a trust anchor and a secure
+      delegation indicating that subsidiary data is signed, but the
+      response fails to validate for some reason: missing signatures,
+      expired signatures, signatures with unsupported algorithms, data
+      missing that the relevant NSEC RR says should be present, and so
+      forth.
+
+   Indeterminate: There is no trust anchor that would indicate that a
+      specific portion of the tree is secure.  This is the default
+      operation mode.
+
+   This specification only defines how security-aware name servers can
+   signal non-validating stub resolvers that data was found to be bogus
+   (using RCODE=2, "Server Failure"; see [RFC4035]).
+
+   There is a mechanism for security-aware name servers to signal
+   security-aware stub resolvers that data was found to be secure (using
+   the AD bit; see [RFC4035]).
+
+   This specification does not define a format for communicating why
+   responses were found to be bogus or marked as insecure.  The current
+   signaling mechanism does not distinguish between indeterminate and
+   insecure states.
+
+   A method for signaling advanced error codes and policy between a
+   security-aware stub resolver and security-aware recursive nameservers
+   is a topic for future work, as is the interface between a security-
+   aware resolver and the applications that use it.  Note, however, that
+   the lack of the specification of such communication does not prohibit
+   deployment of signed zones or the deployment of security aware
+   recursive name servers that prohibit propagation of bogus data to the
+   applications.
+
+6.  Resolver Considerations
+
+   A security-aware resolver has to be able to perform cryptographic
+   functions necessary to verify digital signatures using at least the
+   mandatory-to-implement algorithm(s).  Security-aware resolvers must
+   also be capable of forming an authentication chain from a newly
+   learned zone back to an authentication key, as described above.  This
+   process might require additional queries to intermediate DNS zones to
+
+
+
+Arends, et al.              Standards Track                    [Page 10]
+
+RFC 4033       DNS Security Introduction and Requirements     March 2005
+
+
+   obtain necessary DNSKEY, DS, and RRSIG records.  A security-aware
+   resolver should be configured with at least one trust anchor as the
+   starting point from which it will attempt to establish authentication
+   chains.
+
+   If a security-aware resolver is separated from the relevant
+   authoritative name servers by a recursive name server or by any sort
+   of intermediary device that acts as a proxy for DNS, and if the
+   recursive name server or intermediary device is not security-aware,
+   the security-aware resolver may not be capable of operating in a
+   secure mode.  For example, if a security-aware resolver's packets are
+   routed through a network address translation (NAT) device that
+   includes a DNS proxy that is not security-aware, the security-aware
+   resolver may find it difficult or impossible to obtain or validate
+   signed DNS data.  The security-aware resolver may have a particularly
+   difficult time obtaining DS RRs in such a case, as DS RRs do not
+   follow the usual DNS rules for ownership of RRs at zone cuts.  Note
+   that this problem is not specific to NATs: any security-oblivious DNS
+   software of any kind between the security-aware resolver and the
+   authoritative name servers will interfere with DNSSEC.
+
+   If a security-aware resolver must rely on an unsigned zone or a name
+   server that is not security aware, the resolver may not be able to
+   validate DNS responses and will need a local policy on whether to
+   accept unverified responses.
+
+   A security-aware resolver should take a signature's validation period
+   into consideration when determining the TTL of data in its cache, to
+   avoid caching signed data beyond the validity period of the
+   signature.  However, it should also allow for the possibility that
+   the security-aware resolver's own clock is wrong.  Thus, a
+   security-aware resolver that is part of a security-aware recursive
+   name server will have to pay careful attention to the DNSSEC
+   "checking disabled" (CD) bit ([RFC4034]).  This is in order to avoid
+   blocking valid signatures from getting through to other
+   security-aware resolvers that are clients of this recursive name
+   server.  See [RFC4035] for how a secure recursive server handles
+   queries with the CD bit set.
+
+7.  Stub Resolver Considerations
+
+   Although not strictly required to do so by the protocol, most DNS
+   queries originate from stub resolvers.  Stub resolvers, by
+   definition, are minimal DNS resolvers that use recursive query mode
+   to offload most of the work of DNS resolution to a recursive name
+   server.  Given the widespread use of stub resolvers, the DNSSEC
+
+
+
+
+
+Arends, et al.              Standards Track                    [Page 11]
+
+RFC 4033       DNS Security Introduction and Requirements     March 2005
+
+
+   architecture has to take stub resolvers into account, but the
+   security features needed in a stub resolver differ in some respects
+   from those needed in a security-aware iterative resolver.
+
+   Even a security-oblivious stub resolver may benefit from DNSSEC if
+   the recursive name servers it uses are security-aware, but for the
+   stub resolver to place any real reliance on DNSSEC services, the stub
+   resolver must trust both the recursive name servers in question and
+   the communication channels between itself and those name servers.
+   The first of these issues is a local policy issue: in essence, a
+   security-oblivious stub resolver has no choice but to place itself at
+   the mercy of the recursive name servers that it uses, as it does not
+   perform DNSSEC validity checks on its own.  The second issue requires
+   some kind of channel security mechanism; proper use of DNS
+   transaction authentication mechanisms such as SIG(0) ([RFC2931]) or
+   TSIG ([RFC2845]) would suffice, as would appropriate use of IPsec.
+   Particular implementations may have other choices available, such as
+   operating system specific interprocess communication mechanisms.
+   Confidentiality is not needed for this channel, but data integrity
+   and message authentication are.
+
+   A security-aware stub resolver that does trust both its recursive
+   name servers and its communication channel to them may choose to
+   examine the setting of the Authenticated Data (AD) bit in the message
+   header of the response messages it receives.  The stub resolver can
+   use this flag bit as a hint to find out whether the recursive name
+   server was able to validate signatures for all of the data in the
+   Answer and Authority sections of the response.
+
+   There is one more step that a security-aware stub resolver can take
+   if, for whatever reason, it is not able to establish a useful trust
+   relationship with the recursive name servers that it uses: it can
+   perform its own signature validation by setting the Checking Disabled
+   (CD) bit in its query messages.  A validating stub resolver is thus
+   able to treat the DNSSEC signatures as trust relationships between
+   the zone administrators and the stub resolver itself.
+
+8.  Zone Considerations
+
+   There are several differences between signed and unsigned zones.  A
+   signed zone will contain additional security-related records (RRSIG,
+   DNSKEY, DS, and NSEC records).  RRSIG and NSEC records may be
+   generated by a signing process prior to serving the zone.  The RRSIG
+   records that accompany zone data have defined inception and
+   expiration times that establish a validity period for the signatures
+   and the zone data the signatures cover.
+
+
+
+
+
+Arends, et al.              Standards Track                    [Page 12]
+
+RFC 4033       DNS Security Introduction and Requirements     March 2005
+
+
+8.1.  TTL Values vs. RRSIG Validity Period
+
+   It is important to note the distinction between a RRset's TTL value
+   and the signature validity period specified by the RRSIG RR covering
+   that RRset.  DNSSEC does not change the definition or function of the
+   TTL value, which is intended to maintain database coherency in
+   caches.  A caching resolver purges RRsets from its cache no later
+   than the end of the time period specified by the TTL fields of those
+   RRsets, regardless of whether the resolver is security-aware.
+
+   The inception and expiration fields in the RRSIG RR ([RFC4034]), on
+   the other hand, specify the time period during which the signature
+   can be used to validate the covered RRset.  The signatures associated
+   with signed zone data are only valid for the time period specified by
+   these fields in the RRSIG RRs in question.  TTL values cannot extend
+   the validity period of signed RRsets in a resolver's cache, but the
+   resolver may use the time remaining before expiration of the
+   signature validity period of a signed RRset as an upper bound for the
+   TTL of the signed RRset and its associated RRSIG RR in the resolver's
+   cache.
+
+8.2.  New Temporal Dependency Issues for Zones
+
+   Information in a signed zone has a temporal dependency that did not
+   exist in the original DNS protocol.  A signed zone requires regular
+   maintenance to ensure that each RRset in the zone has a current valid
+   RRSIG RR.  The signature validity period of an RRSIG RR is an
+   interval during which the signature for one particular signed RRset
+   can be considered valid, and the signatures of different RRsets in a
+   zone may expire at different times.  Re-signing one or more RRsets in
+   a zone will change one or more RRSIG RRs, which will in turn require
+   incrementing the zone's SOA serial number to indicate that a zone
+   change has occurred and re-signing the SOA RRset itself.  Thus,
+   re-signing any RRset in a zone may also trigger DNS NOTIFY messages
+   and zone transfer operations.
+
+9.  Name Server Considerations
+
+   A security-aware name server should include the appropriate DNSSEC
+   records (RRSIG, DNSKEY, DS, and NSEC) in all responses to queries
+   from resolvers that have signaled their willingness to receive such
+   records via use of the DO bit in the EDNS header, subject to message
+   size limitations.  Because inclusion of these DNSSEC RRs could easily
+   cause UDP message truncation and fallback to TCP, a security-aware
+   name server must also support the EDNS "sender's UDP payload"
+   mechanism.
+
+
+
+
+
+Arends, et al.              Standards Track                    [Page 13]
+
+RFC 4033       DNS Security Introduction and Requirements     March 2005
+
+
+   If possible, the private half of each DNSSEC key pair should be kept
+   offline, but this will not be possible for a zone for which DNS
+   dynamic update has been enabled.  In the dynamic update case, the
+   primary master server for the zone will have to re-sign the zone when
+   it is updated, so the private key corresponding to the zone signing
+   key will have to be kept online.  This is an example of a situation
+   in which the ability to separate the zone's DNSKEY RRset into zone
+   signing key(s) and key signing key(s) may be useful, as the key
+   signing key(s) in such a case can still be kept offline and may have
+   a longer useful lifetime than the zone signing key(s).
+
+   By itself, DNSSEC is not enough to protect the integrity of an entire
+   zone during zone transfer operations, as even a signed zone contains
+   some unsigned, nonauthoritative data if the zone has any children.
+   Therefore, zone maintenance operations will require some additional
+   mechanisms (most likely some form of channel security, such as TSIG,
+   SIG(0), or IPsec).
+
+10.  DNS Security Document Family
+
+   The DNSSEC document set can be partitioned into several main groups,
+   under the larger umbrella of the DNS base protocol documents.
+
+   The "DNSSEC protocol document set" refers to the three documents that
+   form the core of the DNS security extensions:
+
+   1.  DNS Security Introduction and Requirements (this document)
+
+   2.  Resource Records for DNS Security Extensions [RFC4034]
+
+   3.  Protocol Modifications for the DNS Security Extensions [RFC4035]
+
+   Additionally, any document that would add to or change the core DNS
+   Security extensions would fall into this category.  This includes any
+   future work on the communication between security-aware stub
+   resolvers and upstream security-aware recursive name servers.
+
+   The "Digital Signature Algorithm Specification" document set refers
+   to the group of documents that describe how specific digital
+   signature algorithms should be implemented to fit the DNSSEC resource
+   record format.  Each document in this set deals with a specific
+   digital signature algorithm.  Please see the appendix on "DNSSEC
+   Algorithm and Digest Types" in [RFC4034] for a list of the algorithms
+   that were defined when this core specification was written.
+
+   The "Transaction Authentication Protocol" document set refers to the
+   group of documents that deal with DNS message authentication,
+   including secret key establishment and verification.  Although not
+
+
+
+Arends, et al.              Standards Track                    [Page 14]
+
+RFC 4033       DNS Security Introduction and Requirements     March 2005
+
+
+   strictly part of the DNSSEC specification as defined in this set of
+   documents, this group is noted because of its relationship to DNSSEC.
+
+   The final document set, "New Security Uses", refers to documents that
+   seek to use proposed DNS Security extensions for other security
+   related purposes.  DNSSEC does not provide any direct security for
+   these new uses but may be used to support them.  Documents that fall
+   in this category include those describing the use of DNS in the
+   storage and distribution of certificates ([RFC2538]).
+
+11.  IANA Considerations
+
+   This overview document introduces no new IANA considerations.  Please
+   see [RFC4034] for a complete review of the IANA considerations
+   introduced by DNSSEC.
+
+12.  Security Considerations
+
+   This document introduces DNS security extensions and describes the
+   document set that contains the new security records and DNS protocol
+   modifications.  The extensions provide data origin authentication and
+   data integrity using digital signatures over resource record sets.
+   This section discusses the limitations of these extensions.
+
+   In order for a security-aware resolver to validate a DNS response,
+   all zones along the path from the trusted starting point to the zone
+   containing the response zones must be signed, and all name servers
+   and resolvers involved in the resolution process must be
+   security-aware, as defined in this document set.  A security-aware
+   resolver cannot verify responses originating from an unsigned zone,
+   from a zone not served by a security-aware name server, or for any
+   DNS data that the resolver is only able to obtain through a recursive
+   name server that is not security-aware.  If there is a break in the
+   authentication chain such that a security-aware resolver cannot
+   obtain and validate the authentication keys it needs, then the
+   security-aware resolver cannot validate the affected DNS data.
+
+   This document briefly discusses other methods of adding security to a
+   DNS query, such as using a channel secured by IPsec or using a DNS
+   transaction authentication mechanism such as TSIG ([RFC2845]) or
+   SIG(0) ([RFC2931]), but transaction security is not part of DNSSEC
+   per se.
+
+   A non-validating security-aware stub resolver, by definition, does
+   not perform DNSSEC signature validation on its own and thus is
+   vulnerable both to attacks on (and by) the security-aware recursive
+   name servers that perform these checks on its behalf and to attacks
+   on its communication with those security-aware recursive name
+
+
+
+Arends, et al.              Standards Track                    [Page 15]
+
+RFC 4033       DNS Security Introduction and Requirements     March 2005
+
+
+   servers.  Non-validating security-aware stub resolvers should use
+   some form of channel security to defend against the latter threat.
+   The only known defense against the former threat would be for the
+   security-aware stub resolver to perform its own signature validation,
+   at which point, again by definition, it would no longer be a
+   non-validating security-aware stub resolver.
+
+   DNSSEC does not protect against denial of service attacks.  DNSSEC
+   makes DNS vulnerable to a new class of denial of service attacks
+   based on cryptographic operations against security-aware resolvers
+   and security-aware name servers, as an attacker can attempt to use
+   DNSSEC mechanisms to consume a victim's resources.  This class of
+   attacks takes at least two forms.  An attacker may be able to consume
+   resources in a security-aware resolver's signature validation code by
+   tampering with RRSIG RRs in response messages or by constructing
+   needlessly complex signature chains.  An attacker may also be able to
+   consume resources in a security-aware name server that supports DNS
+   dynamic update, by sending a stream of update messages that force the
+   security-aware name server to re-sign some RRsets in the zone more
+   frequently than would otherwise be necessary.
+
+   Due to a deliberate design choice, DNSSEC does not provide
+   confidentiality.
+
+   DNSSEC introduces the ability for a hostile party to enumerate all
+   the names in a zone by following the NSEC chain.  NSEC RRs assert
+   which names do not exist in a zone by linking from existing name to
+   existing name along a canonical ordering of all the names within a
+   zone.  Thus, an attacker can query these NSEC RRs in sequence to
+   obtain all the names in a zone.  Although this is not an attack on
+   the DNS itself, it could allow an attacker to map network hosts or
+   other resources by enumerating the contents of a zone.
+
+   DNSSEC introduces significant additional complexity to the DNS and
+   thus introduces many new opportunities for implementation bugs and
+   misconfigured zones.  In particular, enabling DNSSEC signature
+   validation in a resolver may cause entire legitimate zones to become
+   effectively unreachable due to DNSSEC configuration errors or bugs.
+
+   DNSSEC does not protect against tampering with unsigned zone data.
+   Non-authoritative data at zone cuts (glue and NS RRs in the parent
+   zone) are not signed.  This does not pose a problem when validating
+   the authentication chain, but it does mean that the non-authoritative
+   data itself is vulnerable to tampering during zone transfer
+   operations.  Thus, while DNSSEC can provide data origin
+   authentication and data integrity for RRsets, it cannot do so for
+   zones, and other mechanisms (such as TSIG, SIG(0), or IPsec) must be
+   used to protect zone transfer operations.
+
+
+
+Arends, et al.              Standards Track                    [Page 16]
+
+RFC 4033       DNS Security Introduction and Requirements     March 2005
+
+
+   Please see [RFC4034] and [RFC4035] for additional security
+   considerations.
+
+13.  Acknowledgements
+
+   This document was created from the input and ideas of the members of
+   the DNS Extensions Working Group.  Although explicitly listing
+   everyone who has contributed during the decade in which DNSSEC has
+   been under development would be impossible, the editors would
+   particularly like to thank the following people for their
+   contributions to and comments on this document set: Jaap Akkerhuis,
+   Mark Andrews, Derek Atkins, Roy Badami, Alan Barrett, Dan Bernstein,
+   David Blacka, Len Budney, Randy Bush, Francis Dupont, Donald
+   Eastlake, Robert Elz, Miek Gieben, Michael Graff, Olafur Gudmundsson,
+   Gilles Guette, Andreas Gustafsson, Jun-ichiro Itojun Hagino, Phillip
+   Hallam-Baker, Bob Halley, Ted Hardie, Walter Howard, Greg Hudson,
+   Christian Huitema, Johan Ihren, Stephen Jacob, Jelte Jansen, Simon
+   Josefsson, Andris Kalnozols, Peter Koch, Olaf Kolkman, Mark Kosters,
+   Suresh Krishnaswamy, Ben Laurie, David Lawrence, Ted Lemon, Ed Lewis,
+   Ted Lindgreen, Josh Littlefield, Rip Loomis, Bill Manning, Russ
+   Mundy, Thomas Narten, Mans Nilsson, Masataka Ohta, Mike Patton, Rob
+   Payne, Jim Reid, Michael Richardson, Erik Rozendaal, Marcos Sanz,
+   Pekka Savola, Jakob Schlyter, Mike StJohns, Paul Vixie, Sam Weiler,
+   Brian Wellington, and Suzanne Woolf.
+
+   No doubt the above list is incomplete.  We apologize to anyone we
+   left out.
+
+14.  References
+
+14.1.  Normative References
+
+   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
+              STD 13, RFC 1034, November 1987.
+
+   [RFC1035]  Mockapetris, P., "Domain names - implementation and
+              specification", STD 13, RFC 1035, November 1987.
+
+   [RFC2535]  Eastlake 3rd, D., "Domain Name System Security
+              Extensions", RFC 2535, March 1999.
+
+   [RFC2671]  Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
+              2671, August 1999.
+
+   [RFC3225]  Conrad, D., "Indicating Resolver Support of DNSSEC", RFC
+              3225, December 2001.
+
+
+
+
+
+Arends, et al.              Standards Track                    [Page 17]
+
+RFC 4033       DNS Security Introduction and Requirements     March 2005
+
+
+   [RFC3226]  Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver
+              message size requirements", RFC 3226, December 2001.
+
+   [RFC3445]  Massey, D. and S. Rose, "Limiting the Scope of the KEY
+              Resource Record (RR)", RFC 3445, December 2002.
+
+   [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
+              Rose, "Resource Records for DNS Security Extensions", RFC
+              4034, March 2005.
+
+   [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
+              Rose, "Protocol Modifications for the DNS Security
+              Extensions", RFC 4035, March 2005.
+
+14.2.  Informative References
+
+   [RFC2136]  Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
+              "Dynamic Updates in the Domain Name System (DNS UPDATE)",
+              RFC 2136, April 1997.
+
+   [RFC2181]  Elz, R. and R. Bush, "Clarifications to the DNS
+              Specification", RFC 2181, July 1997.
+
+   [RFC2308]  Andrews, M., "Negative Caching of DNS Queries (DNS
+              NCACHE)", RFC 2308, March 1998.
+
+   [RFC2538]  Eastlake 3rd, D. and O. Gudmundsson, "Storing Certificates
+              in the Domain Name System (DNS)", RFC 2538, March 1999.
+
+   [RFC2845]  Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
+              Wellington, "Secret Key Transaction Authentication for DNS
+              (TSIG)", RFC 2845, May 2000.
+
+   [RFC2931]  Eastlake 3rd, D., "DNS Request and Transaction Signatures
+              ( SIG(0)s )", RFC 2931, September 2000.
+
+   [RFC3007]  Wellington, B., "Secure Domain Name System (DNS) Dynamic
+              Update", RFC 3007, November 2000.
+
+   [RFC3008]  Wellington, B., "Domain Name System Security (DNSSEC)
+              Signing Authority", RFC 3008, November 2000.
+
+   [RFC3090]  Lewis, E., "DNS Security Extension Clarification on Zone
+              Status", RFC 3090, March 2001.
+
+   [RFC3597]  Gustafsson, A., "Handling of Unknown DNS Resource Record
+              (RR) Types", RFC 3597, September 2003.
+
+
+
+
+Arends, et al.              Standards Track                    [Page 18]
+
+RFC 4033       DNS Security Introduction and Requirements     March 2005
+
+
+   [RFC3655]  Wellington, B. and O. Gudmundsson, "Redefinition of DNS
+              Authenticated Data (AD) bit", RFC 3655, November 2003.
+
+   [RFC3658]  Gudmundsson, O., "Delegation Signer (DS) Resource Record
+              (RR)", RFC 3658, December 2003.
+
+   [RFC3755]  Weiler, S., "Legacy Resolver Compatibility for Delegation
+              Signer (DS)", RFC 3755, May 2004.
+
+   [RFC3757]  Kolkman, O., Schlyter, J., and E. Lewis, "Domain Name
+              System KEY (DNSKEY) Resource Record (RR) Secure Entry
+              Point (SEP) Flag", RFC 3757, April 2004.
+
+   [RFC3833]  Atkins, D. and R. Austein, "Threat Analysis of the Domain
+              Name System (DNS)", RFC 3833, August 2004.
+
+   [RFC3845]  Schlyter, J., "DNS Security (DNSSEC) NextSECure (NSEC)
+              RDATA Format", RFC 3845, August 2004.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al.              Standards Track                    [Page 19]
+
+RFC 4033       DNS Security Introduction and Requirements     March 2005
+
+
+Authors' Addresses
+
+   Roy Arends
+   Telematica Instituut
+   Brouwerijstraat 1
+   7523 XC  Enschede
+   NL
+
+   EMail: roy.arends@telin.nl
+
+
+   Rob Austein
+   Internet Systems Consortium
+   950 Charter Street
+   Redwood City, CA  94063
+   USA
+
+   EMail: sra@isc.org
+
+
+   Matt Larson
+   VeriSign, Inc.
+   21345 Ridgetop Circle
+   Dulles, VA  20166-6503
+   USA
+
+   EMail: mlarson@verisign.com
+
+
+   Dan Massey
+   Colorado State University
+   Department of Computer Science
+   Fort Collins, CO 80523-1873
+
+   EMail: massey@cs.colostate.edu
+
+
+   Scott Rose
+   National Institute for Standards and Technology
+   100 Bureau Drive
+   Gaithersburg, MD  20899-8920
+   USA
+
+   EMail: scott.rose@nist.gov
+
+
+
+
+
+
+
+Arends, et al.              Standards Track                    [Page 20]
+
+RFC 4033       DNS Security Introduction and Requirements     March 2005
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2005).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at ietf-
+   ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+Arends, et al.              Standards Track                    [Page 21]
+
diff --git a/doc/rfc/rfc4034.txt b/doc/rfc/rfc4034.txt
new file mode 100644
index 0000000..6a12c6b
--- /dev/null
+++ b/doc/rfc/rfc4034.txt
@@ -0,0 +1,1627 @@
+
+
+
+
+
+
+Network Working Group                                          R. Arends
+Request for Comments: 4034                          Telematica Instituut
+Obsoletes: 2535, 3008, 3090, 3445, 3655, 3658,                R. Austein
+           3755, 3757, 3845                                          ISC
+Updates: 1034, 1035, 2136, 2181, 2308, 3225,                   M. Larson
+         3007, 3597, 3226                                       VeriSign
+Category: Standards Track                                      D. Massey
+                                               Colorado State University
+                                                                 S. Rose
+                                                                    NIST
+                                                              March 2005
+
+
+            Resource Records for the DNS Security Extensions
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   This document is part of a family of documents that describe the DNS
+   Security Extensions (DNSSEC).  The DNS Security Extensions are a
+   collection of resource records and protocol modifications that
+   provide source authentication for the DNS.  This document defines the
+   public key (DNSKEY), delegation signer (DS), resource record digital
+   signature (RRSIG), and authenticated denial of existence (NSEC)
+   resource records.  The purpose and format of each resource record is
+   described in detail, and an example of each resource record is given.
+
+   This document obsoletes RFC 2535 and incorporates changes from all
+   updates to RFC 2535.
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al.              Standards Track                     [Page 1]
+
+RFC 4034                DNSSEC Resource Records               March 2005
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . .  3
+       1.1.  Background and Related Documents . . . . . . . . . . .  3
+       1.2.  Reserved Words . . . . . . . . . . . . . . . . . . . .  3
+   2.  The DNSKEY Resource Record . . . . . . . . . . . . . . . . .  4
+       2.1.  DNSKEY RDATA Wire Format . . . . . . . . . . . . . . .  4
+             2.1.1.  The Flags Field. . . . . . . . . . . . . . . .  4
+             2.1.2.  The Protocol Field . . . . . . . . . . . . . .  5
+             2.1.3.  The Algorithm Field. . . . . . . . . . . . . .  5
+             2.1.4.  The Public Key Field . . . . . . . . . . . . .  5
+             2.1.5.  Notes on DNSKEY RDATA Design . . . . . . . . .  5
+       2.2.  The DNSKEY RR Presentation Format. . . . . . . . . . .  5
+       2.3.  DNSKEY RR Example  . . . . . . . . . . . . . . . . . .  6
+   3.  The RRSIG Resource Record  . . . . . . . . . . . . . . . . .  6
+       3.1.  RRSIG RDATA Wire Format. . . . . . . . . . . . . . . .  7
+             3.1.1.  The Type Covered Field . . . . . . . . . . . .  7
+             3.1.2.  The Algorithm Number Field . . . . . . . . . .  8
+             3.1.3.  The Labels Field . . . . . . . . . . . . . . .  8
+             3.1.4.  Original TTL Field . . . . . . . . . . . . . .  8
+             3.1.5.  Signature Expiration and Inception Fields. . .  9
+             3.1.6.  The Key Tag Field. . . . . . . . . . . . . . .  9
+             3.1.7.  The Signer's Name Field. . . . . . . . . . . .  9
+             3.1.8.  The Signature Field. . . . . . . . . . . . . .  9
+       3.2.  The RRSIG RR Presentation Format . . . . . . . . . . . 10
+       3.3.  RRSIG RR Example . . . . . . . . . . . . . . . . . . . 11
+   4.  The NSEC Resource Record . . . . . . . . . . . . . . . . . . 12
+       4.1.  NSEC RDATA Wire Format . . . . . . . . . . . . . . . . 13
+             4.1.1.  The Next Domain Name Field . . . . . . . . . . 13
+             4.1.2.  The Type Bit Maps Field. . . . . . . . . . . . 13
+             4.1.3.  Inclusion of Wildcard Names in NSEC RDATA. . . 14
+       4.2.  The NSEC RR Presentation Format. . . . . . . . . . . . 14
+       4.3.  NSEC RR Example. . . . . . . . . . . . . . . . . . . . 15
+   5.  The DS Resource Record . . . . . . . . . . . . . . . . . . . 15
+       5.1.  DS RDATA Wire Format . . . . . . . . . . . . . . . . . 16
+             5.1.1.  The Key Tag Field. . . . . . . . . . . . . . . 16
+             5.1.2.  The Algorithm Field. . . . . . . . . . . . . . 16
+             5.1.3.  The Digest Type Field. . . . . . . . . . . . . 17
+             5.1.4.  The Digest Field . . . . . . . . . . . . . . . 17
+       5.2.  Processing of DS RRs When Validating Responses . . . . 17
+       5.3.  The DS RR Presentation Format. . . . . . . . . . . . . 17
+       5.4.  DS RR Example. . . . . . . . . . . . . . . . . . . . . 18
+   6.  Canonical Form and Order of Resource Records . . . . . . . . 18
+       6.1.  Canonical DNS Name Order . . . . . . . . . . . . . . . 18
+       6.2.  Canonical RR Form. . . . . . . . . . . . . . . . . . . 19
+       6.3.  Canonical RR Ordering within an RRset. . . . . . . . . 20
+   7.  IANA Considerations. . . . . . . . . . . . . . . . . . . . . 20
+   8.  Security Considerations. . . . . . . . . . . . . . . . . . . 21
+
+
+
+Arends, et al.              Standards Track                     [Page 2]
+
+RFC 4034                DNSSEC Resource Records               March 2005
+
+
+   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
+   10. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
+       10.1. Normative References . . . . . . . . . . . . . . . . . 22
+       10.2. Informative References . . . . . . . . . . . . . . . . 23
+   A.  DNSSEC Algorithm and Digest Types. . . . . . . . . . . . . . 24
+       A.1.  DNSSEC Algorithm Types . . . . . . . . . . . . . . . . 24
+             A.1.1.  Private Algorithm Types. . . . . . . . . . . . 25
+       A.2.  DNSSEC Digest Types. . . . . . . . . . . . . . . . . . 25
+   B.  Key Tag Calculation. . . . . . . . . . . . . . . . . . . . . 25
+       B.1.  Key Tag for Algorithm 1 (RSA/MD5). . . . . . . . . . . 27
+   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
+   Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 29
+
+1.  Introduction
+
+   The DNS Security Extensions (DNSSEC) introduce four new DNS resource
+   record types: DNS Public Key (DNSKEY), Resource Record Signature
+   (RRSIG), Next Secure (NSEC), and Delegation Signer (DS).  This
+   document defines the purpose of each resource record (RR), the RR's
+   RDATA format, and its presentation format (ASCII representation).
+
+1.1.  Background and Related Documents
+
+   This document is part of a family of documents defining DNSSEC, which
+   should be read together as a set.
+
+   [RFC4033] contains an introduction to DNSSEC and definition of common
+   terms; the reader is assumed to be familiar with this document.
+   [RFC4033] also contains a list of other documents updated by and
+   obsoleted by this document set.
+
+   [RFC4035] defines the DNSSEC protocol operations.
+
+   The reader is also assumed to be familiar with the basic DNS concepts
+   described in [RFC1034], [RFC1035], and the subsequent documents that
+   update them, particularly [RFC2181] and [RFC2308].
+
+   This document defines the DNSSEC resource records.  All numeric DNS
+   type codes given in this document are decimal integers.
+
+1.2.  Reserved Words
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+
+
+
+
+
+Arends, et al.              Standards Track                     [Page 3]
+
+RFC 4034                DNSSEC Resource Records               March 2005
+
+
+2.  The DNSKEY Resource Record
+
+   DNSSEC uses public key cryptography to sign and authenticate DNS
+   resource record sets (RRsets).  The public keys are stored in DNSKEY
+   resource records and are used in the DNSSEC authentication process
+   described in [RFC4035]: A zone signs its authoritative RRsets by
+   using a private key and stores the corresponding public key in a
+   DNSKEY RR.  A resolver can then use the public key to validate
+   signatures covering the RRsets in the zone, and thus to authenticate
+   them.
+
+   The DNSKEY RR is not intended as a record for storing arbitrary
+   public keys and MUST NOT be used to store certificates or public keys
+   that do not directly relate to the DNS infrastructure.
+
+   The Type value for the DNSKEY RR type is 48.
+
+   The DNSKEY RR is class independent.
+
+   The DNSKEY RR has no special TTL requirements.
+
+2.1.  DNSKEY RDATA Wire Format
+
+   The RDATA for a DNSKEY RR consists of a 2 octet Flags Field, a 1
+   octet Protocol Field, a 1 octet Algorithm Field, and the Public Key
+   Field.
+
+                        1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |              Flags            |    Protocol   |   Algorithm   |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   /                                                               /
+   /                            Public Key                         /
+   /                                                               /
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+2.1.1.  The Flags Field
+
+   Bit 7 of the Flags field is the Zone Key flag.  If bit 7 has value 1,
+   then the DNSKEY record holds a DNS zone key, and the DNSKEY RR's
+   owner name MUST be the name of a zone.  If bit 7 has value 0, then
+   the DNSKEY record holds some other type of DNS public key and MUST
+   NOT be used to verify RRSIGs that cover RRsets.
+
+   Bit 15 of the Flags field is the Secure Entry Point flag, described
+   in [RFC3757].  If bit 15 has value 1, then the DNSKEY record holds a
+   key intended for use as a secure entry point.  This flag is only
+
+
+
+Arends, et al.              Standards Track                     [Page 4]
+
+RFC 4034                DNSSEC Resource Records               March 2005
+
+
+   intended to be a hint to zone signing or debugging software as to the
+   intended use of this DNSKEY record; validators MUST NOT alter their
+   behavior during the signature validation process in any way based on
+   the setting of this bit.  This also means that a DNSKEY RR with the
+   SEP bit set would also need the Zone Key flag set in order to be able
+   to generate signatures legally.  A DNSKEY RR with the SEP set and the
+   Zone Key flag not set MUST NOT be used to verify RRSIGs that cover
+   RRsets.
+
+   Bits 0-6 and 8-14 are reserved: these bits MUST have value 0 upon
+   creation of the DNSKEY RR and MUST be ignored upon receipt.
+
+2.1.2.  The Protocol Field
+
+   The Protocol Field MUST have value 3, and the DNSKEY RR MUST be
+   treated as invalid during signature verification if it is found to be
+   some value other than 3.
+
+2.1.3.  The Algorithm Field
+
+   The Algorithm field identifies the public key's cryptographic
+   algorithm and determines the format of the Public Key field.  A list
+   of DNSSEC algorithm types can be found in Appendix A.1
+
+2.1.4.  The Public Key Field
+
+   The Public Key Field holds the public key material.  The format
+   depends on the algorithm of the key being stored and is described in
+   separate documents.
+
+2.1.5.  Notes on DNSKEY RDATA Design
+
+   Although the Protocol Field always has value 3, it is retained for
+   backward compatibility with early versions of the KEY record.
+
+2.2.  The DNSKEY RR Presentation Format
+
+   The presentation format of the RDATA portion is as follows:
+
+   The Flag field MUST be represented as an unsigned decimal integer.
+   Given the currently defined flags, the possible values are: 0, 256,
+   and 257.
+
+   The Protocol Field MUST be represented as an unsigned decimal integer
+   with a value of 3.
+
+   The Algorithm field MUST be represented either as an unsigned decimal
+   integer or as an algorithm mnemonic as specified in Appendix A.1.
+
+
+
+Arends, et al.              Standards Track                     [Page 5]
+
+RFC 4034                DNSSEC Resource Records               March 2005
+
+
+   The Public Key field MUST be represented as a Base64 encoding of the
+   Public Key.  Whitespace is allowed within the Base64 text.  For a
+   definition of Base64 encoding, see [RFC3548].
+
+2.3.  DNSKEY RR Example
+
+   The following DNSKEY RR stores a DNS zone key for example.com.
+
+   example.com. 86400 IN DNSKEY 256 3 5 ( AQPSKmynfzW4kyBv015MUG2DeIQ3
+                                          Cbl+BBZH4b/0PY1kxkmvHjcZc8no
+                                          kfzj31GajIQKY+5CptLr3buXA10h
+                                          WqTkF7H6RfoRqXQeogmMHfpftf6z
+                                          Mv1LyBUgia7za6ZEzOJBOztyvhjL
+                                          742iU/TpPSEDhm2SNKLijfUppn1U
+                                          aNvv4w==  )
+
+   The first four text fields specify the owner name, TTL, Class, and RR
+   type (DNSKEY).  Value 256 indicates that the Zone Key bit (bit 7) in
+   the Flags field has value 1.  Value 3 is the fixed Protocol value.
+   Value 5 indicates the public key algorithm.  Appendix A.1 identifies
+   algorithm type 5 as RSA/SHA1 and indicates that the format of the
+   RSA/SHA1 public key field is defined in [RFC3110].  The remaining
+   text is a Base64 encoding of the public key.
+
+3.  The RRSIG Resource Record
+
+   DNSSEC uses public key cryptography to sign and authenticate DNS
+   resource record sets (RRsets).  Digital signatures are stored in
+   RRSIG resource records and are used in the DNSSEC authentication
+   process described in [RFC4035].  A validator can use these RRSIG RRs
+   to authenticate RRsets from the zone.  The RRSIG RR MUST only be used
+   to carry verification material (digital signatures) used to secure
+   DNS operations.
+
+   An RRSIG record contains the signature for an RRset with a particular
+   name, class, and type.  The RRSIG RR specifies a validity interval
+   for the signature and uses the Algorithm, the Signer's Name, and the
+   Key Tag to identify the DNSKEY RR containing the public key that a
+   validator can use to verify the signature.
+
+   Because every authoritative RRset in a zone must be protected by a
+   digital signature, RRSIG RRs must be present for names containing a
+   CNAME RR.  This is a change to the traditional DNS specification
+   [RFC1034], which stated that if a CNAME is present for a name, it is
+   the only type allowed at that name.  A RRSIG and NSEC (see Section 4)
+   MUST exist for the same name as a CNAME resource record in a signed
+   zone.
+
+
+
+
+Arends, et al.              Standards Track                     [Page 6]
+
+RFC 4034                DNSSEC Resource Records               March 2005
+
+
+   The Type value for the RRSIG RR type is 46.
+
+   The RRSIG RR is class independent.
+
+   An RRSIG RR MUST have the same class as the RRset it covers.
+
+   The TTL value of an RRSIG RR MUST match the TTL value of the RRset it
+   covers.  This is an exception to the [RFC2181] rules for TTL values
+   of individual RRs within a RRset: individual RRSIG RRs with the same
+   owner name will have different TTL values if the RRsets they cover
+   have different TTL values.
+
+3.1.  RRSIG RDATA Wire Format
+
+   The RDATA for an RRSIG RR consists of a 2 octet Type Covered field, a
+   1 octet Algorithm field, a 1 octet Labels field, a 4 octet Original
+   TTL field, a 4 octet Signature Expiration field, a 4 octet Signature
+   Inception field, a 2 octet Key tag, the Signer's Name field, and the
+   Signature field.
+
+                        1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |        Type Covered           |  Algorithm    |     Labels    |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                         Original TTL                          |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                      Signature Expiration                     |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                      Signature Inception                      |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |            Key Tag            |                               /
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+         Signer's Name         /
+   /                                                               /
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   /                                                               /
+   /                            Signature                          /
+   /                                                               /
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+3.1.1.  The Type Covered Field
+
+   The Type Covered field identifies the type of the RRset that is
+   covered by this RRSIG record.
+
+
+
+
+
+
+
+Arends, et al.              Standards Track                     [Page 7]
+
+RFC 4034                DNSSEC Resource Records               March 2005
+
+
+3.1.2.  The Algorithm Number Field
+
+   The Algorithm Number field identifies the cryptographic algorithm
+   used to create the signature.  A list of DNSSEC algorithm types can
+   be found in Appendix A.1
+
+3.1.3.  The Labels Field
+
+   The Labels field specifies the number of labels in the original RRSIG
+   RR owner name.  The significance of this field is that a validator
+   uses it to determine whether the answer was synthesized from a
+   wildcard.  If so, it can be used to determine what owner name was
+   used in generating the signature.
+
+   To validate a signature, the validator needs the original owner name
+   that was used to create the signature.  If the original owner name
+   contains a wildcard label ("*"), the owner name may have been
+   expanded by the server during the response process, in which case the
+   validator will have to reconstruct the original owner name in order
+   to validate the signature.  [RFC4035] describes how to use the Labels
+   field to reconstruct the original owner name.
+
+   The value of the Labels field MUST NOT count either the null (root)
+   label that terminates the owner name or the wildcard label (if
+   present).  The value of the Labels field MUST be less than or equal
+   to the number of labels in the RRSIG owner name.  For example,
+   "www.example.com." has a Labels field value of 3, and
+   "*.example.com." has a Labels field value of 2.  Root (".") has a
+   Labels field value of 0.
+
+   Although the wildcard label is not included in the count stored in
+   the Labels field of the RRSIG RR, the wildcard label is part of the
+   RRset's owner name when the signature is generated or verified.
+
+3.1.4.  Original TTL Field
+
+   The Original TTL field specifies the TTL of the covered RRset as it
+   appears in the authoritative zone.
+
+   The Original TTL field is necessary because a caching resolver
+   decrements the TTL value of a cached RRset.  In order to validate a
+   signature, a validator requires the original TTL.  [RFC4035]
+   describes how to use the Original TTL field value to reconstruct the
+   original TTL.
+
+
+
+
+
+
+
+Arends, et al.              Standards Track                     [Page 8]
+
+RFC 4034                DNSSEC Resource Records               March 2005
+
+
+3.1.5.  Signature Expiration and Inception Fields
+
+   The Signature Expiration and Inception fields specify a validity
+   period for the signature.  The RRSIG record MUST NOT be used for
+   authentication prior to the inception date and MUST NOT be used for
+   authentication after the expiration date.
+
+   The Signature Expiration and Inception field values specify a date
+   and time in the form of a 32-bit unsigned number of seconds elapsed
+   since 1 January 1970 00:00:00 UTC, ignoring leap seconds, in network
+   byte order.  The longest interval that can be expressed by this
+   format without wrapping is approximately 136 years.  An RRSIG RR can
+   have an Expiration field value that is numerically smaller than the
+   Inception field value if the expiration field value is near the
+   32-bit wrap-around point or if the signature is long lived.  Because
+   of this, all comparisons involving these fields MUST use "Serial
+   number arithmetic", as defined in [RFC1982].  As a direct
+   consequence, the values contained in these fields cannot refer to
+   dates more than 68 years in either the past or the future.
+
+3.1.6.  The Key Tag Field
+
+   The Key Tag field contains the key tag value of the DNSKEY RR that
+   validates this signature, in network byte order.  Appendix B explains
+   how to calculate Key Tag values.
+
+3.1.7.  The Signer's Name Field
+
+   The Signer's Name field value identifies the owner name of the DNSKEY
+   RR that a validator is supposed to use to validate this signature.
+   The Signer's Name field MUST contain the name of the zone of the
+   covered RRset.  A sender MUST NOT use DNS name compression on the
+   Signer's Name field when transmitting a RRSIG RR.
+
+3.1.8.  The Signature Field
+
+   The Signature field contains the cryptographic signature that covers
+   the RRSIG RDATA (excluding the Signature field) and the RRset
+   specified by the RRSIG owner name, RRSIG class, and RRSIG Type
+   Covered field.  The format of this field depends on the algorithm in
+   use, and these formats are described in separate companion documents.
+
+3.1.8.1.  Signature Calculation
+
+   A signature covers the RRSIG RDATA (excluding the Signature Field)
+   and covers the data RRset specified by the RRSIG owner name, RRSIG
+   class, and RRSIG Type Covered fields.  The RRset is in canonical form
+   (see Section 6), and the set RR(1),...RR(n) is signed as follows:
+
+
+
+Arends, et al.              Standards Track                     [Page 9]
+
+RFC 4034                DNSSEC Resource Records               March 2005
+
+
+         signature = sign(RRSIG_RDATA | RR(1) | RR(2)... ) where
+
+            "|" denotes concatenation;
+
+            RRSIG_RDATA is the wire format of the RRSIG RDATA fields
+               with the Signer's Name field in canonical form and
+               the Signature field excluded;
+
+            RR(i) = owner | type | class | TTL | RDATA length | RDATA
+
+               "owner" is the fully qualified owner name of the RRset in
+               canonical form (for RRs with wildcard owner names, the
+               wildcard label is included in the owner name);
+
+               Each RR MUST have the same owner name as the RRSIG RR;
+
+               Each RR MUST have the same class as the RRSIG RR;
+
+               Each RR in the RRset MUST have the RR type listed in the
+               RRSIG RR's Type Covered field;
+
+               Each RR in the RRset MUST have the TTL listed in the
+               RRSIG Original TTL Field;
+
+               Any DNS names in the RDATA field of each RR MUST be in
+               canonical form; and
+
+               The RRset MUST be sorted in canonical order.
+
+   See Sections 6.2 and 6.3 for details on canonical form and ordering
+   of RRsets.
+
+3.2.  The RRSIG RR Presentation Format
+
+   The presentation format of the RDATA portion is as follows:
+
+   The Type Covered field is represented as an RR type mnemonic.  When
+   the mnemonic is not known, the TYPE representation as described in
+   [RFC3597], Section 5, MUST be used.
+
+   The Algorithm field value MUST be represented either as an unsigned
+   decimal integer or as an algorithm mnemonic, as specified in Appendix
+   A.1.
+
+   The Labels field value MUST be represented as an unsigned decimal
+   integer.
+
+
+
+
+
+Arends, et al.              Standards Track                    [Page 10]
+
+RFC 4034                DNSSEC Resource Records               March 2005
+
+
+   The Original TTL field value MUST be represented as an unsigned
+   decimal integer.
+
+   The Signature Expiration Time and Inception Time field values MUST be
+   represented either as an unsigned decimal integer indicating seconds
+   since 1 January 1970 00:00:00 UTC, or in the form YYYYMMDDHHmmSS in
+   UTC, where:
+
+      YYYY is the year (0001-9999, but see Section 3.1.5);
+      MM is the month number (01-12);
+      DD is the day of the month (01-31);
+      HH is the hour, in 24 hour notation (00-23);
+      mm is the minute (00-59); and
+      SS is the second (00-59).
+
+   Note that it is always possible to distinguish between these two
+   formats because the YYYYMMDDHHmmSS format will always be exactly 14
+   digits, while the decimal representation of a 32-bit unsigned integer
+   can never be longer than 10 digits.
+
+   The Key Tag field MUST be represented as an unsigned decimal integer.
+
+   The Signer's Name field value MUST be represented as a domain name.
+
+   The Signature field is represented as a Base64 encoding of the
+   signature.  Whitespace is allowed within the Base64 text.  See
+   Section 2.2.
+
+3.3.  RRSIG RR Example
+
+   The following RRSIG RR stores the signature for the A RRset of
+   host.example.com:
+
+   host.example.com. 86400 IN RRSIG A 5 3 86400 20030322173103 (
+                                  20030220173103 2642 example.com.
+                                  oJB1W6WNGv+ldvQ3WDG0MQkg5IEhjRip8WTr
+                                  PYGv07h108dUKGMeDPKijVCHX3DDKdfb+v6o
+                                  B9wfuh3DTJXUAfI/M0zmO/zz8bW0Rznl8O3t
+                                  GNazPwQKkRN20XPXV6nwwfoXmJQbsLNrLfkG
+                                  J5D6fwFm8nN+6pBzeDQfsS3Ap3o= )
+
+   The first four fields specify the owner name, TTL, Class, and RR type
+   (RRSIG).  The "A" represents the Type Covered field.  The value 5
+   identifies the algorithm used (RSA/SHA1) to create the signature.
+   The value 3 is the number of Labels in the original owner name.  The
+   value 86400 in the RRSIG RDATA is the Original TTL for the covered A
+   RRset.  20030322173103 and 20030220173103 are the expiration and
+
+
+
+
+Arends, et al.              Standards Track                    [Page 11]
+
+RFC 4034                DNSSEC Resource Records               March 2005
+
+
+   inception dates, respectively.  2642 is the Key Tag, and example.com.
+   is the Signer's Name.  The remaining text is a Base64 encoding of the
+   signature.
+
+   Note that combination of RRSIG RR owner name, class, and Type Covered
+   indicates that this RRSIG covers the "host.example.com" A RRset.  The
+   Label value of 3 indicates that no wildcard expansion was used.  The
+   Algorithm, Signer's Name, and Key Tag indicate that this signature
+   can be authenticated using an example.com zone DNSKEY RR whose
+   algorithm is 5 and whose key tag is 2642.
+
+4.  The NSEC Resource Record
+
+   The NSEC resource record lists two separate things: the next owner
+   name (in the canonical ordering of the zone) that contains
+   authoritative data or a delegation point NS RRset, and the set of RR
+   types present at the NSEC RR's owner name [RFC3845].  The complete
+   set of NSEC RRs in a zone indicates which authoritative RRsets exist
+   in a zone and also form a chain of authoritative owner names in the
+   zone.  This information is used to provide authenticated denial of
+   existence for DNS data, as described in [RFC4035].
+
+   Because every authoritative name in a zone must be part of the NSEC
+   chain, NSEC RRs must be present for names containing a CNAME RR.
+   This is a change to the traditional DNS specification [RFC1034],
+   which stated that if a CNAME is present for a name, it is the only
+   type allowed at that name.  An RRSIG (see Section 3) and NSEC MUST
+   exist for the same name as does a CNAME resource record in a signed
+   zone.
+
+   See [RFC4035] for discussion of how a zone signer determines
+   precisely which NSEC RRs it has to include in a zone.
+
+   The type value for the NSEC RR is 47.
+
+   The NSEC RR is class independent.
+
+   The NSEC RR SHOULD have the same TTL value as the SOA minimum TTL
+   field.  This is in the spirit of negative caching ([RFC2308]).
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al.              Standards Track                    [Page 12]
+
+RFC 4034                DNSSEC Resource Records               March 2005
+
+
+4.1.  NSEC RDATA Wire Format
+
+   The RDATA of the NSEC RR is as shown below:
+
+                        1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   /                      Next Domain Name                         /
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   /                       Type Bit Maps                           /
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+4.1.1.  The Next Domain Name Field
+
+   The Next Domain field contains the next owner name (in the canonical
+   ordering of the zone) that has authoritative data or contains a
+   delegation point NS RRset; see Section 6.1 for an explanation of
+   canonical ordering.  The value of the Next Domain Name field in the
+   last NSEC record in the zone is the name of the zone apex (the owner
+   name of the zone's SOA RR).  This indicates that the owner name of
+   the NSEC RR is the last name in the canonical ordering of the zone.
+
+   A sender MUST NOT use DNS name compression on the Next Domain Name
+   field when transmitting an NSEC RR.
+
+   Owner names of RRsets for which the given zone is not authoritative
+   (such as glue records) MUST NOT be listed in the Next Domain Name
+   unless at least one authoritative RRset exists at the same owner
+   name.
+
+4.1.2.  The Type Bit Maps Field
+
+   The Type Bit Maps field identifies the RRset types that exist at the
+   NSEC RR's owner name.
+
+   The RR type space is split into 256 window blocks, each representing
+   the low-order 8 bits of the 16-bit RR type space.  Each block that
+   has at least one active RR type is encoded using a single octet
+   window number (from 0 to 255), a single octet bitmap length (from 1
+   to 32) indicating the number of octets used for the window block's
+   bitmap, and up to 32 octets (256 bits) of bitmap.
+
+   Blocks are present in the NSEC RR RDATA in increasing numerical
+   order.
+
+      Type Bit Maps Field = ( Window Block # | Bitmap Length | Bitmap )+
+
+      where "|" denotes concatenation.
+
+
+
+Arends, et al.              Standards Track                    [Page 13]
+
+RFC 4034                DNSSEC Resource Records               March 2005
+
+
+   Each bitmap encodes the low-order 8 bits of RR types within the
+   window block, in network bit order.  The first bit is bit 0.  For
+   window block 0, bit 1 corresponds to RR type 1 (A), bit 2 corresponds
+   to RR type 2 (NS), and so forth.  For window block 1, bit 1
+   corresponds to RR type 257, and bit 2 to RR type 258.  If a bit is
+   set, it indicates that an RRset of that type is present for the NSEC
+   RR's owner name.  If a bit is clear, it indicates that no RRset of
+   that type is present for the NSEC RR's owner name.
+
+   Bits representing pseudo-types MUST be clear, as they do not appear
+   in zone data.  If encountered, they MUST be ignored upon being read.
+
+   Blocks with no types present MUST NOT be included.  Trailing zero
+   octets in the bitmap MUST be omitted.  The length of each block's
+   bitmap is determined by the type code with the largest numerical
+   value, within that block, among the set of RR types present at the
+   NSEC RR's owner name.  Trailing zero octets not specified MUST be
+   interpreted as zero octets.
+
+   The bitmap for the NSEC RR at a delegation point requires special
+   attention.  Bits corresponding to the delegation NS RRset and the RR
+   types for which the parent zone has authoritative data MUST be set;
+   bits corresponding to any non-NS RRset for which the parent is not
+   authoritative MUST be clear.
+
+   A zone MUST NOT include an NSEC RR for any domain name that only
+   holds glue records.
+
+4.1.3.  Inclusion of Wildcard Names in NSEC RDATA
+
+   If a wildcard owner name appears in a zone, the wildcard label ("*")
+   is treated as a literal symbol and is treated the same as any other
+   owner name for the purposes of generating NSEC RRs.  Wildcard owner
+   names appear in the Next Domain Name field without any wildcard
+   expansion.  [RFC4035] describes the impact of wildcards on
+   authenticated denial of existence.
+
+4.2.  The NSEC RR Presentation Format
+
+   The presentation format of the RDATA portion is as follows:
+
+   The Next Domain Name field is represented as a domain name.
+
+   The Type Bit Maps field is represented as a sequence of RR type
+   mnemonics.  When the mnemonic is not known, the TYPE representation
+   described in [RFC3597], Section 5, MUST be used.
+
+
+
+
+
+Arends, et al.              Standards Track                    [Page 14]
+
+RFC 4034                DNSSEC Resource Records               March 2005
+
+
+4.3.  NSEC RR Example
+
+   The following NSEC RR identifies the RRsets associated with
+   alfa.example.com. and identifies the next authoritative name after
+   alfa.example.com.
+
+   alfa.example.com. 86400 IN NSEC host.example.com. (
+                                   A MX RRSIG NSEC TYPE1234 )
+
+   The first four text fields specify the name, TTL, Class, and RR type
+   (NSEC).  The entry host.example.com. is the next authoritative name
+   after alfa.example.com. in canonical order.  The A, MX, RRSIG, NSEC,
+   and TYPE1234 mnemonics indicate that there are A, MX, RRSIG, NSEC,
+   and TYPE1234 RRsets associated with the name alfa.example.com.
+
+   The RDATA section of the NSEC RR above would be encoded as:
+
+            0x04 'h'  'o'  's'  't'
+            0x07 'e'  'x'  'a'  'm'  'p'  'l'  'e'
+            0x03 'c'  'o'  'm'  0x00
+            0x00 0x06 0x40 0x01 0x00 0x00 0x00 0x03
+            0x04 0x1b 0x00 0x00 0x00 0x00 0x00 0x00
+            0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
+            0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
+            0x00 0x00 0x00 0x00 0x20
+
+   Assuming that the validator can authenticate this NSEC record, it
+   could be used to prove that beta.example.com does not exist, or to
+   prove that there is no AAAA record associated with alfa.example.com.
+   Authenticated denial of existence is discussed in [RFC4035].
+
+5.  The DS Resource Record
+
+   The DS Resource Record refers to a DNSKEY RR and is used in the DNS
+   DNSKEY authentication process.  A DS RR refers to a DNSKEY RR by
+   storing the key tag, algorithm number, and a digest of the DNSKEY RR.
+   Note that while the digest should be sufficient to identify the
+   public key, storing the key tag and key algorithm helps make the
+   identification process more efficient.  By authenticating the DS
+   record, a resolver can authenticate the DNSKEY RR to which the DS
+   record points.  The key authentication process is described in
+   [RFC4035].
+
+   The DS RR and its corresponding DNSKEY RR have the same owner name,
+   but they are stored in different locations.  The DS RR appears only
+   on the upper (parental) side of a delegation, and is authoritative
+   data in the parent zone.  For example, the DS RR for "example.com" is
+   stored in the "com" zone (the parent zone) rather than in the
+
+
+
+Arends, et al.              Standards Track                    [Page 15]
+
+RFC 4034                DNSSEC Resource Records               March 2005
+
+
+   "example.com" zone (the child zone).  The corresponding DNSKEY RR is
+   stored in the "example.com" zone (the child zone).  This simplifies
+   DNS zone management and zone signing but introduces special response
+   processing requirements for the DS RR; these are described in
+   [RFC4035].
+
+   The type number for the DS record is 43.
+
+   The DS resource record is class independent.
+
+   The DS RR has no special TTL requirements.
+
+5.1.  DS RDATA Wire Format
+
+   The RDATA for a DS RR consists of a 2 octet Key Tag field, a 1 octet
+   Algorithm field, a 1 octet Digest Type field, and a Digest field.
+
+                        1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |           Key Tag             |  Algorithm    |  Digest Type  |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   /                                                               /
+   /                            Digest                             /
+   /                                                               /
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+5.1.1.  The Key Tag Field
+
+   The Key Tag field lists the key tag of the DNSKEY RR referred to by
+   the DS record, in network byte order.
+
+   The Key Tag used by the DS RR is identical to the Key Tag used by
+   RRSIG RRs.  Appendix B describes how to compute a Key Tag.
+
+5.1.2.  The Algorithm Field
+
+   The Algorithm field lists the algorithm number of the DNSKEY RR
+   referred to by the DS record.
+
+   The algorithm number used by the DS RR is identical to the algorithm
+   number used by RRSIG and DNSKEY RRs.  Appendix A.1 lists the
+   algorithm number types.
+
+
+
+
+
+
+
+
+Arends, et al.              Standards Track                    [Page 16]
+
+RFC 4034                DNSSEC Resource Records               March 2005
+
+
+5.1.3.  The Digest Type Field
+
+   The DS RR refers to a DNSKEY RR by including a digest of that DNSKEY
+   RR.  The Digest Type field identifies the algorithm used to construct
+   the digest.  Appendix A.2 lists the possible digest algorithm types.
+
+5.1.4.  The Digest Field
+
+   The DS record refers to a DNSKEY RR by including a digest of that
+   DNSKEY RR.
+
+   The digest is calculated by concatenating the canonical form of the
+   fully qualified owner name of the DNSKEY RR with the DNSKEY RDATA,
+   and then applying the digest algorithm.
+
+     digest = digest_algorithm( DNSKEY owner name | DNSKEY RDATA);
+
+      "|" denotes concatenation
+
+     DNSKEY RDATA = Flags | Protocol | Algorithm | Public Key.
+
+   The size of the digest may vary depending on the digest algorithm and
+   DNSKEY RR size.  As of the time of this writing, the only defined
+   digest algorithm is SHA-1, which produces a 20 octet digest.
+
+5.2.  Processing of DS RRs When Validating Responses
+
+   The DS RR links the authentication chain across zone boundaries, so
+   the DS RR requires extra care in processing.  The DNSKEY RR referred
+   to in the DS RR MUST be a DNSSEC zone key.  The DNSKEY RR Flags MUST
+   have Flags bit 7 set.  If the DNSKEY flags do not indicate a DNSSEC
+   zone key, the DS RR (and the DNSKEY RR it references) MUST NOT be
+   used in the validation process.
+
+5.3.  The DS RR Presentation Format
+
+   The presentation format of the RDATA portion is as follows:
+
+   The Key Tag field MUST be represented as an unsigned decimal integer.
+
+   The Algorithm field MUST be represented either as an unsigned decimal
+   integer or as an algorithm mnemonic specified in Appendix A.1.
+
+   The Digest Type field MUST be represented as an unsigned decimal
+   integer.
+
+
+
+
+
+
+Arends, et al.              Standards Track                    [Page 17]
+
+RFC 4034                DNSSEC Resource Records               March 2005
+
+
+   The Digest MUST be represented as a sequence of case-insensitive
+   hexadecimal digits.  Whitespace is allowed within the hexadecimal
+   text.
+
+5.4.  DS RR Example
+
+   The following example shows a DNSKEY RR and its corresponding DS RR.
+
+   dskey.example.com. 86400 IN DNSKEY 256 3 5 ( AQOeiiR0GOMYkDshWoSKz9Xz
+                                             fwJr1AYtsmx3TGkJaNXVbfi/
+                                             2pHm822aJ5iI9BMzNXxeYCmZ
+                                             DRD99WYwYqUSdjMmmAphXdvx
+                                             egXd/M5+X7OrzKBaMbCVdFLU
+                                             Uh6DhweJBjEVv5f2wwjM9Xzc
+                                             nOf+EPbtG9DMBmADjFDc2w/r
+                                             ljwvFw==
+                                             ) ;  key id = 60485
+
+   dskey.example.com. 86400 IN DS 60485 5 1 ( 2BB183AF5F22588179A53B0A
+                                              98631FAD1A292118 )
+
+   The first four text fields specify the name, TTL, Class, and RR type
+   (DS).  Value 60485 is the key tag for the corresponding
+   "dskey.example.com." DNSKEY RR, and value 5 denotes the algorithm
+   used by this "dskey.example.com." DNSKEY RR.  The value 1 is the
+   algorithm used to construct the digest, and the rest of the RDATA
+   text is the digest in hexadecimal.
+
+6.  Canonical Form and Order of Resource Records
+
+   This section defines a canonical form for resource records, a
+   canonical ordering of DNS names, and a canonical ordering of resource
+   records within an RRset.  A canonical name order is required to
+   construct the NSEC name chain.  A canonical RR form and ordering
+   within an RRset are required in order to construct and verify RRSIG
+   RRs.
+
+6.1.  Canonical DNS Name Order
+
+   For the purposes of DNS security, owner names are ordered by treating
+   individual labels as unsigned left-justified octet strings.  The
+   absence of a octet sorts before a zero value octet, and uppercase
+   US-ASCII letters are treated as if they were lowercase US-ASCII
+   letters.
+
+
+
+
+
+
+
+Arends, et al.              Standards Track                    [Page 18]
+
+RFC 4034                DNSSEC Resource Records               March 2005
+
+
+   To compute the canonical ordering of a set of DNS names, start by
+   sorting the names according to their most significant (rightmost)
+   labels.  For names in which the most significant label is identical,
+   continue sorting according to their next most significant label, and
+   so forth.
+
+   For example, the following names are sorted in canonical DNS name
+   order.  The most significant label is "example".  At this level,
+   "example" sorts first, followed by names ending in "a.example", then
+   by names ending "z.example".  The names within each level are sorted
+   in the same way.
+
+             example
+             a.example
+             yljkjljk.a.example
+             Z.a.example
+             zABC.a.EXAMPLE
+             z.example
+             \001.z.example
+             *.z.example
+             \200.z.example
+
+6.2.  Canonical RR Form
+
+   For the purposes of DNS security, the canonical form of an RR is the
+   wire format of the RR where:
+
+   1.  every domain name in the RR is fully expanded (no DNS name
+       compression) and fully qualified;
+
+   2.  all uppercase US-ASCII letters in the owner name of the RR are
+       replaced by the corresponding lowercase US-ASCII letters;
+
+   3.  if the type of the RR is NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR,
+       HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT, NAPTR, KX,
+       SRV, DNAME, A6, RRSIG, or NSEC, all uppercase US-ASCII letters in
+       the DNS names contained within the RDATA are replaced by the
+       corresponding lowercase US-ASCII letters;
+
+   4.  if the owner name of the RR is a wildcard name, the owner name is
+       in its original unexpanded form, including the "*" label (no
+       wildcard substitution); and
+
+   5.  the RR's TTL is set to its original value as it appears in the
+       originating authoritative zone or the Original TTL field of the
+       covering RRSIG RR.
+
+
+
+
+
+Arends, et al.              Standards Track                    [Page 19]
+
+RFC 4034                DNSSEC Resource Records               March 2005
+
+
+6.3.  Canonical RR Ordering within an RRset
+
+   For the purposes of DNS security, RRs with the same owner name,
+   class, and type are sorted by treating the RDATA portion of the
+   canonical form of each RR as a left-justified unsigned octet sequence
+   in which the absence of an octet sorts before a zero octet.
+
+   [RFC2181] specifies that an RRset is not allowed to contain duplicate
+   records (multiple RRs with the same owner name, class, type, and
+   RDATA).  Therefore, if an implementation detects duplicate RRs when
+   putting the RRset in canonical form, it MUST treat this as a protocol
+   error.  If the implementation chooses to handle this protocol error
+   in the spirit of the robustness principle (being liberal in what it
+   accepts), it MUST remove all but one of the duplicate RR(s) for the
+   purposes of calculating the canonical form of the RRset.
+
+7.  IANA Considerations
+
+   This document introduces no new IANA considerations, as all of the
+   protocol parameters used in this document have already been assigned
+   by previous specifications.  However, since the evolution of DNSSEC
+   has been long and somewhat convoluted, this section attempts to
+   describe the current state of the IANA registries and other protocol
+   parameters that are (or once were) related to DNSSEC.
+
+   Please refer to [RFC4035] for additional IANA considerations.
+
+   DNS Resource Record Types: [RFC2535] assigned types 24, 25, and 30 to
+      the SIG, KEY, and NXT RRs, respectively.  [RFC3658] assigned DNS
+      Resource Record Type 43 to DS.  [RFC3755] assigned types 46, 47,
+      and 48 to the RRSIG, NSEC, and DNSKEY RRs, respectively.
+      [RFC3755] also marked type 30 (NXT) as Obsolete and restricted use
+      of types 24 (SIG) and 25 (KEY) to the "SIG(0)" transaction
+      security protocol described in [RFC2931] and to the transaction
+      KEY Resource Record described in [RFC2930].
+
+   DNS Security Algorithm Numbers: [RFC2535] created an IANA registry
+      for DNSSEC Resource Record Algorithm field numbers and assigned
+      values 1-4 and 252-255.  [RFC3110] assigned value 5.  [RFC3755]
+      altered this registry to include flags for each entry regarding
+      its use with the DNS security extensions.  Each algorithm entry
+      could refer to an algorithm that can be used for zone signing,
+      transaction security (see [RFC2931]), or both.  Values 6-251 are
+      available for assignment by IETF standards action ([RFC3755]).
+      See Appendix A for a full listing of the DNS Security Algorithm
+      Numbers entries at the time of this writing and their status for
+      use in DNSSEC.
+
+
+
+
+Arends, et al.              Standards Track                    [Page 20]
+
+RFC 4034                DNSSEC Resource Records               March 2005
+
+
+      [RFC3658] created an IANA registry for DNSSEC DS Digest Types and
+      assigned value 0 to reserved and value 1 to SHA-1.
+
+   KEY Protocol Values: [RFC2535] created an IANA Registry for KEY
+      Protocol Values, but [RFC3445] reassigned all values other than 3
+      to reserved and closed this IANA registry.  The registry remains
+      closed, and all KEY and DNSKEY records are required to have a
+      Protocol Octet value of 3.
+
+   Flag bits in the KEY and DNSKEY RRs: [RFC3755] created an IANA
+      registry for the DNSSEC KEY and DNSKEY RR flag bits.  Initially,
+      this registry only contains assignments for bit 7 (the ZONE bit)
+      and bit 15 (the Secure Entry Point flag (SEP) bit; see [RFC3757]).
+      As stated in [RFC3755], bits 0-6 and 8-14 are available for
+      assignment by IETF Standards Action.
+
+8.  Security Considerations
+
+   This document describes the format of four DNS resource records used
+   by the DNS security extensions and presents an algorithm for
+   calculating a key tag for a public key.  Other than the items
+   described below, the resource records themselves introduce no
+   security considerations.  Please see [RFC4033] and [RFC4035] for
+   additional security considerations related to the use of these
+   records.
+
+   The DS record points to a DNSKEY RR by using a cryptographic digest,
+   the key algorithm type, and a key tag.  The DS record is intended to
+   identify an existing DNSKEY RR, but it is theoretically possible for
+   an attacker to generate a DNSKEY that matches all the DS fields.  The
+   probability of constructing a matching DNSKEY depends on the type of
+   digest algorithm in use.  The only currently defined digest algorithm
+   is SHA-1, and the working group believes that constructing a public
+   key that would match the algorithm, key tag, and SHA-1 digest given
+   in a DS record would be a sufficiently difficult problem that such an
+   attack is not a serious threat at this time.
+
+   The key tag is used to help select DNSKEY resource records
+   efficiently, but it does not uniquely identify a single DNSKEY
+   resource record.  It is possible for two distinct DNSKEY RRs to have
+   the same owner name, the same algorithm type, and the same key tag.
+   An implementation that uses only the key tag to select a DNSKEY RR
+   might select the wrong public key in some circumstances.  Please see
+   Appendix B for further details.
+
+
+
+
+
+
+
+Arends, et al.              Standards Track                    [Page 21]
+
+RFC 4034                DNSSEC Resource Records               March 2005
+
+
+   The table of algorithms in Appendix A and the key tag calculation
+   algorithms in Appendix B include the RSA/MD5 algorithm for
+   completeness, but the RSA/MD5 algorithm is NOT RECOMMENDED, as
+   explained in [RFC3110].
+
+9.  Acknowledgements
+
+   This document was created from the input and ideas of the members of
+   the DNS Extensions Working Group and working group mailing list.  The
+   editors would like to express their thanks for the comments and
+   suggestions received during the revision of these security extension
+   specifications.  Although explicitly listing everyone who has
+   contributed during the decade in which DNSSEC has been under
+   development would be impossible, [RFC4033] includes a list of some of
+   the participants who were kind enough to comment on these documents.
+
+10.  References
+
+10.1.  Normative References
+
+   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
+              STD 13, RFC 1034, November 1987.
+
+   [RFC1035]  Mockapetris, P., "Domain names - implementation and
+              specification", STD 13, RFC 1035, November 1987.
+
+   [RFC1982]  Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
+              August 1996.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2181]  Elz, R. and R. Bush, "Clarifications to the DNS
+              Specification", RFC 2181, July 1997.
+
+   [RFC2308]  Andrews, M., "Negative Caching of DNS Queries (DNS
+              NCACHE)", RFC 2308, March 1998.
+
+   [RFC2536]  Eastlake 3rd, D., "DSA KEYs and SIGs in the Domain Name
+              System (DNS)", RFC 2536, March 1999.
+
+   [RFC2931]  Eastlake 3rd, D., "DNS Request and Transaction Signatures
+              ( SIG(0)s )", RFC 2931, September 2000.
+
+   [RFC3110]  Eastlake 3rd, D., "RSA/SHA-1 SIGs and RSA KEYs in the
+              Domain Name System (DNS)", RFC 3110, May 2001.
+
+
+
+
+
+Arends, et al.              Standards Track                    [Page 22]
+
+RFC 4034                DNSSEC Resource Records               March 2005
+
+
+   [RFC3445]  Massey, D. and S. Rose, "Limiting the Scope of the KEY
+              Resource Record (RR)", RFC 3445, December 2002.
+
+   [RFC3548]  Josefsson, S., "The Base16, Base32, and Base64 Data
+              Encodings", RFC 3548, July 2003.
+
+   [RFC3597]  Gustafsson, A., "Handling of Unknown DNS Resource Record
+              (RR) Types", RFC 3597, September 2003.
+
+   [RFC3658]  Gudmundsson, O., "Delegation Signer (DS) Resource Record
+              (RR)", RFC 3658, December 2003.
+
+   [RFC3755]  Weiler, S., "Legacy Resolver Compatibility for Delegation
+              Signer (DS)", RFC 3755, May 2004.
+
+   [RFC3757]  Kolkman, O., Schlyter, J., and E. Lewis, "Domain Name
+              System KEY (DNSKEY) Resource Record (RR) Secure Entry
+              Point (SEP) Flag", RFC 3757, April 2004.
+
+   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
+              Rose, "DNS Security Introduction and Requirements", RFC
+              4033, March 2005.
+
+   [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
+              Rose, "Protocol Modifications for the DNS Security
+              Extensions", RFC 4035, March 2005.
+
+10.2.  Informative References
+
+   [RFC2535]  Eastlake 3rd, D., "Domain Name System Security
+              Extensions", RFC 2535, March 1999.
+
+   [RFC2537]  Eastlake 3rd, D., "RSA/MD5 KEYs and SIGs in the Domain
+              Name System (DNS)", RFC 2537, March 1999.
+
+   [RFC2539]  Eastlake 3rd, D., "Storage of Diffie-Hellman Keys in the
+              Domain Name System (DNS)", RFC 2539, March 1999.
+
+   [RFC2930]  Eastlake 3rd, D., "Secret Key Establishment for DNS (TKEY
+              RR)", RFC 2930, September 2000.
+
+   [RFC3845]  Schlyter, J., "DNS Security (DNSSEC) NextSECure (NSEC)
+              RDATA Format", RFC 3845, August 2004.
+
+
+
+
+
+
+
+
+Arends, et al.              Standards Track                    [Page 23]
+
+RFC 4034                DNSSEC Resource Records               March 2005
+
+
+Appendix A.  DNSSEC Algorithm and Digest Types
+
+   The DNS security extensions are designed to be independent of the
+   underlying cryptographic algorithms.  The DNSKEY, RRSIG, and DS
+   resource records all use a DNSSEC Algorithm Number to identify the
+   cryptographic algorithm in use by the resource record.  The DS
+   resource record also specifies a Digest Algorithm Number to identify
+   the digest algorithm used to construct the DS record.  The currently
+   defined Algorithm and Digest Types are listed below.  Additional
+   Algorithm or Digest Types could be added as advances in cryptography
+   warrant them.
+
+   A DNSSEC aware resolver or name server MUST implement all MANDATORY
+   algorithms.
+
+A.1.  DNSSEC Algorithm Types
+
+   The DNSKEY, RRSIG, and DS RRs use an 8-bit number to identify the
+   security algorithm being used.  These values are stored in the
+   "Algorithm number" field in the resource record RDATA.
+
+   Some algorithms are usable only for zone signing (DNSSEC), some only
+   for transaction security mechanisms (SIG(0) and TSIG), and some for
+   both.  Those usable for zone signing may appear in DNSKEY, RRSIG, and
+   DS RRs.  Those usable for transaction security would be present in
+   SIG(0) and KEY RRs, as described in [RFC2931].
+
+                                Zone
+   Value Algorithm [Mnemonic]  Signing  References   Status
+   ----- -------------------- --------- ----------  ---------
+     0   reserved
+     1   RSA/MD5 [RSAMD5]         n      [RFC2537]  NOT RECOMMENDED
+     2   Diffie-Hellman [DH]      n      [RFC2539]   -
+     3   DSA/SHA-1 [DSA]          y      [RFC2536]  OPTIONAL
+     4   Elliptic Curve [ECC]              TBA       -
+     5   RSA/SHA-1 [RSASHA1]      y      [RFC3110]  MANDATORY
+   252   Indirect [INDIRECT]      n                  -
+   253   Private [PRIVATEDNS]     y      see below  OPTIONAL
+   254   Private [PRIVATEOID]     y      see below  OPTIONAL
+   255   reserved
+
+   6 - 251  Available for assignment by IETF Standards Action.
+
+
+
+
+
+
+
+
+
+Arends, et al.              Standards Track                    [Page 24]
+
+RFC 4034                DNSSEC Resource Records               March 2005
+
+
+A.1.1.  Private Algorithm Types
+
+   Algorithm number 253 is reserved for private use and will never be
+   assigned to a specific algorithm.  The public key area in the DNSKEY
+   RR and the signature area in the RRSIG RR begin with a wire encoded
+   domain name, which MUST NOT be compressed.  The domain name indicates
+   the private algorithm to use, and the remainder of the public key
+   area is determined by that algorithm.  Entities should only use
+   domain names they control to designate their private algorithms.
+
+   Algorithm number 254 is reserved for private use and will never be
+   assigned to a specific algorithm.  The public key area in the DNSKEY
+   RR and the signature area in the RRSIG RR begin with an unsigned
+   length byte followed by a BER encoded Object Identifier (ISO OID) of
+   that length.  The OID indicates the private algorithm in use, and the
+   remainder of the area is whatever is required by that algorithm.
+   Entities should only use OIDs they control to designate their private
+   algorithms.
+
+A.2.  DNSSEC Digest Types
+
+   A "Digest Type" field in the DS resource record types identifies the
+   cryptographic digest algorithm used by the resource record.  The
+   following table lists the currently defined digest algorithm types.
+
+              VALUE   Algorithm                 STATUS
+                0      Reserved                   -
+                1      SHA-1                   MANDATORY
+              2-255    Unassigned                 -
+
+Appendix B.  Key Tag Calculation
+
+   The Key Tag field in the RRSIG and DS resource record types provides
+   a mechanism for selecting a public key efficiently.  In most cases, a
+   combination of owner name, algorithm, and key tag can efficiently
+   identify a DNSKEY record.  Both the RRSIG and DS resource records
+   have corresponding DNSKEY records.  The Key Tag field in the RRSIG
+   and DS records can be used to help select the corresponding DNSKEY RR
+   efficiently when more than one candidate DNSKEY RR is available.
+
+   However, it is essential to note that the key tag is not a unique
+   identifier.  It is theoretically possible for two distinct DNSKEY RRs
+   to have the same owner name, the same algorithm, and the same key
+   tag.  The key tag is used to limit the possible candidate keys, but
+   it does not uniquely identify a DNSKEY record.  Implementations MUST
+   NOT assume that the key tag uniquely identifies a DNSKEY RR.
+
+
+
+
+
+Arends, et al.              Standards Track                    [Page 25]
+
+RFC 4034                DNSSEC Resource Records               March 2005
+
+
+   The key tag is the same for all DNSKEY algorithm types except
+   algorithm 1 (please see Appendix B.1 for the definition of the key
+   tag for algorithm 1).  The key tag algorithm is the sum of the wire
+   format of the DNSKEY RDATA broken into 2 octet groups.  First, the
+   RDATA (in wire format) is treated as a series of 2 octet groups.
+   These groups are then added together, ignoring any carry bits.
+
+   A reference implementation of the key tag algorithm is as an ANSI C
+   function is given below, with the RDATA portion of the DNSKEY RR is
+   used as input.  It is not necessary to use the following reference
+   code verbatim, but the numerical value of the Key Tag MUST be
+   identical to what the reference implementation would generate for the
+   same input.
+
+   Please note that the algorithm for calculating the Key Tag is almost
+   but not completely identical to the familiar ones-complement checksum
+   used in many other Internet protocols.  Key Tags MUST be calculated
+   using the algorithm described here rather than the ones complement
+   checksum.
+
+   The following ANSI C reference implementation calculates the value of
+   a Key Tag.  This reference implementation applies to all algorithm
+   types except algorithm 1 (see Appendix B.1).  The input is the wire
+   format of the RDATA portion of the DNSKEY RR.  The code is written
+   for clarity, not efficiency.
+
+   /*
+    * Assumes that int is at least 16 bits.
+    * First octet of the key tag is the most significant 8 bits of the
+    * return value;
+    * Second octet of the key tag is the least significant 8 bits of the
+    * return value.
+    */
+
+   unsigned int
+   keytag (
+           unsigned char key[],  /* the RDATA part of the DNSKEY RR */
+           unsigned int keysize  /* the RDLENGTH */
+          )
+   {
+           unsigned long ac;     /* assumed to be 32 bits or larger */
+           int i;                /* loop index */
+
+           for ( ac = 0, i = 0; i < keysize; ++i )
+                   ac += (i & 1) ? key[i] : key[i] << 8;
+           ac += (ac >> 16) & 0xFFFF;
+           return ac & 0xFFFF;
+   }
+
+
+
+Arends, et al.              Standards Track                    [Page 26]
+
+RFC 4034                DNSSEC Resource Records               March 2005
+
+
+B.1.  Key Tag for Algorithm 1 (RSA/MD5)
+
+   The key tag for algorithm 1 (RSA/MD5) is defined differently from the
+   key tag for all other algorithms, for historical reasons.  For a
+   DNSKEY RR with algorithm 1, the key tag is defined to be the most
+   significant 16 bits of the least significant 24 bits in the public
+   key modulus (in other words, the 4th to last and 3rd to last octets
+   of the public key modulus).
+
+   Please note that Algorithm 1 is NOT RECOMMENDED.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al.              Standards Track                    [Page 27]
+
+RFC 4034                DNSSEC Resource Records               March 2005
+
+
+Authors' Addresses
+
+   Roy Arends
+   Telematica Instituut
+   Brouwerijstraat 1
+   7523 XC  Enschede
+   NL
+
+   EMail: roy.arends@telin.nl
+
+
+   Rob Austein
+   Internet Systems Consortium
+   950 Charter Street
+   Redwood City, CA  94063
+   USA
+
+   EMail: sra@isc.org
+
+
+   Matt Larson
+   VeriSign, Inc.
+   21345 Ridgetop Circle
+   Dulles, VA  20166-6503
+   USA
+
+   EMail: mlarson@verisign.com
+
+
+   Dan Massey
+   Colorado State University
+   Department of Computer Science
+   Fort Collins, CO 80523-1873
+
+   EMail: massey@cs.colostate.edu
+
+
+   Scott Rose
+   National Institute for Standards and Technology
+   100 Bureau Drive
+   Gaithersburg, MD  20899-8920
+   USA
+
+   EMail: scott.rose@nist.gov
+
+
+
+
+
+
+
+Arends, et al.              Standards Track                    [Page 28]
+
+RFC 4034                DNSSEC Resource Records               March 2005
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2005).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at ietf-
+   ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+Arends, et al.              Standards Track                    [Page 29]
+
diff --git a/doc/rfc/rfc4035.txt b/doc/rfc/rfc4035.txt
new file mode 100644
index 0000000..b701cd2
--- /dev/null
+++ b/doc/rfc/rfc4035.txt
@@ -0,0 +1,2971 @@
+
+
+
+
+
+
+Network Working Group                                          R. Arends
+Request for Comments: 4035                          Telematica Instituut
+Obsoletes: 2535, 3008, 3090, 3445, 3655, 3658,                R. Austein
+           3755, 3757, 3845                                          ISC
+Updates: 1034, 1035, 2136, 2181, 2308, 3225,                   M. Larson
+         3007, 3597, 3226                                       VeriSign
+Category: Standards Track                                      D. Massey
+                                               Colorado State University
+                                                                 S. Rose
+                                                                    NIST
+                                                              March 2005
+
+
+         Protocol Modifications for the DNS Security Extensions
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   This document is part of a family of documents that describe the DNS
+   Security Extensions (DNSSEC).  The DNS Security Extensions are a
+   collection of new resource records and protocol modifications that
+   add data origin authentication and data integrity to the DNS.  This
+   document describes the DNSSEC protocol modifications.  This document
+   defines the concept of a signed zone, along with the requirements for
+   serving and resolving by using DNSSEC.  These techniques allow a
+   security-aware resolver to authenticate both DNS resource records and
+   authoritative DNS error indications.
+
+   This document obsoletes RFC 2535 and incorporates changes from all
+   updates to RFC 2535.
+
+
+
+
+
+
+
+
+
+
+Arends, et al.              Standards Track                     [Page 1]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+       1.1.  Background and Related Documents . . . . . . . . . . . .  4
+       1.2.  Reserved Words . . . . . . . . . . . . . . . . . . . . .  4
+   2.  Zone Signing . . . . . . . . . . . . . . . . . . . . . . . . .  4
+       2.1.  Including DNSKEY RRs in a Zone . . . . . . . . . . . . .  5
+       2.2.  Including RRSIG RRs in a Zone  . . . . . . . . . . . . .  5
+       2.3.  Including NSEC RRs in a Zone . . . . . . . . . . . . . .  6
+       2.4.  Including DS RRs in a Zone . . . . . . . . . . . . . . .  7
+       2.5.  Changes to the CNAME Resource Record.  . . . . . . . . .  7
+       2.6.  DNSSEC RR Types Appearing at Zone Cuts.  . . . . . . . .  8
+       2.7.  Example of a Secure Zone . . . . . . . . . . . . . . . .  8
+   3.  Serving  . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
+       3.1.  Authoritative Name Servers . . . . . . . . . . . . . . .  9
+             3.1.1.  Including RRSIG RRs in a Response  . . . . . . . 10
+             3.1.2.  Including DNSKEY RRs in a Response . . . . . . . 11
+             3.1.3.  Including NSEC RRs in a Response . . . . . . . . 11
+             3.1.4.  Including DS RRs in a Response . . . . . . . . . 14
+             3.1.5.  Responding to Queries for Type AXFR or IXFR  . . 15
+             3.1.6.  The AD and CD Bits in an Authoritative Response. 16
+       3.2.  Recursive Name Servers . . . . . . . . . . . . . . . . . 17
+             3.2.1.  The DO Bit . . . . . . . . . . . . . . . . . . . 17
+             3.2.2.  The CD Bit . . . . . . . . . . . . . . . . . . . 17
+             3.2.3.  The AD Bit . . . . . . . . . . . . . . . . . . . 18
+       3.3.  Example DNSSEC Responses . . . . . . . . . . . . . . . . 19
+   4.  Resolving  . . . . . . . . . . . . . . . . . . . . . . . . . . 19
+       4.1.  EDNS Support . . . . . . . . . . . . . . . . . . . . . . 19
+       4.2.  Signature Verification Support . . . . . . . . . . . . . 19
+       4.3.  Determining Security Status of Data  . . . . . . . . . . 20
+       4.4.  Configured Trust Anchors . . . . . . . . . . . . . . . . 21
+       4.5.  Response Caching . . . . . . . . . . . . . . . . . . . . 21
+       4.6.  Handling of the CD and AD Bits . . . . . . . . . . . . . 22
+       4.7.  Caching BAD Data . . . . . . . . . . . . . . . . . . . . 22
+       4.8.  Synthesized CNAMEs . . . . . . . . . . . . . . . . . . . 23
+       4.9.  Stub Resolvers . . . . . . . . . . . . . . . . . . . . . 23
+             4.9.1.  Handling of the DO Bit . . . . . . . . . . . . . 24
+             4.9.2.  Handling of the CD Bit . . . . . . . . . . . . . 24
+             4.9.3.  Handling of the AD Bit . . . . . . . . . . . . . 24
+   5.  Authenticating DNS Responses . . . . . . . . . . . . . . . . . 25
+       5.1.  Special Considerations for Islands of Security . . . . . 26
+       5.2.  Authenticating Referrals . . . . . . . . . . . . . . . . 26
+       5.3.  Authenticating an RRset with an RRSIG RR . . . . . . . . 28
+             5.3.1.  Checking the RRSIG RR Validity . . . . . . . . . 28
+             5.3.2.  Reconstructing the Signed Data . . . . . . . . . 29
+             5.3.3.  Checking the Signature . . . . . . . . . . . . . 31
+             5.3.4.  Authenticating a Wildcard Expanded RRset
+                     Positive Response. . . . . . . . . . . . . . . . 32
+
+
+
+Arends, et al.              Standards Track                     [Page 2]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+       5.4.  Authenticated Denial of Existence  . . . . . . . . . . . 32
+       5.5.  Resolver Behavior When Signatures Do Not Validate  . . . 33
+       5.6.  Authentication Example . . . . . . . . . . . . . . . . . 33
+   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 33
+   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 33
+   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34
+   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 34
+       9.1.  Normative References . . . . . . . . . . . . . . . . . . 34
+       9.2.  Informative References . . . . . . . . . . . . . . . . . 35
+   A.  Signed Zone Example  . . . . . . . . . . . . . . . . . . . . . 36
+   B.  Example Responses  . . . . . . . . . . . . . . . . . . . . . . 41
+       B.1.  Answer . . . . . . . . . . . . . . . . . . . . . . . . . 41
+       B.2.  Name Error . . . . . . . . . . . . . . . . . . . . . . . 43
+       B.3.  No Data Error  . . . . . . . . . . . . . . . . . . . . . 44
+       B.4.  Referral to Signed Zone  . . . . . . . . . . . . . . . . 44
+       B.5.  Referral to Unsigned Zone  . . . . . . . . . . . . . . . 45
+       B.6.  Wildcard Expansion . . . . . . . . . . . . . . . . . . . 46
+       B.7.  Wildcard No Data Error . . . . . . . . . . . . . . . . . 47
+       B.8.  DS Child Zone No Data Error  . . . . . . . . . . . . . . 48
+   C.  Authentication Examples  . . . . . . . . . . . . . . . . . . . 49
+       C.1.  Authenticating an Answer . . . . . . . . . . . . . . . . 49
+             C.1.1.  Authenticating the Example DNSKEY RR . . . . . . 49
+       C.2.  Name Error . . . . . . . . . . . . . . . . . . . . . . . 50
+       C.3.  No Data Error  . . . . . . . . . . . . . . . . . . . . . 50
+       C.4.  Referral to Signed Zone  . . . . . . . . . . . . . . . . 50
+       C.5.  Referral to Unsigned Zone  . . . . . . . . . . . . . . . 51
+       C.6.  Wildcard Expansion . . . . . . . . . . . . . . . . . . . 51
+       C.7.  Wildcard No Data Error . . . . . . . . . . . . . . . . . 51
+       C.8.  DS Child Zone No Data Error  . . . . . . . . . . . . . . 51
+   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 52
+   Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 53
+
+1.  Introduction
+
+   The DNS Security Extensions (DNSSEC) are a collection of new resource
+   records and protocol modifications that add data origin
+   authentication and data integrity to the DNS.  This document defines
+   the DNSSEC protocol modifications.  Section 2 of this document
+   defines the concept of a signed zone and lists the requirements for
+   zone signing.  Section 3 describes the modifications to authoritative
+   name server behavior necessary for handling signed zones.  Section 4
+   describes the behavior of entities that include security-aware
+   resolver functions.  Finally, Section 5 defines how to use DNSSEC RRs
+   to authenticate a response.
+
+
+
+
+
+
+
+Arends, et al.              Standards Track                     [Page 3]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+1.1.  Background and Related Documents
+
+   This document is part of a family of documents defining DNSSEC that
+   should be read together as a set.
+
+   [RFC4033] contains an introduction to DNSSEC and definitions of
+   common terms; the reader is assumed to be familiar with this
+   document.  [RFC4033] also contains a list of other documents updated
+   by and obsoleted by this document set.
+
+   [RFC4034] defines the DNSSEC resource records.
+
+   The reader is also assumed to be familiar with the basic DNS concepts
+   described in [RFC1034], [RFC1035], and the subsequent documents that
+   update them; particularly, [RFC2181] and [RFC2308].
+
+   This document defines the DNSSEC protocol operations.
+
+1.2.  Reserved Words
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+2.  Zone Signing
+
+   DNSSEC introduces the concept of signed zones.  A signed zone
+   includes DNS Public Key (DNSKEY), Resource Record Signature (RRSIG),
+   Next Secure (NSEC), and (optionally) Delegation Signer (DS) records
+   according to the rules specified in Sections 2.1, 2.2, 2.3, and 2.4,
+   respectively.  A zone that does not include these records according
+   to the rules in this section is an unsigned zone.
+
+   DNSSEC requires a change to the definition of the CNAME resource
+   record ([RFC1035]).  Section 2.5 changes the CNAME RR to allow RRSIG
+   and NSEC RRs to appear at the same owner name as does a CNAME RR.
+
+   DNSSEC specifies the placement of two new RR types, NSEC and DS,
+   which can be placed at the parental side of a zone cut (that is, at a
+   delegation point).  This is an exception to the general prohibition
+   against putting data in the parent zone at a zone cut.  Section 2.6
+   describes this change.
+
+
+
+
+
+
+
+
+
+Arends, et al.              Standards Track                     [Page 4]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+2.1.  Including DNSKEY RRs in a Zone
+
+   To sign a zone, the zone's administrator generates one or more
+   public/private key pairs and uses the private key(s) to sign
+   authoritative RRsets in the zone.  For each private key used to
+   create RRSIG RRs in a zone, the zone SHOULD include a zone DNSKEY RR
+   containing the corresponding public key.  A zone key DNSKEY RR MUST
+   have the Zone Key bit of the flags RDATA field set (see Section 2.1.1
+   of [RFC4034]).  Public keys associated with other DNS operations MAY
+   be stored in DNSKEY RRs that are not marked as zone keys but MUST NOT
+   be used to verify RRSIGs.
+
+   If the zone administrator intends a signed zone to be usable other
+   than as an island of security, the zone apex MUST contain at least
+   one DNSKEY RR to act as a secure entry point into the zone.  This
+   secure entry point could then be used as the target of a secure
+   delegation via a corresponding DS RR in the parent zone (see
+   [RFC4034]).
+
+2.2.  Including RRSIG RRs in a Zone
+
+   For each authoritative RRset in a signed zone, there MUST be at least
+   one RRSIG record that meets the following requirements:
+
+   o  The RRSIG owner name is equal to the RRset owner name.
+
+   o  The RRSIG class is equal to the RRset class.
+
+   o  The RRSIG Type Covered field is equal to the RRset type.
+
+   o  The RRSIG Original TTL field is equal to the TTL of the RRset.
+
+   o  The RRSIG RR's TTL is equal to the TTL of the RRset.
+
+   o  The RRSIG Labels field is equal to the number of labels in the
+      RRset owner name, not counting the null root label and not
+      counting the leftmost label if it is a wildcard.
+
+   o  The RRSIG Signer's Name field is equal to the name of the zone
+      containing the RRset.
+
+   o  The RRSIG Algorithm, Signer's Name, and Key Tag fields identify a
+      zone key DNSKEY record at the zone apex.
+
+   The process for constructing the RRSIG RR for a given RRset is
+   described in [RFC4034].  An RRset MAY have multiple RRSIG RRs
+   associated with it.  Note that as RRSIG RRs are closely tied to the
+   RRsets whose signatures they contain, RRSIG RRs, unlike all other DNS
+
+
+
+Arends, et al.              Standards Track                     [Page 5]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+   RR types, do not form RRsets.  In particular, the TTL values among
+   RRSIG RRs with a common owner name do not follow the RRset rules
+   described in [RFC2181].
+
+   An RRSIG RR itself MUST NOT be signed, as signing an RRSIG RR would
+   add no value and would create an infinite loop in the signing
+   process.
+
+   The NS RRset that appears at the zone apex name MUST be signed, but
+   the NS RRsets that appear at delegation points (that is, the NS
+   RRsets in the parent zone that delegate the name to the child zone's
+   name servers) MUST NOT be signed.  Glue address RRsets associated
+   with delegations MUST NOT be signed.
+
+   There MUST be an RRSIG for each RRset using at least one DNSKEY of
+   each algorithm in the zone apex DNSKEY RRset.  The apex DNSKEY RRset
+   itself MUST be signed by each algorithm appearing in the DS RRset
+   located at the delegating parent (if any).
+
+2.3.  Including NSEC RRs in a Zone
+
+   Each owner name in the zone that has authoritative data or a
+   delegation point NS RRset MUST have an NSEC resource record.  The
+   format of NSEC RRs and the process for constructing the NSEC RR for a
+   given name is described in [RFC4034].
+
+   The TTL value for any NSEC RR SHOULD be the same as the minimum TTL
+   value field in the zone SOA RR.
+
+   An NSEC record (and its associated RRSIG RRset) MUST NOT be the only
+   RRset at any particular owner name.  That is, the signing process
+   MUST NOT create NSEC or RRSIG RRs for owner name nodes that were not
+   the owner name of any RRset before the zone was signed.  The main
+   reasons for this are a desire for namespace consistency between
+   signed and unsigned versions of the same zone and a desire to reduce
+   the risk of response inconsistency in security oblivious recursive
+   name servers.
+
+   The type bitmap of every NSEC resource record in a signed zone MUST
+   indicate the presence of both the NSEC record itself and its
+   corresponding RRSIG record.
+
+   The difference between the set of owner names that require RRSIG
+   records and the set of owner names that require NSEC records is
+   subtle and worth highlighting.  RRSIG records are present at the
+   owner names of all authoritative RRsets.  NSEC records are present at
+   the owner names of all names for which the signed zone is
+   authoritative and also at the owner names of delegations from the
+
+
+
+Arends, et al.              Standards Track                     [Page 6]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+   signed zone to its children.  Neither NSEC nor RRSIG records are
+   present (in the parent zone) at the owner names of glue address
+   RRsets.  Note, however, that this distinction is for the most part
+   visible only during the zone signing process, as NSEC RRsets are
+   authoritative data and are therefore signed.  Thus, any owner name
+   that has an NSEC RRset will have RRSIG RRs as well in the signed
+   zone.
+
+   The bitmap for the NSEC RR at a delegation point requires special
+   attention.  Bits corresponding to the delegation NS RRset and any
+   RRsets for which the parent zone has authoritative data MUST be set;
+   bits corresponding to any non-NS RRset for which the parent is not
+   authoritative MUST be clear.
+
+2.4.  Including DS RRs in a Zone
+
+   The DS resource record establishes authentication chains between DNS
+   zones.  A DS RRset SHOULD be present at a delegation point when the
+   child zone is signed.  The DS RRset MAY contain multiple records,
+   each referencing a public key in the child zone used to verify the
+   RRSIGs in that zone.  All DS RRsets in a zone MUST be signed, and DS
+   RRsets MUST NOT appear at a zone's apex.
+
+   A DS RR SHOULD point to a DNSKEY RR that is present in the child's
+   apex DNSKEY RRset, and the child's apex DNSKEY RRset SHOULD be signed
+   by the corresponding private key.  DS RRs that fail to meet these
+   conditions are not useful for validation, but because the DS RR and
+   its corresponding DNSKEY RR are in different zones, and because the
+   DNS is only loosely consistent, temporary mismatches can occur.
+
+   The TTL of a DS RRset SHOULD match the TTL of the delegating NS RRset
+   (that is, the NS RRset from the same zone containing the DS RRset).
+
+   Construction of a DS RR requires knowledge of the corresponding
+   DNSKEY RR in the child zone, which implies communication between the
+   child and parent zones.  This communication is an operational matter
+   not covered by this document.
+
+2.5.  Changes to the CNAME Resource Record
+
+   If a CNAME RRset is present at a name in a signed zone, appropriate
+   RRSIG and NSEC RRsets are REQUIRED at that name.  A KEY RRset at that
+   name for secure dynamic update purposes is also allowed ([RFC3007]).
+   Other types MUST NOT be present at that name.
+
+   This is a modification to the original CNAME definition given in
+   [RFC1034].  The original definition of the CNAME RR did not allow any
+   other types to coexist with a CNAME record, but a signed zone
+
+
+
+Arends, et al.              Standards Track                     [Page 7]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+   requires NSEC and RRSIG RRs for every authoritative name.  To resolve
+   this conflict, this specification modifies the definition of the
+   CNAME resource record to allow it to coexist with NSEC and RRSIG RRs.
+
+2.6.  DNSSEC RR Types Appearing at Zone Cuts
+
+   DNSSEC introduced two new RR types that are unusual in that they can
+   appear at the parental side of a zone cut.  At the parental side of a
+   zone cut (that is, at a delegation point), NSEC RRs are REQUIRED at
+   the owner name.  A DS RR could also be present if the zone being
+   delegated is signed and seeks to have a chain of authentication to
+   the parent zone.  This is an exception to the original DNS
+   specification ([RFC1034]), which states that only NS RRsets could
+   appear at the parental side of a zone cut.
+
+   This specification updates the original DNS specification to allow
+   NSEC and DS RR types at the parent side of a zone cut.  These RRsets
+   are authoritative for the parent when they appear at the parent side
+   of a zone cut.
+
+2.7.  Example of a Secure Zone
+
+   Appendix A shows a complete example of a small signed zone.
+
+3.  Serving
+
+   This section describes the behavior of entities that include
+   security-aware name server functions.  In many cases such functions
+   will be part of a security-aware recursive name server, but a
+   security-aware authoritative name server has some of the same
+   requirements.  Functions specific to security-aware recursive name
+   servers are described in Section 3.2; functions specific to
+   authoritative servers are described in Section 3.1.
+
+   In the following discussion, the terms "SNAME", "SCLASS", and "STYPE"
+   are as used in [RFC1034].
+
+   A security-aware name server MUST support the EDNS0 ([RFC2671])
+   message size extension, MUST support a message size of at least 1220
+   octets, and SHOULD support a message size of 4000 octets.  As IPv6
+   packets can only be fragmented by the source host, a security aware
+   name server SHOULD take steps to ensure that UDP datagrams it
+   transmits over IPv6 are fragmented, if necessary, at the minimum IPv6
+   MTU, unless the path MTU is known.  Please see [RFC1122], [RFC2460],
+   and [RFC3226] for further discussion of packet size and fragmentation
+   issues.
+
+
+
+
+
+Arends, et al.              Standards Track                     [Page 8]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+   A security-aware name server that receives a DNS query that does not
+   include the EDNS OPT pseudo-RR or that has the DO bit clear MUST
+   treat the RRSIG, DNSKEY, and NSEC RRs as it would any other RRset and
+   MUST NOT perform any of the additional processing described below.
+   Because the DS RR type has the peculiar property of only existing in
+   the parent zone at delegation points, DS RRs always require some
+   special processing, as described in Section 3.1.4.1.
+
+   Security aware name servers that receive explicit queries for
+   security RR types that match the content of more than one zone that
+   it serves (for example, NSEC and RRSIG RRs above and below a
+   delegation point where the server is authoritative for both zones)
+   should behave self-consistently.  As long as the response is always
+   consistent for each query to the name server, the name server MAY
+   return one of the following:
+
+   o  The above-delegation RRsets.
+   o  The below-delegation RRsets.
+   o  Both above and below-delegation RRsets.
+   o  Empty answer section (no records).
+   o  Some other response.
+   o  An error.
+
+   DNSSEC allocates two new bits in the DNS message header: the CD
+   (Checking Disabled) bit and the AD (Authentic Data) bit.  The CD bit
+   is controlled by resolvers; a security-aware name server MUST copy
+   the CD bit from a query into the corresponding response.  The AD bit
+   is controlled by name servers; a security-aware name server MUST
+   ignore the setting of the AD bit in queries.  See Sections 3.1.6,
+   3.2.2, 3.2.3, 4, and 4.9 for details on the behavior of these bits.
+
+   A security aware name server that synthesizes CNAME RRs from DNAME
+   RRs as described in [RFC2672] SHOULD NOT generate signatures for the
+   synthesized CNAME RRs.
+
+3.1.  Authoritative Name Servers
+
+   Upon receiving a relevant query that has the EDNS ([RFC2671]) OPT
+   pseudo-RR DO bit ([RFC3225]) set, a security-aware authoritative name
+   server for a signed zone MUST include additional RRSIG, NSEC, and DS
+   RRs, according to the following rules:
+
+   o  RRSIG RRs that can be used to authenticate a response MUST be
+      included in the response according to the rules in Section 3.1.1.
+
+
+
+
+
+
+
+Arends, et al.              Standards Track                     [Page 9]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+   o  NSEC RRs that can be used to provide authenticated denial of
+      existence MUST be included in the response automatically according
+      to the rules in Section 3.1.3.
+
+   o  Either a DS RRset or an NSEC RR proving that no DS RRs exist MUST
+      be included in referrals automatically according to the rules in
+      Section 3.1.4.
+
+   These rules only apply to responses where the semantics convey
+   information about the presence or absence of resource records.  That
+   is, these rules are not intended to rule out responses such as RCODE
+   4 ("Not Implemented") or RCODE 5 ("Refused").
+
+   DNSSEC does not change the DNS zone transfer protocol.  Section 3.1.5
+   discusses zone transfer requirements.
+
+3.1.1.  Including RRSIG RRs in a Response
+
+   When responding to a query that has the DO bit set, a security-aware
+   authoritative name server SHOULD attempt to send RRSIG RRs that a
+   security-aware resolver can use to authenticate the RRsets in the
+   response.  A name server SHOULD make every attempt to keep the RRset
+   and its associated RRSIG(s) together in a response.  Inclusion of
+   RRSIG RRs in a response is subject to the following rules:
+
+   o  When placing a signed RRset in the Answer section, the name server
+      MUST also place its RRSIG RRs in the Answer section.  The RRSIG
+      RRs have a higher priority for inclusion than any other RRsets
+      that may have to be included.  If space does not permit inclusion
+      of these RRSIG RRs, the name server MUST set the TC bit.
+
+   o  When placing a signed RRset in the Authority section, the name
+      server MUST also place its RRSIG RRs in the Authority section.
+      The RRSIG RRs have a higher priority for inclusion than any other
+      RRsets that may have to be included.  If space does not permit
+      inclusion of these RRSIG RRs, the name server MUST set the TC bit.
+
+   o  When placing a signed RRset in the Additional section, the name
+      server MUST also place its RRSIG RRs in the Additional section.
+      If space does not permit inclusion of both the RRset and its
+      associated RRSIG RRs, the name server MAY retain the RRset while
+      dropping the RRSIG RRs.  If this happens, the name server MUST NOT
+      set the TC bit solely because these RRSIG RRs didn't fit.
+
+
+
+
+
+
+
+
+Arends, et al.              Standards Track                    [Page 10]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+3.1.2.  Including DNSKEY RRs in a Response
+
+   When responding to a query that has the DO bit set and that requests
+   the SOA or NS RRs at the apex of a signed zone, a security-aware
+   authoritative name server for that zone MAY return the zone apex
+   DNSKEY RRset in the Additional section.  In this situation, the
+   DNSKEY RRset and associated RRSIG RRs have lower priority than does
+   any other information that would be placed in the additional section.
+   The name server SHOULD NOT include the DNSKEY RRset unless there is
+   enough space in the response message for both the DNSKEY RRset and
+   its associated RRSIG RR(s).  If there is not enough space to include
+   these DNSKEY and RRSIG RRs, the name server MUST omit them and MUST
+   NOT set the TC bit solely because these RRs didn't fit (see Section
+   3.1.1).
+
+3.1.3.  Including NSEC RRs in a Response
+
+   When responding to a query that has the DO bit set, a security-aware
+   authoritative name server for a signed zone MUST include NSEC RRs in
+   each of the following cases:
+
+   No Data: The zone contains RRsets that exactly match <SNAME, SCLASS>
+      but does not contain any RRsets that exactly match <SNAME, SCLASS,
+      STYPE>.
+
+   Name Error: The zone does not contain any RRsets that match <SNAME,
+      SCLASS> either exactly or via wildcard name expansion.
+
+   Wildcard Answer: The zone does not contain any RRsets that exactly
+      match <SNAME, SCLASS> but does contain an RRset that matches
+      <SNAME, SCLASS, STYPE> via wildcard name expansion.
+
+   Wildcard No Data: The zone does not contain any RRsets that exactly
+      match <SNAME, SCLASS> and does contain one or more RRsets that
+      match <SNAME, SCLASS> via wildcard name expansion, but does not
+      contain any RRsets that match <SNAME, SCLASS, STYPE> via wildcard
+      name expansion.
+
+   In each of these cases, the name server includes NSEC RRs in the
+   response to prove that an exact match for <SNAME, SCLASS, STYPE> was
+   not present in the zone and that the response that the name server is
+   returning is correct given the data in the zone.
+
+
+
+
+
+
+
+
+
+Arends, et al.              Standards Track                    [Page 11]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+3.1.3.1.  Including NSEC RRs: No Data Response
+
+   If the zone contains RRsets matching <SNAME, SCLASS> but contains no
+   RRset matching <SNAME, SCLASS, STYPE>, then the name server MUST
+   include the NSEC RR for <SNAME, SCLASS> along with its associated
+   RRSIG RR(s) in the Authority section of the response (see Section
+   3.1.1).  If space does not permit inclusion of the NSEC RR or its
+   associated RRSIG RR(s), the name server MUST set the TC bit (see
+   Section 3.1.1).
+
+   Since the search name exists, wildcard name expansion does not apply
+   to this query, and a single signed NSEC RR suffices to prove that the
+   requested RR type does not exist.
+
+3.1.3.2.  Including NSEC RRs: Name Error Response
+
+   If the zone does not contain any RRsets matching <SNAME, SCLASS>
+   either exactly or via wildcard name expansion, then the name server
+   MUST include the following NSEC RRs in the Authority section, along
+   with their associated RRSIG RRs:
+
+   o  An NSEC RR proving that there is no exact match for <SNAME,
+      SCLASS>.
+
+   o  An NSEC RR proving that the zone contains no RRsets that would
+      match <SNAME, SCLASS> via wildcard name expansion.
+
+   In some cases, a single NSEC RR may prove both of these points.  If
+   it does, the name server SHOULD only include the NSEC RR and its
+   RRSIG RR(s) once in the Authority section.
+
+   If space does not permit inclusion of these NSEC and RRSIG RRs, the
+   name server MUST set the TC bit (see Section 3.1.1).
+
+   The owner names of these NSEC and RRSIG RRs are not subject to
+   wildcard name expansion when these RRs are included in the Authority
+   section of the response.
+
+   Note that this form of response includes cases in which SNAME
+   corresponds to an empty non-terminal name within the zone (a name
+   that is not the owner name for any RRset but that is the parent name
+   of one or more RRsets).
+
+3.1.3.3.  Including NSEC RRs: Wildcard Answer Response
+
+   If the zone does not contain any RRsets that exactly match <SNAME,
+   SCLASS> but does contain an RRset that matches <SNAME, SCLASS, STYPE>
+   via wildcard name expansion, the name server MUST include the
+
+
+
+Arends, et al.              Standards Track                    [Page 12]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+   wildcard-expanded answer and the corresponding wildcard-expanded
+   RRSIG RRs in the Answer section and MUST include in the Authority
+   section an NSEC RR and associated RRSIG RR(s) proving that the zone
+   does not contain a closer match for <SNAME, SCLASS>.  If space does
+   not permit inclusion of the answer, NSEC and RRSIG RRs, the name
+   server MUST set the TC bit (see Section 3.1.1).
+
+3.1.3.4.  Including NSEC RRs: Wildcard No Data Response
+
+   This case is a combination of the previous cases.  The zone does not
+   contain an exact match for <SNAME, SCLASS>, and although the zone
+   does contain RRsets that match <SNAME, SCLASS> via wildcard
+   expansion, none of those RRsets matches STYPE.  The name server MUST
+   include the following NSEC RRs in the Authority section, along with
+   their associated RRSIG RRs:
+
+   o  An NSEC RR proving that there are no RRsets matching STYPE at the
+      wildcard owner name that matched <SNAME, SCLASS> via wildcard
+      expansion.
+
+   o  An NSEC RR proving that there are no RRsets in the zone that would
+      have been a closer match for <SNAME, SCLASS>.
+
+   In some cases, a single NSEC RR may prove both of these points.  If
+   it does, the name server SHOULD only include the NSEC RR and its
+   RRSIG RR(s) once in the Authority section.
+
+   The owner names of these NSEC and RRSIG RRs are not subject to
+   wildcard name expansion when these RRs are included in the Authority
+   section of the response.
+
+   If space does not permit inclusion of these NSEC and RRSIG RRs, the
+   name server MUST set the TC bit (see Section 3.1.1).
+
+3.1.3.5.  Finding the Right NSEC RRs
+
+   As explained above, there are several situations in which a
+   security-aware authoritative name server has to locate an NSEC RR
+   that proves that no RRsets matching a particular SNAME exist.
+   Locating such an NSEC RR within an authoritative zone is relatively
+   simple, at least in concept.  The following discussion assumes that
+   the name server is authoritative for the zone that would have held
+   the non-existent RRsets matching SNAME.  The algorithm below is
+   written for clarity, not for efficiency.
+
+   To find the NSEC that proves that no RRsets matching name N exist in
+   the zone Z that would have held them, construct a sequence, S,
+   consisting of the owner names of every RRset in Z, sorted into
+
+
+
+Arends, et al.              Standards Track                    [Page 13]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+   canonical order ([RFC4034]), with no duplicate names.  Find the name
+   M that would have immediately preceded N in S if any RRsets with
+   owner name N had existed.  M is the owner name of the NSEC RR that
+   proves that no RRsets exist with owner name N.
+
+   The algorithm for finding the NSEC RR that proves that a given name
+   is not covered by any applicable wildcard is similar but requires an
+   extra step.  More precisely, the algorithm for finding the NSEC
+   proving that no RRsets exist with the applicable wildcard name is
+   precisely the same as the algorithm for finding the NSEC RR that
+   proves that RRsets with any other owner name do not exist.  The part
+   that's missing is a method of determining the name of the non-
+   existent applicable wildcard.  In practice, this is easy, because the
+   authoritative name server has already checked for the presence of
+   precisely this wildcard name as part of step (1)(c) of the normal
+   lookup algorithm described in Section 4.3.2 of [RFC1034].
+
+3.1.4.  Including DS RRs in a Response
+
+   When responding to a query that has the DO bit set, a security-aware
+   authoritative name server returning a referral includes DNSSEC data
+   along with the NS RRset.
+
+   If a DS RRset is present at the delegation point, the name server
+   MUST return both the DS RRset and its associated RRSIG RR(s) in the
+   Authority section along with the NS RRset.
+
+   If no DS RRset is present at the delegation point, the name server
+   MUST return both the NSEC RR that proves that the DS RRset is not
+   present and the NSEC RR's associated RRSIG RR(s) along with the NS
+   RRset.  The name server MUST place the NS RRset before the NSEC RRset
+   and its associated RRSIG RR(s).
+
+   Including these DS, NSEC, and RRSIG RRs increases the size of
+   referral messages and may cause some or all glue RRs to be omitted.
+   If space does not permit inclusion of the DS or NSEC RRset and
+   associated RRSIG RRs, the name server MUST set the TC bit (see
+   Section 3.1.1).
+
+3.1.4.1.  Responding to Queries for DS RRs
+
+   The DS resource record type is unusual in that it appears only on the
+   parent zone's side of a zone cut.  For example, the DS RRset for the
+   delegation of "foo.example" is stored in the "example" zone rather
+   than in the "foo.example" zone.  This requires special processing
+   rules for both name servers and resolvers, as the name server for the
+   child zone is authoritative for the name at the zone cut by the
+   normal DNS rules but the child zone does not contain the DS RRset.
+
+
+
+Arends, et al.              Standards Track                    [Page 14]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+   A security-aware resolver sends queries to the parent zone when
+   looking for a needed DS RR at a delegation point (see Section 4.2).
+   However, special rules are necessary to avoid confusing
+   security-oblivious resolvers which might become involved in
+   processing such a query (for example, in a network configuration that
+   forces a security-aware resolver to channel its queries through a
+   security-oblivious recursive name server).  The rest of this section
+   describes how a security-aware name server processes DS queries in
+   order to avoid this problem.
+
+   The need for special processing by a security-aware name server only
+   arises when all the following conditions are met:
+
+   o  The name server has received a query for the DS RRset at a zone
+      cut.
+
+   o  The name server is authoritative for the child zone.
+
+   o  The name server is not authoritative for the parent zone.
+
+   o  The name server does not offer recursion.
+
+   In all other cases, the name server either has some way of obtaining
+   the DS RRset or could not have been expected to have the DS RRset
+   even by the pre-DNSSEC processing rules, so the name server can
+   return either the DS RRset or an error response according to the
+   normal processing rules.
+
+   If all the above conditions are met, however, the name server is
+   authoritative for SNAME but cannot supply the requested RRset.  In
+   this case, the name server MUST return an authoritative "no data"
+   response showing that the DS RRset does not exist in the child zone's
+   apex.  See Appendix B.8 for an example of such a response.
+
+3.1.5.  Responding to Queries for Type AXFR or IXFR
+
+   DNSSEC does not change the DNS zone transfer process.  A signed zone
+   will contain RRSIG, DNSKEY, NSEC, and DS resource records, but these
+   records have no special meaning with respect to a zone transfer
+   operation.
+
+   An authoritative name server is not required to verify that a zone is
+   properly signed before sending or accepting a zone transfer.
+   However, an authoritative name server MAY choose to reject the entire
+   zone transfer if the zone fails to meet any of the signing
+   requirements described in Section 2.  The primary objective of a zone
+   transfer is to ensure that all authoritative name servers have
+   identical copies of the zone.  An authoritative name server that
+
+
+
+Arends, et al.              Standards Track                    [Page 15]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+   chooses to perform its own zone validation MUST NOT selectively
+   reject some RRs and accept others.
+
+   DS RRsets appear only on the parental side of a zone cut and are
+   authoritative data in the parent zone.  As with any other
+   authoritative RRset, the DS RRset MUST be included in zone transfers
+   of the zone in which the RRset is authoritative data.  In the case of
+   the DS RRset, this is the parent zone.
+
+   NSEC RRs appear in both the parent and child zones at a zone cut and
+   are authoritative data in both the parent and child zones.  The
+   parental and child NSEC RRs at a zone cut are never identical to each
+   other, as the NSEC RR in the child zone's apex will always indicate
+   the presence of the child zone's SOA RR whereas the parental NSEC RR
+   at the zone cut will never indicate the presence of an SOA RR.  As
+   with any other authoritative RRs, NSEC RRs MUST be included in zone
+   transfers of the zone in which they are authoritative data.  The
+   parental NSEC RR at a zone cut MUST be included in zone transfers of
+   the parent zone, and the NSEC at the zone apex of the child zone MUST
+   be included in zone transfers of the child zone.
+
+   RRSIG RRs appear in both the parent and child zones at a zone cut and
+   are authoritative in whichever zone contains the authoritative RRset
+   for which the RRSIG RR provides the signature.  That is, the RRSIG RR
+   for a DS RRset or a parental NSEC RR at a zone cut will be
+   authoritative in the parent zone, and the RRSIG for any RRset in the
+   child zone's apex will be authoritative in the child zone.  Parental
+   and child RRSIG RRs at a zone cut will never be identical to each
+   other, as the Signer's Name field of an RRSIG RR in the child zone's
+   apex will indicate a DNSKEY RR in the child zone's apex whereas the
+   same field of a parental RRSIG RR at the zone cut will indicate a
+   DNSKEY RR in the parent zone's apex.  As with any other authoritative
+   RRs, RRSIG RRs MUST be included in zone transfers of the zone in
+   which they are authoritative data.
+
+3.1.6.  The AD and CD Bits in an Authoritative Response
+
+   The CD and AD bits are designed for use in communication between
+   security-aware resolvers and security-aware recursive name servers.
+   These bits are for the most part not relevant to query processing by
+   security-aware authoritative name servers.
+
+   A security-aware name server does not perform signature validation
+   for authoritative data during query processing, even when the CD bit
+   is clear.  A security-aware name server SHOULD clear the CD bit when
+   composing an authoritative response.
+
+
+
+
+
+Arends, et al.              Standards Track                    [Page 16]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+   A security-aware name server MUST NOT set the AD bit in a response
+   unless the name server considers all RRsets in the Answer and
+   Authority sections of the response to be authentic.  A security-aware
+   name server's local policy MAY consider data from an authoritative
+   zone to be authentic without further validation.  However, the name
+   server MUST NOT do so unless the name server obtained the
+   authoritative zone via secure means (such as a secure zone transfer
+   mechanism) and MUST NOT do so unless this behavior has been
+   configured explicitly.
+
+   A security-aware name server that supports recursion MUST follow the
+   rules for the CD and AD bits given in Section 3.2 when generating a
+   response that involves data obtained via recursion.
+
+3.2.  Recursive Name Servers
+
+   As explained in [RFC4033], a security-aware recursive name server is
+   an entity that acts in both the security-aware name server and
+   security-aware resolver roles.  This section uses the terms "name
+   server side" and "resolver side" to refer to the code within a
+   security-aware recursive name server that implements the
+   security-aware name server role and the code that implements the
+   security-aware resolver role, respectively.
+
+   The resolver side follows the usual rules for caching and negative
+   caching that would apply to any security-aware resolver.
+
+3.2.1.  The DO Bit
+
+   The resolver side of a security-aware recursive name server MUST set
+   the DO bit when sending requests, regardless of the state of the DO
+   bit in the initiating request received by the name server side.  If
+   the DO bit in an initiating query is not set, the name server side
+   MUST strip any authenticating DNSSEC RRs from the response but MUST
+   NOT strip any DNSSEC RR types that the initiating query explicitly
+   requested.
+
+3.2.2.  The CD Bit
+
+   The CD bit exists in order to allow a security-aware resolver to
+   disable signature validation in a security-aware name server's
+   processing of a particular query.
+
+   The name server side MUST copy the setting of the CD bit from a query
+   to the corresponding response.
+
+   The name server side of a security-aware recursive name server MUST
+   pass the state of the CD bit to the resolver side along with the rest
+
+
+
+Arends, et al.              Standards Track                    [Page 17]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+   of an initiating query, so that the resolver side will know whether
+   it is required to verify the response data it returns to the name
+   server side.  If the CD bit is set, it indicates that the originating
+   resolver is willing to perform whatever authentication its local
+   policy requires.  Thus, the resolver side of the recursive name
+   server need not perform authentication on the RRsets in the response.
+   When the CD bit is set, the recursive name server SHOULD, if
+   possible, return the requested data to the originating resolver, even
+   if the recursive name server's local authentication policy would
+   reject the records in question.  That is, by setting the CD bit, the
+   originating resolver has indicated that it takes responsibility for
+   performing its own authentication, and the recursive name server
+   should not interfere.
+
+   If the resolver side implements a BAD cache (see Section 4.7) and the
+   name server side receives a query that matches an entry in the
+   resolver side's BAD cache, the name server side's response depends on
+   the state of the CD bit in the original query.  If the CD bit is set,
+   the name server side SHOULD return the data from the BAD cache; if
+   the CD bit is not set, the name server side MUST return RCODE 2
+   (server failure).
+
+   The intent of the above rule is to provide the raw data to clients
+   that are capable of performing their own signature verification
+   checks while protecting clients that depend on the resolver side of a
+   security-aware recursive name server to perform such checks.  Several
+   of the possible reasons why signature validation might fail involve
+   conditions that may not apply equally to the recursive name server
+   and the client that invoked it.  For example, the recursive name
+   server's clock may be set incorrectly, or the client may have
+   knowledge of a relevant island of security that the recursive name
+   server does not share.  In such cases, "protecting" a client that is
+   capable of performing its own signature validation from ever seeing
+   the "bad" data does not help the client.
+
+3.2.3.  The AD Bit
+
+   The name server side of a security-aware recursive name server MUST
+   NOT set the AD bit in a response unless the name server considers all
+   RRsets in the Answer and Authority sections of the response to be
+   authentic.  The name server side SHOULD set the AD bit if and only if
+   the resolver side considers all RRsets in the Answer section and any
+   relevant negative response RRs in the Authority section to be
+   authentic.  The resolver side MUST follow the procedure described in
+   Section 5 to determine whether the RRs in question are authentic.
+   However, for backward compatibility, a recursive name server MAY set
+   the AD bit when a response includes unsigned CNAME RRs if those CNAME
+
+
+
+
+Arends, et al.              Standards Track                    [Page 18]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+   RRs demonstrably could have been synthesized from an authentic DNAME
+   RR that is also included in the response according to the synthesis
+   rules described in [RFC2672].
+
+3.3.  Example DNSSEC Responses
+
+   See Appendix B for example response packets.
+
+4.  Resolving
+
+   This section describes the behavior of entities that include
+   security-aware resolver functions.  In many cases such functions will
+   be part of a security-aware recursive name server, but a stand-alone
+   security-aware resolver has many of the same requirements.  Functions
+   specific to security-aware recursive name servers are described in
+   Section 3.2.
+
+4.1.  EDNS Support
+
+   A security-aware resolver MUST include an EDNS ([RFC2671]) OPT
+   pseudo-RR with the DO ([RFC3225]) bit set when sending queries.
+
+   A security-aware resolver MUST support a message size of at least
+   1220 octets, SHOULD support a message size of 4000 octets, and MUST
+   use the "sender's UDP payload size" field in the EDNS OPT pseudo-RR
+   to advertise the message size that it is willing to accept.  A
+   security-aware resolver's IP layer MUST handle fragmented UDP packets
+   correctly regardless of whether any such fragmented packets were
+   received via IPv4 or IPv6.  Please see [RFC1122], [RFC2460], and
+   [RFC3226] for discussion of these requirements.
+
+4.2.  Signature Verification Support
+
+   A security-aware resolver MUST support the signature verification
+   mechanisms described in Section 5 and SHOULD apply them to every
+   received response, except when:
+
+   o  the security-aware resolver is part of a security-aware recursive
+      name server, and the response is the result of recursion on behalf
+      of a query received with the CD bit set;
+
+   o  the response is the result of a query generated directly via some
+      form of application interface that instructed the security-aware
+      resolver not to perform validation for this query; or
+
+   o  validation for this query has been disabled by local policy.
+
+
+
+
+
+Arends, et al.              Standards Track                    [Page 19]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+   A security-aware resolver's support for signature verification MUST
+   include support for verification of wildcard owner names.
+
+   Security-aware resolvers MAY query for missing security RRs in an
+   attempt to perform validation; implementations that choose to do so
+   must be aware that the answers received may not be sufficient to
+   validate the original response.  For example, a zone update may have
+   changed (or deleted) the desired information between the original and
+   follow-up queries.
+
+   When attempting to retrieve missing NSEC RRs that reside on the
+   parental side at a zone cut, a security-aware iterative-mode resolver
+   MUST query the name servers for the parent zone, not the child zone.
+
+   When attempting to retrieve a missing DS, a security-aware
+   iterative-mode resolver MUST query the name servers for the parent
+   zone, not the child zone.  As explained in Section 3.1.4.1,
+   security-aware name servers need to apply special processing rules to
+   handle the DS RR, and in some situations the resolver may also need
+   to apply special rules to locate the name servers for the parent zone
+   if the resolver does not already have the parent's NS RRset.  To
+   locate the parent NS RRset, the resolver can start with the
+   delegation name, strip off the leftmost label, and query for an NS
+   RRset by that name.  If no NS RRset is present at that name, the
+   resolver then strips off the leftmost remaining label and retries the
+   query for that name, repeating this process of walking up the tree
+   until it either finds the NS RRset or runs out of labels.
+
+4.3.  Determining Security Status of Data
+
+   A security-aware resolver MUST be able to determine whether it should
+   expect a particular RRset to be signed.  More precisely, a
+   security-aware resolver must be able to distinguish between four
+   cases:
+
+   Secure: An RRset for which the resolver is able to build a chain of
+      signed DNSKEY and DS RRs from a trusted security anchor to the
+      RRset.  In this case, the RRset should be signed and is subject to
+      signature validation, as described above.
+
+   Insecure: An RRset for which the resolver knows that it has no chain
+      of signed DNSKEY and DS RRs from any trusted starting point to the
+      RRset.  This can occur when the target RRset lies in an unsigned
+      zone or in a descendent of an unsigned zone.  In this case, the
+      RRset may or may not be signed, but the resolver will not be able
+      to verify the signature.
+
+
+
+
+
+Arends, et al.              Standards Track                    [Page 20]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+   Bogus: An RRset for which the resolver believes that it ought to be
+      able to establish a chain of trust but for which it is unable to
+      do so, either due to signatures that for some reason fail to
+      validate or due to missing data that the relevant DNSSEC RRs
+      indicate should be present.  This case may indicate an attack but
+      may also indicate a configuration error or some form of data
+      corruption.
+
+   Indeterminate: An RRset for which the resolver is not able to
+      determine whether the RRset should be signed, as the resolver is
+      not able to obtain the necessary DNSSEC RRs.  This can occur when
+      the security-aware resolver is not able to contact security-aware
+      name servers for the relevant zones.
+
+4.4.  Configured Trust Anchors
+
+   A security-aware resolver MUST be capable of being configured with at
+   least one trusted public key or DS RR and SHOULD be capable of being
+   configured with multiple trusted public keys or DS RRs.  Since a
+   security-aware resolver will not be able to validate signatures
+   without such a configured trust anchor, the resolver SHOULD have some
+   reasonably robust mechanism for obtaining such keys when it boots;
+   examples of such a mechanism would be some form of non-volatile
+   storage (such as a disk drive) or some form of trusted local network
+   configuration mechanism.
+
+   Note that trust anchors also cover key material that is updated in a
+   secure manner.  This secure manner could be through physical media, a
+   key exchange protocol, or some other out-of-band means.
+
+4.5.  Response Caching
+
+   A security-aware resolver SHOULD cache each response as a single
+   atomic entry containing the entire answer, including the named RRset
+   and any associated DNSSEC RRs.  The resolver SHOULD discard the
+   entire atomic entry when any of the RRs contained in it expire.  In
+   most cases the appropriate cache index for the atomic entry will be
+   the triple <QNAME, QTYPE, QCLASS>, but in cases such as the response
+   form described in Section 3.1.3.2 the appropriate cache index will be
+   the double <QNAME,QCLASS>.
+
+   The reason for these recommendations is that, between the initial
+   query and the expiration of the data from the cache, the
+   authoritative data might have been changed (for example, via dynamic
+   update).
+
+
+
+
+
+
+Arends, et al.              Standards Track                    [Page 21]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+   There are two situations for which this is relevant:
+
+   1.  By using the RRSIG record, it is possible to deduce that an
+       answer was synthesized from a wildcard.  A security-aware
+       recursive name server could store this wildcard data and use it
+       to generate positive responses to queries other than the name for
+       which the original answer was first received.
+
+   2.  NSEC RRs received to prove the non-existence of a name could be
+       reused by a security-aware resolver to prove the non-existence of
+       any name in the name range it spans.
+
+   In theory, a resolver could use wildcards or NSEC RRs to generate
+   positive and negative responses (respectively) until the TTL or
+   signatures on the records in question expire.  However, it seems
+   prudent for resolvers to avoid blocking new authoritative data or
+   synthesizing new data on their own.  Resolvers that follow this
+   recommendation will have a more consistent view of the namespace.
+
+4.6.  Handling of the CD and AD Bits
+
+   A security-aware resolver MAY set a query's CD bit in order to
+   indicate that the resolver takes responsibility for performing
+   whatever authentication its local policy requires on the RRsets in
+   the response.  See Section 3.2 for the effect this bit has on the
+   behavior of security-aware recursive name servers.
+
+   A security-aware resolver MUST clear the AD bit when composing query
+   messages to protect against buggy name servers that blindly copy
+   header bits that they do not understand from the query message to the
+   response message.
+
+   A resolver MUST disregard the meaning of the CD and AD bits in a
+   response unless the response was obtained by using a secure channel
+   or the resolver was specifically configured to regard the message
+   header bits without using a secure channel.
+
+4.7.  Caching BAD Data
+
+   While many validation errors will be transient, some are likely to be
+   more persistent, such as those caused by administrative error
+   (failure to re-sign a zone, clock skew, and so forth).  Since
+   requerying will not help in these cases, validating resolvers might
+   generate a significant amount of unnecessary DNS traffic as a result
+   of repeated queries for RRsets with persistent validation failures.
+
+   To prevent such unnecessary DNS traffic, security-aware resolvers MAY
+   cache data with invalid signatures, with some restrictions.
+
+
+
+Arends, et al.              Standards Track                    [Page 22]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+   Conceptually, caching such data is similar to negative caching
+   ([RFC2308]), except that instead of caching a valid negative
+   response, the resolver is caching the fact that a particular answer
+   failed to validate.  This document refers to a cache of data with
+   invalid signatures as a "BAD cache".
+
+   Resolvers that implement a BAD cache MUST take steps to prevent the
+   cache from being useful as a denial-of-service attack amplifier,
+   particularly the following:
+
+   o  Since RRsets that fail to validate do not have trustworthy TTLs,
+      the implementation MUST assign a TTL.  This TTL SHOULD be small,
+      in order to mitigate the effect of caching the results of an
+      attack.
+
+   o  In order to prevent caching of a transient validation failure
+      (which might be the result of an attack), resolvers SHOULD track
+      queries that result in validation failures and SHOULD only answer
+      from the BAD cache after the number of times that responses to
+      queries for that particular <QNAME, QTYPE, QCLASS> have failed to
+      validate exceeds a threshold value.
+
+   Resolvers MUST NOT return RRsets from the BAD cache unless the
+   resolver is not required to validate the signatures of the RRsets in
+   question under the rules given in Section 4.2 of this document.  See
+   Section 3.2.2 for discussion of how the responses returned by a
+   security-aware recursive name server interact with a BAD cache.
+
+4.8.  Synthesized CNAMEs
+
+   A validating security-aware resolver MUST treat the signature of a
+   valid signed DNAME RR as also covering unsigned CNAME RRs that could
+   have been synthesized from the DNAME RR, as described in [RFC2672],
+   at least to the extent of not rejecting a response message solely
+   because it contains such CNAME RRs.  The resolver MAY retain such
+   CNAME RRs in its cache or in the answers it hands back, but is not
+   required to do so.
+
+4.9.  Stub Resolvers
+
+   A security-aware stub resolver MUST support the DNSSEC RR types, at
+   least to the extent of not mishandling responses just because they
+   contain DNSSEC RRs.
+
+
+
+
+
+
+
+
+Arends, et al.              Standards Track                    [Page 23]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+4.9.1.  Handling of the DO Bit
+
+   A non-validating security-aware stub resolver MAY include the DNSSEC
+   RRs returned by a security-aware recursive name server as part of the
+   data that the stub resolver hands back to the application that
+   invoked it, but is not required to do so.  A non-validating stub
+   resolver that seeks to do this will need to set the DO bit in order
+   to receive DNSSEC RRs from the recursive name server.
+
+   A validating security-aware stub resolver MUST set the DO bit,
+   because otherwise it will not receive the DNSSEC RRs it needs to
+   perform signature validation.
+
+4.9.2.  Handling of the CD Bit
+
+   A non-validating security-aware stub resolver SHOULD NOT set the CD
+   bit when sending queries unless it is requested by the application
+   layer, as by definition, a non-validating stub resolver depends on
+   the security-aware recursive name server to perform validation on its
+   behalf.
+
+   A validating security-aware stub resolver SHOULD set the CD bit,
+   because otherwise the security-aware recursive name server will
+   answer the query using the name server's local policy, which may
+   prevent the stub resolver from receiving data that would be
+   acceptable to the stub resolver's local policy.
+
+4.9.3.  Handling of the AD Bit
+
+   A non-validating security-aware stub resolver MAY chose to examine
+   the setting of the AD bit in response messages that it receives in
+   order to determine whether the security-aware recursive name server
+   that sent the response claims to have cryptographically verified the
+   data in the Answer and Authority sections of the response message.
+   Note, however, that the responses received by a security-aware stub
+   resolver are heavily dependent on the local policy of the
+   security-aware recursive name server.  Therefore, there may be little
+   practical value in checking the status of the AD bit, except perhaps
+   as a debugging aid.  In any case, a security-aware stub resolver MUST
+   NOT place any reliance on signature validation allegedly performed on
+   its behalf, except when the security-aware stub resolver obtained the
+   data in question from a trusted security-aware recursive name server
+   via a secure channel.
+
+   A validating security-aware stub resolver SHOULD NOT examine the
+   setting of the AD bit in response messages, as, by definition, the
+   stub resolver performs its own signature validation regardless of the
+   setting of the AD bit.
+
+
+
+Arends, et al.              Standards Track                    [Page 24]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+5.  Authenticating DNS Responses
+
+   To use DNSSEC RRs for authentication, a security-aware resolver
+   requires configured knowledge of at least one authenticated DNSKEY or
+   DS RR.  The process for obtaining and authenticating this initial
+   trust anchor is achieved via some external mechanism.  For example, a
+   resolver could use some off-line authenticated exchange to obtain a
+   zone's DNSKEY RR or to obtain a DS RR that identifies and
+   authenticates a zone's DNSKEY RR.  The remainder of this section
+   assumes that the resolver has somehow obtained an initial set of
+   trust anchors.
+
+   An initial DNSKEY RR can be used to authenticate a zone's apex DNSKEY
+   RRset.  To authenticate an apex DNSKEY RRset by using an initial key,
+   the resolver MUST:
+
+   1.  verify that the initial DNSKEY RR appears in the apex DNSKEY
+       RRset, and that the DNSKEY RR has the Zone Key Flag (DNSKEY RDATA
+       bit 7) set; and
+
+   2.  verify that there is some RRSIG RR that covers the apex DNSKEY
+       RRset, and that the combination of the RRSIG RR and the initial
+       DNSKEY RR authenticates the DNSKEY RRset.  The process for using
+       an RRSIG RR to authenticate an RRset is described in Section 5.3.
+
+   Once the resolver has authenticated the apex DNSKEY RRset by using an
+   initial DNSKEY RR, delegations from that zone can be authenticated by
+   using DS RRs.  This allows a resolver to start from an initial key
+   and use DS RRsets to proceed recursively down the DNS tree, obtaining
+   other apex DNSKEY RRsets.  If the resolver were configured with a
+   root DNSKEY RR, and if every delegation had a DS RR associated with
+   it, then the resolver could obtain and validate any apex DNSKEY
+   RRset.  The process of using DS RRs to authenticate referrals is
+   described in Section 5.2.
+
+   Section 5.3 shows how the resolver can use DNSKEY RRs in the apex
+   DNSKEY RRset and RRSIG RRs from the zone to authenticate any other
+   RRsets in the zone once the resolver has authenticated a zone's apex
+   DNSKEY RRset.  Section 5.4 shows how the resolver can use
+   authenticated NSEC RRsets from the zone to prove that an RRset is not
+   present in the zone.
+
+   When a resolver indicates support for DNSSEC (by setting the DO bit),
+   a security-aware name server should attempt to provide the necessary
+   DNSKEY, RRSIG, NSEC, and DS RRsets in a response (see Section 3).
+   However, a security-aware resolver may still receive a response that
+   lacks the appropriate DNSSEC RRs, whether due to configuration issues
+   such as an upstream security-oblivious recursive name server that
+
+
+
+Arends, et al.              Standards Track                    [Page 25]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+   accidentally interferes with DNSSEC RRs or due to a deliberate attack
+   in which an adversary forges a response, strips DNSSEC RRs from a
+   response, or modifies a query so that DNSSEC RRs appear not to be
+   requested.  The absence of DNSSEC data in a response MUST NOT by
+   itself be taken as an indication that no authentication information
+   exists.
+
+   A resolver SHOULD expect authentication information from signed
+   zones.  A resolver SHOULD believe that a zone is signed if the
+   resolver has been configured with public key information for the
+   zone, or if the zone's parent is signed and the delegation from the
+   parent contains a DS RRset.
+
+5.1.  Special Considerations for Islands of Security
+
+   Islands of security (see [RFC4033]) are signed zones for which it is
+   not possible to construct an authentication chain to the zone from
+   its parent.  Validating signatures within an island of security
+   requires that the validator have some other means of obtaining an
+   initial authenticated zone key for the island.  If a validator cannot
+   obtain such a key, it SHOULD switch to operating as if the zones in
+   the island of security are unsigned.
+
+   All the normal processes for validating responses apply to islands of
+   security.  The only difference between normal validation and
+   validation within an island of security is in how the validator
+   obtains a trust anchor for the authentication chain.
+
+5.2.  Authenticating Referrals
+
+   Once the apex DNSKEY RRset for a signed parent zone has been
+   authenticated, DS RRsets can be used to authenticate the delegation
+   to a signed child zone.  A DS RR identifies a DNSKEY RR in the child
+   zone's apex DNSKEY RRset and contains a cryptographic digest of the
+   child zone's DNSKEY RR.  Use of a strong cryptographic digest
+   algorithm ensures that it is computationally infeasible for an
+   adversary to generate a DNSKEY RR that matches the digest.  Thus,
+   authenticating the digest allows a resolver to authenticate the
+   matching DNSKEY RR.  The resolver can then use this child DNSKEY RR
+   to authenticate the entire child apex DNSKEY RRset.
+
+   Given a DS RR for a delegation, the child zone's apex DNSKEY RRset
+   can be authenticated if all of the following hold:
+
+   o  The DS RR has been authenticated using some DNSKEY RR in the
+      parent's apex DNSKEY RRset (see Section 5.3).
+
+
+
+
+
+Arends, et al.              Standards Track                    [Page 26]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+   o  The Algorithm and Key Tag in the DS RR match the Algorithm field
+      and the key tag of a DNSKEY RR in the child zone's apex DNSKEY
+      RRset, and, when the DNSKEY RR's owner name and RDATA are hashed
+      using the digest algorithm specified in the DS RR's Digest Type
+      field, the resulting digest value matches the Digest field of the
+      DS RR.
+
+   o  The matching DNSKEY RR in the child zone has the Zone Flag bit
+      set, the corresponding private key has signed the child zone's
+      apex DNSKEY RRset, and the resulting RRSIG RR authenticates the
+      child zone's apex DNSKEY RRset.
+
+   If the referral from the parent zone did not contain a DS RRset, the
+   response should have included a signed NSEC RRset proving that no DS
+   RRset exists for the delegated name (see Section 3.1.4).  A
+   security-aware resolver MUST query the name servers for the parent
+   zone for the DS RRset if the referral includes neither a DS RRset nor
+   a NSEC RRset proving that the DS RRset does not exist (see Section
+   4).
+
+   If the validator authenticates an NSEC RRset that proves that no DS
+   RRset is present for this zone, then there is no authentication path
+   leading from the parent to the child.  If the resolver has an initial
+   DNSKEY or DS RR that belongs to the child zone or to any delegation
+   below the child zone, this initial DNSKEY or DS RR MAY be used to
+   re-establish an authentication path.  If no such initial DNSKEY or DS
+   RR exists, the validator cannot authenticate RRsets in or below the
+   child zone.
+
+   If the validator does not support any of the algorithms listed in an
+   authenticated DS RRset, then the resolver has no supported
+   authentication path leading from the parent to the child.  The
+   resolver should treat this case as it would the case of an
+   authenticated NSEC RRset proving that no DS RRset exists, as
+   described above.
+
+   Note that, for a signed delegation, there are two NSEC RRs associated
+   with the delegated name.  One NSEC RR resides in the parent zone and
+   can be used to prove whether a DS RRset exists for the delegated
+   name.  The second NSEC RR resides in the child zone and identifies
+   which RRsets are present at the apex of the child zone.  The parent
+   NSEC RR and child NSEC RR can always be distinguished because the SOA
+   bit will be set in the child NSEC RR and clear in the parent NSEC RR.
+   A security-aware resolver MUST use the parent NSEC RR when attempting
+   to prove that a DS RRset does not exist.
+
+
+
+
+
+
+Arends, et al.              Standards Track                    [Page 27]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+   If the resolver does not support any of the algorithms listed in an
+   authenticated DS RRset, then the resolver will not be able to verify
+   the authentication path to the child zone.  In this case, the
+   resolver SHOULD treat the child zone as if it were unsigned.
+
+5.3.  Authenticating an RRset with an RRSIG RR
+
+   A validator can use an RRSIG RR and its corresponding DNSKEY RR to
+   attempt to authenticate RRsets.  The validator first checks the RRSIG
+   RR to verify that it covers the RRset, has a valid time interval, and
+   identifies a valid DNSKEY RR.  The validator then constructs the
+   canonical form of the signed data by appending the RRSIG RDATA
+   (excluding the Signature Field) with the canonical form of the
+   covered RRset.  Finally, the validator uses the public key and
+   signature to authenticate the signed data.  Sections 5.3.1, 5.3.2,
+   and 5.3.3 describe each step in detail.
+
+5.3.1.  Checking the RRSIG RR Validity
+
+   A security-aware resolver can use an RRSIG RR to authenticate an
+   RRset if all of the following conditions hold:
+
+   o  The RRSIG RR and the RRset MUST have the same owner name and the
+      same class.
+
+   o  The RRSIG RR's Signer's Name field MUST be the name of the zone
+      that contains the RRset.
+
+   o  The RRSIG RR's Type Covered field MUST equal the RRset's type.
+
+   o  The number of labels in the RRset owner name MUST be greater than
+      or equal to the value in the RRSIG RR's Labels field.
+
+   o  The validator's notion of the current time MUST be less than or
+      equal to the time listed in the RRSIG RR's Expiration field.
+
+   o  The validator's notion of the current time MUST be greater than or
+      equal to the time listed in the RRSIG RR's Inception field.
+
+   o  The RRSIG RR's Signer's Name, Algorithm, and Key Tag fields MUST
+      match the owner name, algorithm, and key tag for some DNSKEY RR in
+      the zone's apex DNSKEY RRset.
+
+   o  The matching DNSKEY RR MUST be present in the zone's apex DNSKEY
+      RRset, and MUST have the Zone Flag bit (DNSKEY RDATA Flag bit 7)
+      set.
+
+
+
+
+
+Arends, et al.              Standards Track                    [Page 28]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+   It is possible for more than one DNSKEY RR to match the conditions
+   above.  In this case, the validator cannot predetermine which DNSKEY
+   RR to use to authenticate the signature, and it MUST try each
+   matching DNSKEY RR until either the signature is validated or the
+   validator has run out of matching public keys to try.
+
+   Note that this authentication process is only meaningful if the
+   validator authenticates the DNSKEY RR before using it to validate
+   signatures.  The matching DNSKEY RR is considered to be authentic if:
+
+   o  the apex DNSKEY RRset containing the DNSKEY RR is considered
+      authentic; or
+
+   o  the RRset covered by the RRSIG RR is the apex DNSKEY RRset itself,
+      and the DNSKEY RR either matches an authenticated DS RR from the
+      parent zone or matches a trust anchor.
+
+5.3.2.  Reconstructing the Signed Data
+
+   Once the RRSIG RR has met the validity requirements described in
+   Section 5.3.1, the validator has to reconstruct the original signed
+   data.  The original signed data includes RRSIG RDATA (excluding the
+   Signature field) and the canonical form of the RRset.  Aside from
+   being ordered, the canonical form of the RRset might also differ from
+   the received RRset due to DNS name compression, decremented TTLs, or
+   wildcard expansion.  The validator should use the following to
+   reconstruct the original signed data:
+
+         signed_data = RRSIG_RDATA | RR(1) | RR(2)...  where
+
+            "|" denotes concatenation
+
+            RRSIG_RDATA is the wire format of the RRSIG RDATA fields
+               with the Signature field excluded and the Signer's Name
+               in canonical form.
+
+            RR(i) = name | type | class | OrigTTL | RDATA length | RDATA
+
+               name is calculated according to the function below
+
+               class is the RRset's class
+
+               type is the RRset type and all RRs in the class
+
+               OrigTTL is the value from the RRSIG Original TTL field
+
+               All names in the RDATA field are in canonical form
+
+
+
+
+Arends, et al.              Standards Track                    [Page 29]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+               The set of all RR(i) is sorted into canonical order.
+
+            To calculate the name:
+               let rrsig_labels = the value of the RRSIG Labels field
+
+               let fqdn = RRset's fully qualified domain name in
+                               canonical form
+
+               let fqdn_labels = Label count of the fqdn above.
+
+               if rrsig_labels = fqdn_labels,
+                   name = fqdn
+
+               if rrsig_labels < fqdn_labels,
+                  name = "*." | the rightmost rrsig_label labels of the
+                                fqdn
+
+               if rrsig_labels > fqdn_labels
+                  the RRSIG RR did not pass the necessary validation
+                  checks and MUST NOT be used to authenticate this
+                  RRset.
+
+   The canonical forms for names and RRsets are defined in [RFC4034].
+
+   NSEC RRsets at a delegation boundary require special processing.
+   There are two distinct NSEC RRsets associated with a signed delegated
+   name.  One NSEC RRset resides in the parent zone, and specifies which
+   RRsets are present at the parent zone.  The second NSEC RRset resides
+   at the child zone and identifies which RRsets are present at the apex
+   in the child zone.  The parent NSEC RRset and child NSEC RRset can
+   always be distinguished as only a child NSEC RR will indicate that an
+   SOA RRset exists at the name.  When reconstructing the original NSEC
+   RRset for the delegation from the parent zone, the NSEC RRs MUST NOT
+   be combined with NSEC RRs from the child zone.  When reconstructing
+   the original NSEC RRset for the apex of the child zone, the NSEC RRs
+   MUST NOT be combined with NSEC RRs from the parent zone.
+
+   Note that each of the two NSEC RRsets at a delegation point has a
+   corresponding RRSIG RR with an owner name matching the delegated
+   name, and each of these RRSIG RRs is authoritative data associated
+   with the same zone that contains the corresponding NSEC RRset.  If
+   necessary, a resolver can tell these RRSIG RRs apart by checking the
+   Signer's Name field.
+
+
+
+
+
+
+
+
+Arends, et al.              Standards Track                    [Page 30]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+5.3.3.  Checking the Signature
+
+   Once the resolver has validated the RRSIG RR as described in Section
+   5.3.1 and reconstructed the original signed data as described in
+   Section 5.3.2, the validator can attempt to use the cryptographic
+   signature to authenticate the signed data, and thus (finally!)
+   authenticate the RRset.
+
+   The Algorithm field in the RRSIG RR identifies the cryptographic
+   algorithm used to generate the signature.  The signature itself is
+   contained in the Signature field of the RRSIG RDATA, and the public
+   key used to verify the signature is contained in the Public Key field
+   of the matching DNSKEY RR(s) (found in Section 5.3.1).  [RFC4034]
+   provides a list of algorithm types and provides pointers to the
+   documents that define each algorithm's use.
+
+   Note that it is possible for more than one DNSKEY RR to match the
+   conditions in Section 5.3.1.  In this case, the validator can only
+   determine which DNSKEY RR is correct by trying each matching public
+   key until the validator either succeeds in validating the signature
+   or runs out of keys to try.
+
+   If the Labels field of the RRSIG RR is not equal to the number of
+   labels in the RRset's fully qualified owner name, then the RRset is
+   either invalid or the result of wildcard expansion.  The resolver
+   MUST verify that wildcard expansion was applied properly before
+   considering the RRset to be authentic.  Section 5.3.4 describes how
+   to determine whether a wildcard was applied properly.
+
+   If other RRSIG RRs also cover this RRset, the local resolver security
+   policy determines whether the resolver also has to test these RRSIG
+   RRs and how to resolve conflicts if these RRSIG RRs lead to differing
+   results.
+
+   If the resolver accepts the RRset as authentic, the validator MUST
+   set the TTL of the RRSIG RR and each RR in the authenticated RRset to
+   a value no greater than the minimum of:
+
+   o  the RRset's TTL as received in the response;
+
+   o  the RRSIG RR's TTL as received in the response;
+
+   o  the value in the RRSIG RR's Original TTL field; and
+
+   o  the difference of the RRSIG RR's Signature Expiration time and the
+      current time.
+
+
+
+
+
+Arends, et al.              Standards Track                    [Page 31]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+5.3.4.  Authenticating a Wildcard Expanded RRset Positive Response
+
+   If the number of labels in an RRset's owner name is greater than the
+   Labels field of the covering RRSIG RR, then the RRset and its
+   covering RRSIG RR were created as a result of wildcard expansion.
+   Once the validator has verified the signature, as described in
+   Section 5.3, it must take additional steps to verify the non-
+   existence of an exact match or closer wildcard match for the query.
+   Section 5.4 discusses these steps.
+
+   Note that the response received by the resolver should include all
+   NSEC RRs needed to authenticate the response (see Section 3.1.3).
+
+5.4.  Authenticated Denial of Existence
+
+   A resolver can use authenticated NSEC RRs to prove that an RRset is
+   not present in a signed zone.  Security-aware name servers should
+   automatically include any necessary NSEC RRs for signed zones in
+   their responses to security-aware resolvers.
+
+   Denial of existence is determined by the following rules:
+
+   o  If the requested RR name matches the owner name of an
+      authenticated NSEC RR, then the NSEC RR's type bit map field lists
+      all RR types present at that owner name, and a resolver can prove
+      that the requested RR type does not exist by checking for the RR
+      type in the bit map.  If the number of labels in an authenticated
+      NSEC RR's owner name equals the Labels field of the covering RRSIG
+      RR, then the existence of the NSEC RR proves that wildcard
+      expansion could not have been used to match the request.
+
+   o  If the requested RR name would appear after an authenticated NSEC
+      RR's owner name and before the name listed in that NSEC RR's Next
+      Domain Name field according to the canonical DNS name order
+      defined in [RFC4034], then no RRsets with the requested name exist
+      in the zone.  However, it is possible that a wildcard could be
+      used to match the requested RR owner name and type, so proving
+      that the requested RRset does not exist also requires proving that
+      no possible wildcard RRset exists that could have been used to
+      generate a positive response.
+
+   In addition, security-aware resolvers MUST authenticate the NSEC
+   RRsets that comprise the non-existence proof as described in Section
+   5.3.
+
+   To prove the non-existence of an RRset, the resolver must be able to
+   verify both that the queried RRset does not exist and that no
+   relevant wildcard RRset exists.  Proving this may require more than
+
+
+
+Arends, et al.              Standards Track                    [Page 32]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+   one NSEC RRset from the zone.  If the complete set of necessary NSEC
+   RRsets is not present in a response (perhaps due to message
+   truncation), then a security-aware resolver MUST resend the query in
+   order to attempt to obtain the full collection of NSEC RRs necessary
+   to verify the non-existence of the requested RRset.  As with all DNS
+   operations, however, the resolver MUST bound the work it puts into
+   answering any particular query.
+
+   Since a validated NSEC RR proves the existence of both itself and its
+   corresponding RRSIG RR, a validator MUST ignore the settings of the
+   NSEC and RRSIG bits in an NSEC RR.
+
+5.5.  Resolver Behavior When Signatures Do Not Validate
+
+   If for whatever reason none of the RRSIGs can be validated, the
+   response SHOULD be considered BAD.  If the validation was being done
+   to service a recursive query, the name server MUST return RCODE 2 to
+   the originating client.  However, it MUST return the full response if
+   and only if the original query had the CD bit set.  Also see Section
+   4.7 on caching responses that do not validate.
+
+5.6.  Authentication Example
+
+   Appendix C shows an example of the authentication process.
+
+6.  IANA Considerations
+
+   [RFC4034] contains a review of the IANA considerations introduced by
+   DNSSEC.  The following are additional IANA considerations discussed
+   in this document:
+
+   [RFC2535] reserved the CD and AD bits in the message header.  The
+   meaning of the AD bit was redefined in [RFC3655], and the meaning of
+   both the CD and AD bit are restated in this document.  No new bits in
+   the DNS message header are defined in this document.
+
+   [RFC2671] introduced EDNS, and [RFC3225] reserved the DNSSEC OK bit
+   and defined its use.  The use is restated but not altered in this
+   document.
+
+7.  Security Considerations
+
+   This document describes how the DNS security extensions use public
+   key cryptography to sign and authenticate DNS resource record sets.
+   Please see [RFC4033] for terminology and general security
+   considerations related to DNSSEC; see [RFC4034] for considerations
+   specific to the DNSSEC resource record types.
+
+
+
+
+Arends, et al.              Standards Track                    [Page 33]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+   An active attacker who can set the CD bit in a DNS query message or
+   the AD bit in a DNS response message can use these bits to defeat the
+   protection that DNSSEC attempts to provide to security-oblivious
+   recursive-mode resolvers.  For this reason, use of these control bits
+   by a security-aware recursive-mode resolver requires a secure
+   channel.  See Sections 3.2.2 and 4.9 for further discussion.
+
+   The protocol described in this document attempts to extend the
+   benefits of DNSSEC to security-oblivious stub resolvers.  However, as
+   recovery from validation failures is likely to be specific to
+   particular applications, the facilities that DNSSEC provides for stub
+   resolvers may prove inadequate.  Operators of security-aware
+   recursive name servers will have to pay close attention to the
+   behavior of the applications that use their services when choosing a
+   local validation policy; failure to do so could easily result in the
+   recursive name server accidentally denying service to the clients it
+   is intended to support.
+
+8.  Acknowledgements
+
+   This document was created from the input and ideas of the members of
+   the DNS Extensions Working Group and working group mailing list.  The
+   editors would like to express their thanks for the comments and
+   suggestions received during the revision of these security extension
+   specifications.  Although explicitly listing everyone who has
+   contributed during the decade in which DNSSEC has been under
+   development would be impossible, [RFC4033] includes a list of some of
+   the participants who were kind enough to comment on these documents.
+
+9.  References
+
+9.1.  Normative References
+
+   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
+              STD 13, RFC 1034, November 1987.
+
+   [RFC1035]  Mockapetris, P., "Domain names - implementation and
+              specification", STD 13, RFC 1035, November 1987.
+
+   [RFC1122]  Braden, R., "Requirements for Internet Hosts -
+              Communication Layers", STD 3, RFC 1122, October 1989.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2181]  Elz, R. and R. Bush, "Clarifications to the DNS
+              Specification", RFC 2181, July 1997.
+
+
+
+
+Arends, et al.              Standards Track                    [Page 34]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
+              (IPv6) Specification", RFC 2460, December 1998.
+
+   [RFC2671]  Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
+              2671, August 1999.
+
+   [RFC2672]  Crawford, M., "Non-Terminal DNS Name Redirection", RFC
+              2672, August 1999.
+
+   [RFC3225]  Conrad, D., "Indicating Resolver Support of DNSSEC", RFC
+              3225, December 2001.
+
+   [RFC3226]  Gudmundsson, O., "DNSSEC and IPv6 A6 aware server/resolver
+              message size requirements", RFC 3226, December 2001.
+
+   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
+              Rose, "DNS Security Introduction and Requirements", RFC
+              4033, March 2005.
+
+   [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
+              Rose, "Resource Records for DNS Security Extensions", RFC
+              4034, March 2005.
+
+9.2.  Informative References
+
+   [RFC2308]  Andrews, M., "Negative Caching of DNS Queries (DNS
+              NCACHE)", RFC 2308, March 1998.
+
+   [RFC2535]  Eastlake 3rd, D., "Domain Name System Security
+              Extensions", RFC 2535, March 1999.
+
+   [RFC3007]  Wellington, B., "Secure Domain Name System (DNS) Dynamic
+              Update", RFC 3007, November 2000.
+
+   [RFC3655]  Wellington, B. and O. Gudmundsson, "Redefinition of DNS
+              Authenticated Data (AD) bit", RFC 3655, November 2003.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Arends, et al.              Standards Track                    [Page 35]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+Appendix A.  Signed Zone Example
+
+   The following example shows a (small) complete signed zone.
+
+   example.       3600 IN SOA ns1.example. bugs.x.w.example. (
+                              1081539377
+                              3600
+                              300
+                              3600000
+                              3600
+                              )
+                  3600 RRSIG  SOA 5 1 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h
+                              7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF
+                              vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW
+                              DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB
+                              jV7j86HyQgM5e7+miRAz8V01b0I= )
+                  3600 NS     ns1.example.
+                  3600 NS     ns2.example.
+                  3600 RRSIG  NS 5 1 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd
+                              EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf
+                              4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8
+                              RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48
+                              0HjMeRaZB/FRPGfJPajngcq6Kwg= )
+                  3600 MX     1 xx.example.
+                  3600 RRSIG  MX 5 1 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              HyDHYVT5KHSZ7HtO/vypumPmSZQrcOP3tzWB
+                              2qaKkHVPfau/DgLgS/IKENkYOGL95G4N+NzE
+                              VyNU8dcTOckT+ChPcGeVjguQ7a3Ao9Z/ZkUO
+                              6gmmUW4b89rz1PUxW4jzUxj66PTwoVtUU/iM
+                              W6OISukd1EQt7a0kygkg+PEDxdI= )
+                  3600 NSEC   a.example. NS SOA MX RRSIG NSEC DNSKEY
+                  3600 RRSIG  NSEC 5 1 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              O0k558jHhyrC97ISHnislm4kLMW48C7U7cBm
+                              FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V
+                              Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW
+                              SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm
+                              jfFJ5arXf4nPxp/kEowGgBRzY/U= )
+                  3600 DNSKEY 256 3 5 (
+                              AQOy1bZVvpPqhg4j7EJoM9rI3ZmyEx2OzDBV
+                              rZy/lvI5CQePxXHZS4i8dANH4DX3tbHol61e
+                              k8EFMcsGXxKciJFHyhl94C+NwILQdzsUlSFo
+                              vBZsyl/NX6yEbtw/xN9ZNcrbYvgjjZ/UVPZI
+
+
+
+Arends, et al.              Standards Track                    [Page 36]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+                              ySFNsgEYvh0z2542lzMKR4Dh8uZffQ==
+                              )
+                  3600 DNSKEY 257 3 5 (
+                              AQOeX7+baTmvpVHb2CcLnL1dMRWbuscRvHXl
+                              LnXwDzvqp4tZVKp1sZMepFb8MvxhhW3y/0QZ
+                              syCjczGJ1qk8vJe52iOhInKROVLRwxGpMfzP
+                              RLMlGybr51bOV/1se0ODacj3DomyB4QB5gKT
+                              Yot/K9alk5/j8vfd4jWCWD+E1Sze0Q==
+                              )
+                  3600 RRSIG  DNSKEY 5 1 3600 20040509183619 (
+                              20040409183619 9465 example.
+                              ZxgauAuIj+k1YoVEOSlZfx41fcmKzTFHoweZ
+                              xYnz99JVQZJ33wFS0Q0jcP7VXKkaElXk9nYJ
+                              XevO/7nAbo88iWsMkSpSR6jWzYYKwfrBI/L9
+                              hjYmyVO9m6FjQ7uwM4dCP/bIuV/DKqOAK9NY
+                              NC3AHfvCV1Tp4VKDqxqG7R5tTVM= )
+                  3600 RRSIG  DNSKEY 5 1 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              eGL0s90glUqcOmloo/2y+bSzyEfKVOQViD9Z
+                              DNhLz/Yn9CQZlDVRJffACQDAUhXpU/oP34ri
+                              bKBpysRXosczFrKqS5Oa0bzMOfXCXup9qHAp
+                              eFIku28Vqfr8Nt7cigZLxjK+u0Ws/4lIRjKk
+                              7z5OXogYVaFzHKillDt3HRxHIZM= )
+   a.example.     3600 IN NS  ns1.a.example.
+                  3600 IN NS  ns2.a.example.
+                  3600 DS     57855 5 1 (
+                              B6DCD485719ADCA18E5F3D48A2331627FDD3
+                              636B )
+                  3600 RRSIG  DS 5 2 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              oXIKit/QtdG64J/CB+Gi8dOvnwRvqrto1AdQ
+                              oRkAN15FP3iZ7suB7gvTBmXzCjL7XUgQVcoH
+                              kdhyCuzp8W9qJHgRUSwKKkczSyuL64nhgjuD
+                              EML8l9wlWVsl7PR2VnZduM9bLyBhaaPmRKX/
+                              Fm+v6ccF2EGNLRiY08kdkz+XHHo= )
+                  3600 NSEC   ai.example. NS DS RRSIG NSEC
+                  3600 RRSIG  NSEC 5 2 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              cOlYgqJLqlRqmBQ3iap2SyIsK4O5aqpKSoba
+                              U9fQ5SMApZmHfq3AgLflkrkXRXvgxTQSKkG2
+                              039/cRUs6Jk/25+fi7Xr5nOVJsb0lq4zsB3I
+                              BBdjyGDAHE0F5ROJj87996vJupdm1fbH481g
+                              sdkOW6Zyqtz3Zos8N0BBkEx+2G4= )
+   ns1.a.example. 3600 IN A   192.0.2.5
+   ns2.a.example. 3600 IN A   192.0.2.6
+   ai.example.    3600 IN A   192.0.2.9
+                  3600 RRSIG  A 5 2 3600 20040509183619 (
+                              20040409183619 38519 example.
+
+
+
+Arends, et al.              Standards Track                    [Page 37]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+                              pAOtzLP2MU0tDJUwHOKE5FPIIHmdYsCgTb5B
+                              ERGgpnJluA9ixOyf6xxVCgrEJW0WNZSsJicd
+                              hBHXfDmAGKUajUUlYSAH8tS4ZnrhyymIvk3u
+                              ArDu2wfT130e9UHnumaHHMpUTosKe22PblOy
+                              6zrTpg9FkS0XGVmYRvOTNYx2HvQ= )
+                  3600 HINFO  "KLH-10" "ITS"
+                  3600 RRSIG  HINFO 5 2 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              Iq/RGCbBdKzcYzlGE4ovbr5YcB+ezxbZ9W0l
+                              e/7WqyvhOO9J16HxhhL7VY/IKmTUY0GGdcfh
+                              ZEOCkf4lEykZF9NPok1/R/fWrtzNp8jobuY7
+                              AZEcZadp1WdDF3jc2/ndCa5XZhLKD3JzOsBw
+                              FvL8sqlS5QS6FY/ijFEDnI4RkZA= )
+                  3600 AAAA   2001:db8::f00:baa9
+                  3600 RRSIG  AAAA 5 2 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              nLcpFuXdT35AcE+EoafOUkl69KB+/e56XmFK
+                              kewXG2IadYLKAOBIoR5+VoQV3XgTcofTJNsh
+                              1rnF6Eav2zpZB3byI6yo2bwY8MNkr4A7cL9T
+                              cMmDwV/hWFKsbGBsj8xSCN/caEL2CWY/5XP2
+                              sZM6QjBBLmukH30+w1z3h8PUP2o= )
+                  3600 NSEC   b.example. A HINFO AAAA RRSIG NSEC
+                  3600 RRSIG  NSEC 5 2 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              QoshyPevLcJ/xcRpEtMft1uoIrcrieVcc9pG
+                              CScIn5Glnib40T6ayVOimXwdSTZ/8ISXGj4p
+                              P8Sh0PlA6olZQ84L453/BUqB8BpdOGky4hsN
+                              3AGcLEv1Gr0QMvirQaFcjzOECfnGyBm+wpFL
+                              AhS+JOVfDI/79QtyTI0SaDWcg8U= )
+   b.example.     3600 IN NS  ns1.b.example.
+                  3600 IN NS  ns2.b.example.
+                  3600 NSEC   ns1.example. NS RRSIG NSEC
+                  3600 RRSIG  NSEC 5 2 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              GNuxHn844wfmUhPzGWKJCPY5ttEX/RfjDoOx
+                              9ueK1PtYkOWKOOdiJ/PJKCYB3hYX+858dDWS
+                              xb2qnV/LSTCNVBnkm6owOpysY97MVj5VQEWs
+                              0lm9tFoqjcptQkmQKYPrwUnCSNwvvclSF1xZ
+                              vhRXgWT7OuFXldoCG6TfVFMs9xE= )
+   ns1.b.example. 3600 IN A   192.0.2.7
+   ns2.b.example. 3600 IN A   192.0.2.8
+   ns1.example.   3600 IN A   192.0.2.1
+                  3600 RRSIG  A 5 2 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              F1C9HVhIcs10cZU09G5yIVfKJy5yRQQ3qVet
+                              5pGhp82pzhAOMZ3K22JnmK4c+IjUeFp/to06
+                              im5FVpHtbFisdjyPq84bhTv8vrXt5AB1wNB+
+                              +iAqvIfdgW4sFNC6oADb1hK8QNauw9VePJhK
+
+
+
+Arends, et al.              Standards Track                    [Page 38]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+                              v/iVXSYC0b7mPSU+EOlknFpVECs= )
+                  3600 NSEC   ns2.example. A RRSIG NSEC
+                  3600 RRSIG  NSEC 5 2 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              I4hj+Kt6+8rCcHcUdolks2S+Wzri9h3fHas8
+                              1rGN/eILdJHN7JpV6lLGPIh/8fIBkfvdyWnB
+                              jjf1q3O7JgYO1UdI7FvBNWqaaEPJK3UkddBq
+                              ZIaLi8Qr2XHkjq38BeQsbp8X0+6h4ETWSGT8
+                              IZaIGBLryQWGLw6Y6X8dqhlnxJM= )
+   ns2.example.   3600 IN A   192.0.2.2
+                  3600 RRSIG  A 5 2 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              V7cQRw1TR+knlaL1z/psxlS1PcD37JJDaCMq
+                              Qo6/u1qFQu6x+wuDHRH22Ap9ulJPQjFwMKOu
+                              yfPGQPC8KzGdE3vt5snFEAoE1Vn3mQqtu7SO
+                              6amIjk13Kj/jyJ4nGmdRIc/3cM3ipXFhNTKq
+                              rdhx8SZ0yy4ObIRzIzvBFLiSS8o= )
+                  3600 NSEC   *.w.example. A RRSIG NSEC
+                  3600 RRSIG  NSEC 5 2 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              N0QzHvaJf5NRw1rE9uxS1Ltb2LZ73Qb9bKGE
+                              VyaISkqzGpP3jYJXZJPVTq4UVEsgT3CgeHvb
+                              3QbeJ5Dfb2V9NGCHj/OvF/LBxFFWwhLwzngH
+                              l+bQAgAcMsLu/nL3nDi1y/JSQjAcdZNDl4bw
+                              Ymx28EtgIpo9A0qmP08rMBqs1Jw= )
+   *.w.example.   3600 IN MX  1 ai.example.
+                  3600 RRSIG  MX 5 2 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              OMK8rAZlepfzLWW75Dxd63jy2wswESzxDKG2
+                              f9AMN1CytCd10cYISAxfAdvXSZ7xujKAtPbc
+                              tvOQ2ofO7AZJ+d01EeeQTVBPq4/6KCWhqe2X
+                              TjnkVLNvvhnc0u28aoSsG0+4InvkkOHknKxw
+                              4kX18MMR34i8lC36SR5xBni8vHI= )
+                  3600 NSEC   x.w.example. MX RRSIG NSEC
+                  3600 RRSIG  NSEC 5 2 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              r/mZnRC3I/VIcrelgIcteSxDhtsdlTDt8ng9
+                              HSBlABOlzLxQtfgTnn8f+aOwJIAFe1Ee5RvU
+                              5cVhQJNP5XpXMJHfyps8tVvfxSAXfahpYqtx
+                              91gsmcV/1V9/bZAG55CefP9cM4Z9Y9NT9XQ8
+                              s1InQ2UoIv6tJEaaKkP701j8OLA= )
+   x.w.example.   3600 IN MX  1 xx.example.
+                  3600 RRSIG  MX 5 3 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              Il2WTZ+Bkv+OytBx4LItNW5mjB4RCwhOO8y1
+                              XzPHZmZUTVYL7LaA63f6T9ysVBzJRI3KRjAP
+                              H3U1qaYnDoN1DrWqmi9RJe4FoObkbcdm7P3I
+                              kx70ePCoFgRz1Yq+bVVXCvGuAU4xALv3W/Y1
+
+
+
+Arends, et al.              Standards Track                    [Page 39]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+                              jNSlwZ2mSWKHfxFQxPtLj8s32+k= )
+                  3600 NSEC   x.y.w.example. MX RRSIG NSEC
+                  3600 RRSIG  NSEC 5 3 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              aRbpHftxggzgMXdDlym9SsADqMZovZZl2QWK
+                              vw8J0tZEUNQByH5Qfnf5N1FqH/pS46UA7A4E
+                              mcWBN9PUA1pdPY6RVeaRlZlCr1IkVctvbtaI
+                              NJuBba/VHm+pebTbKcAPIvL9tBOoh+to1h6e
+                              IjgiM8PXkBQtxPq37wDKALkyn7Q= )
+   x.y.w.example. 3600 IN MX  1 xx.example.
+                  3600 RRSIG  MX 5 4 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              k2bJHbwP5LH5qN4is39UiPzjAWYmJA38Hhia
+                              t7i9t7nbX/e0FPnvDSQXzcK7UL+zrVA+3MDj
+                              q1ub4q3SZgcbLMgexxIW3Va//LVrxkP6Xupq
+                              GtOB9prkK54QTl/qZTXfMQpW480YOvVknhvb
+                              +gLcMZBnHJ326nb/TOOmrqNmQQE= )
+                  3600 NSEC   xx.example. MX RRSIG NSEC
+                  3600 RRSIG  NSEC 5 4 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              OvE6WUzN2ziieJcvKPWbCAyXyP6ef8cr6Csp
+                              ArVSTzKSquNwbezZmkU7E34o5lmb6CWSSSpg
+                              xw098kNUFnHcQf/LzY2zqRomubrNQhJTiDTX
+                              a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5Vr
+                              QoKqJDCLnoAlcPOPKAm/jJkn3jk= )
+   xx.example.    3600 IN A   192.0.2.10
+                  3600 RRSIG  A 5 2 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              kBF4YxMGWF0D8r0cztL+2fWWOvN1U/GYSpYP
+                              7SoKoNQ4fZKyk+weWGlKLIUM+uE1zjVTPXoa
+                              0Z6WG0oZp46rkl1EzMcdMgoaeUzzAJ2BMq+Y
+                              VdxG9IK1yZkYGY9AgbTOGPoAgbJyO9EPULsx
+                              kbIDV6GPPSZVusnZU6OMgdgzHV4= )
+                  3600 HINFO  "KLH-10" "TOPS-20"
+                  3600 RRSIG  HINFO 5 2 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              GY2PLSXmMHkWHfLdggiox8+chWpeMNJLkML0
+                              t+U/SXSUsoUdR91KNdNUkTDWamwcF8oFRjhq
+                              BcPZ6EqrF+vl5v5oGuvSF7U52epfVTC+wWF8
+                              3yCUeUw8YklhLWlvk8gQ15YKth0ITQy8/wI+
+                              RgNvuwbioFSEuv2pNlkq0goYxNY= )
+                  3600 AAAA   2001:db8::f00:baaa
+                  3600 RRSIG  AAAA 5 2 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              Zzj0yodDxcBLnnOIwDsuKo5WqiaK24DlKg9C
+                              aGaxDFiKgKobUj2jilYQHpGFn2poFRetZd4z
+                              ulyQkssz2QHrVrPuTMS22knudCiwP4LWpVTr
+                              U4zfeA+rDz9stmSBP/4PekH/x2IoAYnwctd/
+
+
+
+Arends, et al.              Standards Track                    [Page 40]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+                              xS9cL2QgW7FChw16mzlkH6/vsfs= )
+                  3600 NSEC   example. A HINFO AAAA RRSIG NSEC
+                  3600 RRSIG  NSEC 5 2 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              ZFWUln6Avc8bmGl5GFjD3BwT530DUZKHNuoY
+                              9A8lgXYyrxu+pqgFiRVbyZRQvVB5pccEOT3k
+                              mvHgEa/HzbDB4PIYY79W+VHrgOxzdQGGCZzi
+                              asXrpSGOWwSOElghPnMIi8xdF7qtCntr382W
+                              GghLahumFIpg4MO3LS/prgzVVWo= )
+
+   The apex DNSKEY set includes two DNSKEY RRs, and the DNSKEY RDATA
+   Flags indicate that each of these DNSKEY RRs is a zone key.  One of
+   these DNSKEY RRs also has the SEP flag set and has been used to sign
+   the apex DNSKEY RRset; this is the key that should be hashed to
+   generate a DS record to be inserted into the parent zone.  The other
+   DNSKEY is used to sign all the other RRsets in the zone.
+
+   The zone includes a wildcard entry, "*.w.example".  Note that the
+   name "*.w.example" is used in constructing NSEC chains, and that the
+   RRSIG covering the "*.w.example" MX RRset has a label count of 2.
+
+   The zone also includes two delegations.  The delegation to
+   "b.example" includes an NS RRset, glue address records, and an NSEC
+   RR; note that only the NSEC RRset is signed.  The delegation to
+   "a.example" provides a DS RR; note that only the NSEC and DS RRsets
+   are signed.
+
+Appendix B.  Example Responses
+
+   The examples in this section show response messages using the signed
+   zone example in Appendix A.
+
+B.1.  Answer
+
+   A successful query to an authoritative server.
+
+   ;; Header: QR AA DO RCODE=0
+   ;;
+   ;; Question
+   x.w.example.        IN MX
+
+   ;; Answer
+   x.w.example.   3600 IN MX  1 xx.example.
+   x.w.example.   3600 RRSIG  MX 5 3 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              Il2WTZ+Bkv+OytBx4LItNW5mjB4RCwhOO8y1
+                              XzPHZmZUTVYL7LaA63f6T9ysVBzJRI3KRjAP
+                              H3U1qaYnDoN1DrWqmi9RJe4FoObkbcdm7P3I
+
+
+
+Arends, et al.              Standards Track                    [Page 41]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+                              kx70ePCoFgRz1Yq+bVVXCvGuAU4xALv3W/Y1
+                              jNSlwZ2mSWKHfxFQxPtLj8s32+k= )
+
+   ;; Authority
+   example.       3600 NS     ns1.example.
+   example.       3600 NS     ns2.example.
+   example.       3600 RRSIG  NS 5 1 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd
+                              EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf
+                              4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8
+                              RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48
+                              0HjMeRaZB/FRPGfJPajngcq6Kwg= )
+
+   ;; Additional
+   xx.example.    3600 IN A   192.0.2.10
+   xx.example.    3600 RRSIG  A 5 2 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              kBF4YxMGWF0D8r0cztL+2fWWOvN1U/GYSpYP
+                              7SoKoNQ4fZKyk+weWGlKLIUM+uE1zjVTPXoa
+                              0Z6WG0oZp46rkl1EzMcdMgoaeUzzAJ2BMq+Y
+                              VdxG9IK1yZkYGY9AgbTOGPoAgbJyO9EPULsx
+                              kbIDV6GPPSZVusnZU6OMgdgzHV4= )
+   xx.example.    3600 AAAA   2001:db8::f00:baaa
+   xx.example.    3600 RRSIG  AAAA 5 2 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              Zzj0yodDxcBLnnOIwDsuKo5WqiaK24DlKg9C
+                              aGaxDFiKgKobUj2jilYQHpGFn2poFRetZd4z
+                              ulyQkssz2QHrVrPuTMS22knudCiwP4LWpVTr
+                              U4zfeA+rDz9stmSBP/4PekH/x2IoAYnwctd/
+                              xS9cL2QgW7FChw16mzlkH6/vsfs= )
+   ns1.example.   3600 IN A   192.0.2.1
+   ns1.example.   3600 RRSIG  A 5 2 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              F1C9HVhIcs10cZU09G5yIVfKJy5yRQQ3qVet
+                              5pGhp82pzhAOMZ3K22JnmK4c+IjUeFp/to06
+                              im5FVpHtbFisdjyPq84bhTv8vrXt5AB1wNB+
+                              +iAqvIfdgW4sFNC6oADb1hK8QNauw9VePJhK
+                              v/iVXSYC0b7mPSU+EOlknFpVECs= )
+   ns2.example.   3600 IN A   192.0.2.2
+   ns2.example.   3600 RRSIG  A 5 2 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              V7cQRw1TR+knlaL1z/psxlS1PcD37JJDaCMq
+                              Qo6/u1qFQu6x+wuDHRH22Ap9ulJPQjFwMKOu
+                              yfPGQPC8KzGdE3vt5snFEAoE1Vn3mQqtu7SO
+                              6amIjk13Kj/jyJ4nGmdRIc/3cM3ipXFhNTKq
+                              rdhx8SZ0yy4ObIRzIzvBFLiSS8o= )
+
+
+
+
+Arends, et al.              Standards Track                    [Page 42]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+B.2.  Name Error
+
+   An authoritative name error.  The NSEC RRs prove that the name does
+   not exist and that no covering wildcard exists.
+
+   ;; Header: QR AA DO RCODE=3
+   ;;
+   ;; Question
+   ml.example.         IN A
+
+   ;; Answer
+   ;; (empty)
+
+   ;; Authority
+   example.       3600 IN SOA ns1.example. bugs.x.w.example. (
+                              1081539377
+                              3600
+                              300
+                              3600000
+                              3600
+                              )
+   example.       3600 RRSIG  SOA 5 1 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h
+                              7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF
+                              vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW
+                              DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB
+                              jV7j86HyQgM5e7+miRAz8V01b0I= )
+   b.example.     3600 NSEC   ns1.example. NS RRSIG NSEC
+   b.example.     3600 RRSIG  NSEC 5 2 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              GNuxHn844wfmUhPzGWKJCPY5ttEX/RfjDoOx
+                              9ueK1PtYkOWKOOdiJ/PJKCYB3hYX+858dDWS
+                              xb2qnV/LSTCNVBnkm6owOpysY97MVj5VQEWs
+                              0lm9tFoqjcptQkmQKYPrwUnCSNwvvclSF1xZ
+                              vhRXgWT7OuFXldoCG6TfVFMs9xE= )
+   example.       3600 NSEC   a.example. NS SOA MX RRSIG NSEC DNSKEY
+   example.       3600 RRSIG  NSEC 5 1 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              O0k558jHhyrC97ISHnislm4kLMW48C7U7cBm
+                              FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V
+                              Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW
+                              SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm
+                              jfFJ5arXf4nPxp/kEowGgBRzY/U= )
+
+   ;; Additional
+   ;; (empty)
+
+
+
+
+Arends, et al.              Standards Track                    [Page 43]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+B.3.  No Data Error
+
+   A "no data" response.  The NSEC RR proves that the name exists and
+   that the requested RR type does not.
+
+   ;; Header: QR AA DO RCODE=0
+   ;;
+   ;; Question
+   ns1.example.        IN MX
+
+   ;; Answer
+   ;; (empty)
+
+   ;; Authority
+   example.       3600 IN SOA ns1.example. bugs.x.w.example. (
+                              1081539377
+                              3600
+                              300
+                              3600000
+                              3600
+                              )
+   example.       3600 RRSIG  SOA 5 1 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h
+                              7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF
+                              vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW
+                              DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB
+                              jV7j86HyQgM5e7+miRAz8V01b0I= )
+   ns1.example.   3600 NSEC   ns2.example. A RRSIG NSEC
+   ns1.example.   3600 RRSIG  NSEC 5 2 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              I4hj+Kt6+8rCcHcUdolks2S+Wzri9h3fHas8
+                              1rGN/eILdJHN7JpV6lLGPIh/8fIBkfvdyWnB
+                              jjf1q3O7JgYO1UdI7FvBNWqaaEPJK3UkddBq
+                              ZIaLi8Qr2XHkjq38BeQsbp8X0+6h4ETWSGT8
+                              IZaIGBLryQWGLw6Y6X8dqhlnxJM= )
+
+   ;; Additional
+   ;; (empty)
+
+B.4.  Referral to Signed Zone
+
+   Referral to a signed zone.  The DS RR contains the data which the
+   resolver will need to validate the corresponding DNSKEY RR in the
+   child zone's apex.
+
+   ;; Header: QR DO RCODE=0
+   ;;
+
+
+
+Arends, et al.              Standards Track                    [Page 44]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+   ;; Question
+   mc.a.example.       IN MX
+
+   ;; Answer
+   ;; (empty)
+
+   ;; Authority
+   a.example.     3600 IN NS  ns1.a.example.
+   a.example.     3600 IN NS  ns2.a.example.
+   a.example.     3600 DS     57855 5 1 (
+                              B6DCD485719ADCA18E5F3D48A2331627FDD3
+                              636B )
+   a.example.     3600 RRSIG  DS 5 2 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              oXIKit/QtdG64J/CB+Gi8dOvnwRvqrto1AdQ
+                              oRkAN15FP3iZ7suB7gvTBmXzCjL7XUgQVcoH
+                              kdhyCuzp8W9qJHgRUSwKKkczSyuL64nhgjuD
+                              EML8l9wlWVsl7PR2VnZduM9bLyBhaaPmRKX/
+                              Fm+v6ccF2EGNLRiY08kdkz+XHHo= )
+
+   ;; Additional
+   ns1.a.example. 3600 IN A   192.0.2.5
+   ns2.a.example. 3600 IN A   192.0.2.6
+
+B.5.  Referral to Unsigned Zone
+
+   Referral to an unsigned zone.  The NSEC RR proves that no DS RR for
+   this delegation exists in the parent zone.
+
+   ;; Header: QR DO RCODE=0
+   ;;
+   ;; Question
+   mc.b.example.       IN MX
+
+   ;; Answer
+   ;; (empty)
+
+   ;; Authority
+   b.example.     3600 IN NS  ns1.b.example.
+   b.example.     3600 IN NS  ns2.b.example.
+   b.example.     3600 NSEC   ns1.example. NS RRSIG NSEC
+   b.example.     3600 RRSIG  NSEC 5 2 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              GNuxHn844wfmUhPzGWKJCPY5ttEX/RfjDoOx
+                              9ueK1PtYkOWKOOdiJ/PJKCYB3hYX+858dDWS
+                              xb2qnV/LSTCNVBnkm6owOpysY97MVj5VQEWs
+                              0lm9tFoqjcptQkmQKYPrwUnCSNwvvclSF1xZ
+                              vhRXgWT7OuFXldoCG6TfVFMs9xE= )
+
+
+
+Arends, et al.              Standards Track                    [Page 45]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+   ;; Additional
+   ns1.b.example. 3600 IN A   192.0.2.7
+   ns2.b.example. 3600 IN A   192.0.2.8
+
+B.6.  Wildcard Expansion
+
+   A successful query that was answered via wildcard expansion.  The
+   label count in the answer's RRSIG RR indicates that a wildcard RRset
+   was expanded to produce this response, and the NSEC RR proves that no
+   closer match exists in the zone.
+
+   ;; Header: QR AA DO RCODE=0
+   ;;
+   ;; Question
+   a.z.w.example.      IN MX
+
+   ;; Answer
+   a.z.w.example. 3600 IN MX  1 ai.example.
+   a.z.w.example. 3600 RRSIG  MX 5 2 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              OMK8rAZlepfzLWW75Dxd63jy2wswESzxDKG2
+                              f9AMN1CytCd10cYISAxfAdvXSZ7xujKAtPbc
+                              tvOQ2ofO7AZJ+d01EeeQTVBPq4/6KCWhqe2X
+                              TjnkVLNvvhnc0u28aoSsG0+4InvkkOHknKxw
+                              4kX18MMR34i8lC36SR5xBni8vHI= )
+
+   ;; Authority
+   example.       3600 NS     ns1.example.
+   example.       3600 NS     ns2.example.
+   example.       3600 RRSIG  NS 5 1 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              gl13F00f2U0R+SWiXXLHwsMY+qStYy5k6zfd
+                              EuivWc+wd1fmbNCyql0Tk7lHTX6UOxc8AgNf
+                              4ISFve8XqF4q+o9qlnqIzmppU3LiNeKT4FZ8
+                              RO5urFOvoMRTbQxW3U0hXWuggE4g3ZpsHv48
+                              0HjMeRaZB/FRPGfJPajngcq6Kwg= )
+   x.y.w.example. 3600 NSEC   xx.example. MX RRSIG NSEC
+   x.y.w.example. 3600 RRSIG  NSEC 5 4 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              OvE6WUzN2ziieJcvKPWbCAyXyP6ef8cr6Csp
+                              ArVSTzKSquNwbezZmkU7E34o5lmb6CWSSSpg
+                              xw098kNUFnHcQf/LzY2zqRomubrNQhJTiDTX
+                              a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5Vr
+                              QoKqJDCLnoAlcPOPKAm/jJkn3jk= )
+
+   ;; Additional
+   ai.example.    3600 IN A   192.0.2.9
+   ai.example.    3600 RRSIG  A 5 2 3600 20040509183619 (
+
+
+
+Arends, et al.              Standards Track                    [Page 46]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+                              20040409183619 38519 example.
+                              pAOtzLP2MU0tDJUwHOKE5FPIIHmdYsCgTb5B
+                              ERGgpnJluA9ixOyf6xxVCgrEJW0WNZSsJicd
+                              hBHXfDmAGKUajUUlYSAH8tS4ZnrhyymIvk3u
+                              ArDu2wfT130e9UHnumaHHMpUTosKe22PblOy
+                              6zrTpg9FkS0XGVmYRvOTNYx2HvQ= )
+   ai.example.    3600 AAAA   2001:db8::f00:baa9
+   ai.example.    3600 RRSIG  AAAA 5 2 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              nLcpFuXdT35AcE+EoafOUkl69KB+/e56XmFK
+                              kewXG2IadYLKAOBIoR5+VoQV3XgTcofTJNsh
+                              1rnF6Eav2zpZB3byI6yo2bwY8MNkr4A7cL9T
+                              cMmDwV/hWFKsbGBsj8xSCN/caEL2CWY/5XP2
+                              sZM6QjBBLmukH30+w1z3h8PUP2o= )
+
+B.7.  Wildcard No Data Error
+
+   A "no data" response for a name covered by a wildcard.  The NSEC RRs
+   prove that the matching wildcard name does not have any RRs of the
+   requested type and that no closer match exists in the zone.
+
+   ;; Header: QR AA DO RCODE=0
+   ;;
+   ;; Question
+   a.z.w.example.      IN AAAA
+
+   ;; Answer
+   ;; (empty)
+
+   ;; Authority
+   example.       3600 IN SOA ns1.example. bugs.x.w.example. (
+                              1081539377
+                              3600
+                              300
+                              3600000
+                              3600
+                              )
+   example.       3600 RRSIG  SOA 5 1 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h
+                              7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF
+                              vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW
+                              DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB
+                              jV7j86HyQgM5e7+miRAz8V01b0I= )
+   x.y.w.example. 3600 NSEC   xx.example. MX RRSIG NSEC
+   x.y.w.example. 3600 RRSIG  NSEC 5 4 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              OvE6WUzN2ziieJcvKPWbCAyXyP6ef8cr6Csp
+
+
+
+Arends, et al.              Standards Track                    [Page 47]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+                              ArVSTzKSquNwbezZmkU7E34o5lmb6CWSSSpg
+                              xw098kNUFnHcQf/LzY2zqRomubrNQhJTiDTX
+                              a0ArunJQCzPjOYq5t0SLjm6qp6McJI1AP5Vr
+                              QoKqJDCLnoAlcPOPKAm/jJkn3jk= )
+   *.w.example.   3600 NSEC   x.w.example. MX RRSIG NSEC
+   *.w.example.   3600 RRSIG  NSEC 5 2 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              r/mZnRC3I/VIcrelgIcteSxDhtsdlTDt8ng9
+                              HSBlABOlzLxQtfgTnn8f+aOwJIAFe1Ee5RvU
+                              5cVhQJNP5XpXMJHfyps8tVvfxSAXfahpYqtx
+                              91gsmcV/1V9/bZAG55CefP9cM4Z9Y9NT9XQ8
+                              s1InQ2UoIv6tJEaaKkP701j8OLA= )
+
+   ;; Additional
+   ;; (empty)
+
+B.8.  DS Child Zone No Data Error
+
+   A "no data" response for a QTYPE=DS query that was mistakenly sent to
+   a name server for the child zone.
+
+   ;; Header: QR AA DO RCODE=0
+   ;;
+   ;; Question
+   example.            IN DS
+
+   ;; Answer
+   ;; (empty)
+
+   ;; Authority
+   example.       3600 IN SOA ns1.example. bugs.x.w.example. (
+                              1081539377
+                              3600
+                              300
+                              3600000
+                              3600
+                              )
+   example.       3600 RRSIG  SOA 5 1 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              ONx0k36rcjaxYtcNgq6iQnpNV5+drqYAsC9h
+                              7TSJaHCqbhE67Sr6aH2xDUGcqQWu/n0UVzrF
+                              vkgO9ebarZ0GWDKcuwlM6eNB5SiX2K74l5LW
+                              DA7S/Un/IbtDq4Ay8NMNLQI7Dw7n4p8/rjkB
+                              jV7j86HyQgM5e7+miRAz8V01b0I= )
+   example.       3600 NSEC   a.example. NS SOA MX RRSIG NSEC DNSKEY
+   example.       3600 RRSIG  NSEC 5 1 3600 20040509183619 (
+                              20040409183619 38519 example.
+                              O0k558jHhyrC97ISHnislm4kLMW48C7U7cBm
+
+
+
+Arends, et al.              Standards Track                    [Page 48]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+                              FTfhke5iVqNRVTB1STLMpgpbDIC9hcryoO0V
+                              Z9ME5xPzUEhbvGnHd5sfzgFVeGxr5Nyyq4tW
+                              SDBgIBiLQUv1ivy29vhXy7WgR62dPrZ0PWvm
+                              jfFJ5arXf4nPxp/kEowGgBRzY/U= )
+
+   ;; Additional
+   ;; (empty)
+
+Appendix C.  Authentication Examples
+
+   The examples in this section show how the response messages in
+   Appendix B are authenticated.
+
+C.1.  Authenticating an Answer
+
+   The query in Appendix B.1 returned an MX RRset for "x.w.example.com".
+   The corresponding RRSIG indicates that the MX RRset was signed by an
+   "example" DNSKEY with algorithm 5 and key tag 38519.  The resolver
+   needs the corresponding DNSKEY RR in order to authenticate this
+   answer.  The discussion below describes how a resolver might obtain
+   this DNSKEY RR.
+
+   The RRSIG indicates the original TTL of the MX RRset was 3600, and,
+   for the purpose of authentication, the current TTL is replaced by
+   3600.  The RRSIG labels field value of 3 indicates that the answer
+   was not the result of wildcard expansion.  The "x.w.example.com" MX
+   RRset is placed in canonical form, and, assuming the current time
+   falls between the signature inception and expiration dates, the
+   signature is authenticated.
+
+C.1.1.  Authenticating the Example DNSKEY RR
+
+   This example shows the logical authentication process that starts
+   from the a configured root DNSKEY (or DS RR) and moves down the tree
+   to authenticate the desired "example" DNSKEY RR.  Note that the
+   logical order is presented for clarity.  An implementation may choose
+   to construct the authentication as referrals are received or to
+   construct the authentication chain only after all RRsets have been
+   obtained, or in any other combination it sees fit.  The example here
+   demonstrates only the logical process and does not dictate any
+   implementation rules.
+
+   We assume the resolver starts with a configured DNSKEY RR for the
+   root zone (or a configured DS RR for the root zone).  The resolver
+   checks whether this configured DNSKEY RR is present in the root
+   DNSKEY RRset (or whether the DS RR matches some DNSKEY in the root
+   DNSKEY RRset), whether this DNSKEY RR has signed the root DNSKEY
+   RRset, and whether the signature lifetime is valid.  If all these
+
+
+
+Arends, et al.              Standards Track                    [Page 49]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+   conditions are met, all keys in the DNSKEY RRset are considered
+   authenticated.  The resolver then uses one (or more) of the root
+   DNSKEY RRs to authenticate the "example" DS RRset.  Note that the
+   resolver may have to query the root zone to obtain the root DNSKEY
+   RRset or "example" DS RRset.
+
+   Once the DS RRset has been authenticated using the root DNSKEY, the
+   resolver checks the "example" DNSKEY RRset for some "example" DNSKEY
+   RR that matches one of the authenticated "example" DS RRs.  If such a
+   matching "example" DNSKEY is found, the resolver checks whether this
+   DNSKEY RR has signed the "example" DNSKEY RRset and the signature
+   lifetime is valid.  If these conditions are met, all keys in the
+   "example" DNSKEY RRset are considered authenticated.
+
+   Finally, the resolver checks that some DNSKEY RR in the "example"
+   DNSKEY RRset uses algorithm 5 and has a key tag of 38519.  This
+   DNSKEY is used to authenticate the RRSIG included in the response.
+   If multiple "example" DNSKEY RRs match this algorithm and key tag,
+   then each DNSKEY RR is tried, and the answer is authenticated if any
+   of the matching DNSKEY RRs validate the signature as described above.
+
+C.2.  Name Error
+
+   The query in Appendix B.2 returned NSEC RRs that prove that the
+   requested data does not exist and no wildcard applies.  The negative
+   reply is authenticated by verifying both NSEC RRs.  The NSEC RRs are
+   authenticated in a manner identical to that of the MX RRset discussed
+   above.
+
+C.3.  No Data Error
+
+   The query in Appendix B.3 returned an NSEC RR that proves that the
+   requested name exists, but the requested RR type does not exist.  The
+   negative reply is authenticated by verifying the NSEC RR.  The NSEC
+   RR is authenticated in a manner identical to that of the MX RRset
+   discussed above.
+
+C.4.  Referral to Signed Zone
+
+   The query in Appendix B.4 returned a referral to the signed
+   "a.example." zone.  The DS RR is authenticated in a manner identical
+   to that of the MX RRset discussed above.  This DS RR is used to
+   authenticate the "a.example" DNSKEY RRset.
+
+   Once the "a.example" DS RRset has been authenticated using the
+   "example" DNSKEY, the resolver checks the "a.example" DNSKEY RRset
+   for some "a.example" DNSKEY RR that matches the DS RR.  If such a
+   matching "a.example" DNSKEY is found, the resolver checks whether
+
+
+
+Arends, et al.              Standards Track                    [Page 50]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+   this DNSKEY RR has signed the "a.example" DNSKEY RRset and whether
+   the signature lifetime is valid.  If all these conditions are met,
+   all keys in the "a.example" DNSKEY RRset are considered
+   authenticated.
+
+C.5.  Referral to Unsigned Zone
+
+   The query in Appendix B.5 returned a referral to an unsigned
+   "b.example." zone.  The NSEC proves that no authentication leads from
+   "example" to "b.example", and the NSEC RR is authenticated in a
+   manner identical to that of the MX RRset discussed above.
+
+C.6.  Wildcard Expansion
+
+   The query in Appendix B.6 returned an answer that was produced as a
+   result of wildcard expansion.  The answer section contains a wildcard
+   RRset expanded as it would be in a traditional DNS response, and the
+   corresponding RRSIG indicates that the expanded wildcard MX RRset was
+   signed by an "example" DNSKEY with algorithm 5 and key tag 38519.
+   The RRSIG indicates that the original TTL of the MX RRset was 3600,
+   and, for the purpose of authentication, the current TTL is replaced
+   by 3600.  The RRSIG labels field value of 2 indicates that the answer
+   is the result of wildcard expansion, as the "a.z.w.example" name
+   contains 4 labels.  The name "a.z.w.w.example" is replaced by
+   "*.w.example", the MX RRset is placed in canonical form, and,
+   assuming that the current time falls between the signature inception
+   and expiration dates, the signature is authenticated.
+
+   The NSEC proves that no closer match (exact or closer wildcard) could
+   have been used to answer this query, and the NSEC RR must also be
+   authenticated before the answer is considered valid.
+
+C.7.  Wildcard No Data Error
+
+   The query in Appendix B.7 returned NSEC RRs that prove that the
+   requested data does not exist and no wildcard applies.  The negative
+   reply is authenticated by verifying both NSEC RRs.
+
+C.8.  DS Child Zone No Data Error
+
+   The query in Appendix B.8 returned NSEC RRs that shows the requested
+   was answered by a child server ("example" server).  The NSEC RR
+   indicates the presence of an SOA RR, showing that the answer is from
+   the child .  Queries for the "example" DS RRset should be sent to the
+   parent servers ("root" servers).
+
+
+
+
+
+
+Arends, et al.              Standards Track                    [Page 51]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+Authors' Addresses
+
+   Roy Arends
+   Telematica Instituut
+   Brouwerijstraat 1
+   7523 XC  Enschede
+   NL
+
+   EMail: roy.arends@telin.nl
+
+
+   Rob Austein
+   Internet Systems Consortium
+   950 Charter Street
+   Redwood City, CA  94063
+   USA
+
+   EMail: sra@isc.org
+
+
+   Matt Larson
+   VeriSign, Inc.
+   21345 Ridgetop Circle
+   Dulles, VA  20166-6503
+   USA
+
+   EMail: mlarson@verisign.com
+
+
+   Dan Massey
+   Colorado State University
+   Department of Computer Science
+   Fort Collins, CO 80523-1873
+
+   EMail: massey@cs.colostate.edu
+
+
+   Scott Rose
+   National Institute for Standards and Technology
+   100 Bureau Drive
+   Gaithersburg, MD  20899-8920
+   USA
+
+   EMail: scott.rose@nist.gov
+
+
+
+
+
+
+
+Arends, et al.              Standards Track                    [Page 52]
+
+RFC 4035             DNSSEC Protocol Modifications            March 2005
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2005).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at ietf-
+   ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+Arends, et al.              Standards Track                    [Page 53]
+
diff --git a/doc/rfc/rfc4074.txt b/doc/rfc/rfc4074.txt
new file mode 100644
index 0000000..d9252b3
--- /dev/null
+++ b/doc/rfc/rfc4074.txt
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+Network Working Group                                       Y. Morishita
+Request for Comments: 4074                                          JPRS
+Category: Informational                                        T. Jinmei
+                                                                 Toshiba
+                                                                May 2005
+
+
+       Common Misbehavior Against DNS Queries for IPv6 Addresses
+
+Status of This Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   There is some known misbehavior of DNS authoritative servers when
+   they are queried for AAAA resource records.  Such behavior can block
+   IPv4 communication that should actually be available, cause a
+   significant delay in name resolution, or even make a denial of
+   service attack.  This memo describes details of known cases and
+   discusses their effects.
+
+1.  Introduction
+
+   Many existing DNS clients (resolvers) that support IPv6 first search
+   for AAAA Resource Records (RRs) of a target host name, and then for A
+   RRs of the same name.  This fallback mechanism is based on the DNS
+   specifications, which if not obeyed by authoritative servers, can
+   produce unpleasant results.  In some cases, for example, a web
+   browser fails to connect to a web server it could otherwise reach.
+   In the following sections, this memo describes some typical cases of
+   such misbehavior and its (bad) effects.
+
+   Note that the misbehavior is not specific to AAAA RRs.  In fact, all
+   known examples also apply to the cases of queries for MX, NS, and SOA
+   RRs.  The authors believe this can be generalized for all types of
+   queries other than those for A RRs.  In this memo, however, we
+   concentrate on the case for AAAA queries, since the problem is
+   particularly severe for resolvers that support IPv6, which thus
+   affects many end users.  Resolvers at end users normally send A
+   and/or AAAA queries only, so the problem for the other cases is
+   relatively minor.
+
+
+
+Morishita & Jinmei           Informational                      [Page 1]
+
+RFC 4074         Common Misbehavior Against DNS Queries         May 2005
+
+
+2.  Network Model
+
+   In this memo, we assume a typical network model of name resolution
+   environment using DNS.  It consists of three components: stub
+   resolvers, caching servers, and authoritative servers.  A stub
+   resolver issues a recursive query to a caching server, which then
+   handles the entire name resolution procedure recursively.  The
+   caching server caches the result of the query and sends the result to
+   the stub resolver.  The authoritative servers respond to queries for
+   names for which they have the authority, normally in a non-recursive
+   manner.
+
+3.  Expected Behavior
+
+   Suppose that an authoritative server has an A RR but has no AAAA RR
+   for a host name.  Then, the server should return a response to a
+   query for an AAAA RR of the name with the response code (RCODE) being
+   0 (indicating no error) and with an empty answer section (see
+   Sections 4.3.2 and 6.2.4 of [1]).  Such a response indicates that
+   there is at least one RR of a different type than AAAA for the
+   queried name, and the stub resolver can then look for A RRs.
+
+   This way, the caching server can cache the fact that the queried name
+   has no AAAA RR (but may have other types of RRs), and thus improve
+   the response time to further queries for an AAAA RR of the name.
+
+4.  Problematic Behaviors
+
+   There are some known cases at authoritative servers that do not
+   conform to the expected behavior.  This section describes those
+   problematic cases.
+
+4.1.  Ignore Queries for AAAA
+
+   Some authoritative servers seem to ignore queries for an AAAA RR,
+   causing a delay at the stub resolver to fall back to a query for an A
+   RR.  This behavior may cause a fatal timeout at the resolver or at
+   the application that calls the resolver.  Even if the resolver
+   eventually falls back, the result can be an unacceptable delay for
+   the application user, especially with interactive applications like
+   web browsing.
+
+4.2.  Return "Name Error"
+
+   This type of server returns a response with RCODE 3 ("Name Error") to
+   a query for an AAAA RR, indicating that it does not have any RRs of
+   any type for the queried name.
+
+
+
+
+Morishita & Jinmei           Informational                      [Page 2]
+
+RFC 4074         Common Misbehavior Against DNS Queries         May 2005
+
+
+   With this response, the stub resolver may immediately give up and
+   never fall back.  Even if the resolver retries with a query for an A
+   RR, the negative response for the name has been cached in the caching
+   server, and the caching server will simply return the negative
+   response.  As a result, the stub resolver considers this to be a
+   fatal error in name resolution.
+
+   Several examples of this behavior are known to the authors.  As of
+   this writing, all have been fixed.
+
+4.3.  Return Other Erroneous Codes
+
+   Other authoritative servers return a response with erroneous response
+   codes other than RCODE 3 ("Name Error").  One such RCODE is 4 ("Not
+   Implemented"), indicating that the servers do not support the
+   requested type of query.
+
+   These cases are less harmful than the previous one; if the stub
+   resolver falls back to querying for an A RR, the caching server will
+   process the query correctly and return an appropriate response.
+
+   However, these can still cause a serious effect.  There was an
+   authoritative server implementation that returned RCODE 2 ("Server
+   failure") to queries for AAAA RRs.  One widely deployed mail server
+   implementation with a certain type of resolver library interpreted
+   this result as an indication of retry and did not fall back to
+   queries for A RRs, causing message delivery failure.
+
+   If the caching server receives a response with these response codes,
+   it does not cache the fact that the queried name has no AAAA RR,
+   resulting in redundant queries for AAAA RRs in the future.  The
+   behavior will waste network bandwidth and increase the load of the
+   authoritative server.
+
+   Using RCODE 1 ("Format error") would cause a similar effect, though
+   the authors have not seen such implementations yet.
+
+4.4.  Return a Broken Response
+
+   Another type of authoritative servers returns broken responses to
+   AAAA queries.  Returning a response whose RR type is AAAA with the
+   length of the RDATA being 4 bytes is a known behavior of this
+   category.  The 4-byte data looks like the IPv4 address of the queried
+   host name.
+
+
+
+
+
+
+
+Morishita & Jinmei           Informational                      [Page 3]
+
+RFC 4074         Common Misbehavior Against DNS Queries         May 2005
+
+
+   That is, the RR in the answer section would be described as follows:
+
+     www.bad.example. 600 IN AAAA 192.0.2.1
+
+   which is, of course, bogus (or at least meaningless).
+
+   A widely deployed caching server implementation transparently returns
+   the broken response (and caches it) to the stub resolver.  Another
+   known server implementation parses the response by itself, and sends
+   a separate response with RCODE 2 ("Server failure").
+
+   In either case, the broken response does not affect queries for an A
+   RR of the same name.  If the stub resolver falls back to A queries,
+   it will get an appropriate response.
+
+   The latter case, however, causes the same bad effect as that
+   described in the previous section: redundant queries for AAAA RRs.
+
+4.5.  Make Lame Delegation
+
+   Some authoritative servers respond to AAAA queries in a way that
+   causes lame delegation.  In this case, the parent zone specifies that
+   the authoritative server should have the authority of a zone, but the
+   server should not return an authoritative response for AAAA queries
+   within the zone (i.e., the AA bit in the response is not set).  On
+   the other hand, the authoritative server returns an authoritative
+   response for A queries.
+
+   When a caching server asks the server for AAAA RRs in the zone, it
+   recognizes the delegation is lame, and returns a response with RCODE
+   2 ("Server failure") to the stub resolver.
+
+   Furthermore, some caching servers record the authoritative server as
+   lame for the zone and will not use it for a certain period of time.
+   With this type of caching server, even if the stub resolver falls
+   back to querying for an A RR, the caching server will simply return a
+   response with RCODE 2, since all the servers are known to be "lame."
+
+   There is also an implementation that relaxes the behavior a little
+   bit.  It tries to avoid using the lame server, but continues to try
+   it as a last resort.  With this type of caching server, the stub
+   resolver will get a correct response if it falls back after Server
+   failure.  However, this still causes redundant AAAA queries, as
+   explained in the previous sections.
+
+
+
+
+
+
+
+Morishita & Jinmei           Informational                      [Page 4]
+
+RFC 4074         Common Misbehavior Against DNS Queries         May 2005
+
+
+5.  Security Considerations
+
+   The CERT/CC pointed out that the response with RCODE 3 ("Name
+   Error"), described in Section 4.2, can be used for a denial of
+   service attack [2].  The same argument applies to the case of "lame
+   delegation", described in Section 4.5, with a certain type of caching
+   server.
+
+6.  Acknowledgements
+
+   Erik Nordmark encouraged the authors to publish this document as an
+   RFC.  Akira Kato and Paul Vixie reviewed a preliminary version of
+   this document.  Pekka Savola carefully reviewed a previous version
+   and provided detailed comments.  Bill Fenner, Scott Hollenbeck,
+   Thomas Narten, and Alex Zinin reviewed and helped improve the
+   document at the last stage for publication.
+
+7.  Informative References
+
+   [1]  Mockapetris, P., "Domain names - concepts and facilities", STD
+        13, RFC 1034, November 1987.
+
+   [2]  The CERT Coordination Center, "Incorrect NXDOMAIN responses from
+        AAAA queries could cause denial-of-service conditions",
+        March 2003, <http://www.kb.cert.org/vuls/id/714121>.
+
+Authors' Addresses
+
+   MORISHITA Orange Yasuhiro
+   Research and Development Department, Japan Registry Services Co.,Ltd.
+   Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda
+   Chiyoda-ku, Tokyo  101-0065
+   Japan
+
+   EMail: yasuhiro@jprs.co.jp
+
+
+   JINMEI Tatuya
+   Corporate Research & Development Center, Toshiba Corporation
+   1 Komukai Toshiba-cho, Saiwai-ku
+   Kawasaki-shi, Kanagawa  212-8582
+   Japan
+
+   EMail: jinmei@isl.rdc.toshiba.co.jp
+
+
+
+
+
+
+
+Morishita & Jinmei           Informational                      [Page 5]
+
+RFC 4074         Common Misbehavior Against DNS Queries         May 2005
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2005).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at ietf-
+   ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+Morishita & Jinmei           Informational                      [Page 6]
+
diff --git a/doc/rfc/rfc4159.txt b/doc/rfc/rfc4159.txt
new file mode 100644
index 0000000..1ab4bd1
--- /dev/null
+++ b/doc/rfc/rfc4159.txt
@@ -0,0 +1,171 @@
+
+
+
+
+
+
+Network Working Group                                          G. Huston
+Request for Comments: 4159                                         APNIC
+BCP: 109                                                     August 2005
+Category: Best Current Practice
+
+
+                        Deprecation of "ip6.int"
+
+Status of This Memo
+
+   This document specifies an Internet Best Current Practices for the
+   Internet Community, and requests discussion and suggestions for
+   improvements.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   This document advises of the deprecation of the use of "ip6.int" for
+   Standards Conformant IPv6 implementations.
+
+1.  IPv6 Standards Action
+
+   In August 2001 the IETF published [RFC3152], which advised that the
+   use of "ip6.int" as the domain for reverse-mapping of IPv6 addresses
+   to DNS names was deprecated.  The document noted that the use of
+   "ip6.int" would be phased out in an orderly fashion.
+
+   As of 1 September 2005, the IETF advises the community that the DNS
+   domain "ip6.int" should no longer be used to perform reverse mapping
+   of IPv6 addresses to domain names, and that the domain "ip6.arpa"
+   should be used henceforth, in accordance with the IANA Considerations
+   described in [RFC3596].  The domain "ip6.int" is deprecated, and its
+   use in IPv6 implementations that conform to the IPv6 Internet
+   Standards is discontinued.
+
+   The Regional Internet Registries (RIRs) are advised that maintenance
+   of delegation of entries in "ip6.int" is no longer required as part
+   of infrastructure services in support of Internet Standards
+   Conformant IPv6 implementations as of 1 September 2005.  The RIRs are
+   requested to work with their communities to adopt a schedule
+   regarding the cessation of support of registration services for the
+   "ip6.int" domain.
+
+
+
+
+
+
+Huston                   Best Current Practice                  [Page 1]
+
+RFC 4159                        ip6.int                      August 2005
+
+
+2.  IANA Considerations
+
+   IANA is advised that the "ip6.int" domain for reverse mapping of IPv6
+   addresses to domain names is no longer part of Internet Standards
+   Conformant support of IPv6 as of 1 September 2005.
+
+3.  Security Considerations
+
+   While DNS spoofing of address to name mapping has been exploited in
+   IPv4, removal of the "ip6.int" zone from the standard IPv6
+   specification creates no new threats to the security of the internet.
+
+4.  Acknowledgements
+
+   The document was prepared with the assistance of Kurt Lindqvist,
+   Thomas Narten, Paul Wilson, David Kessens, Bob Hinden, Brian
+   Haberman, and Bill Manning.
+
+5.  Normative References
+
+   [RFC3152] Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152,
+             August 2001.
+
+   [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS
+             Extensions to Support IP Version 6", RFC 3596, October
+             2003.
+
+Author's Address
+
+   Geoff Huston
+   APNIC
+
+   EMail: gih@apnic.net
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Huston                   Best Current Practice                  [Page 2]
+
+RFC 4159                        ip6.int                      August 2005
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2005).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at ietf-
+   ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+Huston                   Best Current Practice                  [Page 3]
+
diff --git a/doc/rfc/rfc4193.txt b/doc/rfc/rfc4193.txt
new file mode 100644
index 0000000..17e2c0b
--- /dev/null
+++ b/doc/rfc/rfc4193.txt
@@ -0,0 +1,899 @@
+
+
+
+
+
+
+Network Working Group                                          R. Hinden
+Request for Comments: 4193                                         Nokia
+Category: Standards Track                                    B. Haberman
+                                                                 JHU-APL
+                                                            October 2005
+
+
+                  Unique Local IPv6 Unicast Addresses
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   This document defines an IPv6 unicast address format that is globally
+   unique and is intended for local communications, usually inside of a
+   site.  These addresses are not expected to be routable on the global
+   Internet.
+
+Table of Contents
+
+   1. Introduction ....................................................2
+   2. Acknowledgements ................................................3
+   3. Local IPv6 Unicast Addresses ....................................3
+      3.1. Format .....................................................3
+           3.1.1. Background ..........................................4
+      3.2. Global ID ..................................................4
+           3.2.1. Locally Assigned Global IDs .........................5
+           3.2.2. Sample Code for Pseudo-Random Global ID Algorithm ...5
+           3.2.3. Analysis of the Uniqueness of Global IDs ............6
+      3.3. Scope Definition ...........................................6
+   4. Operational Guidelines ..........................................7
+      4.1. Routing ....................................................7
+      4.2. Renumbering and Site Merging ...............................7
+      4.3. Site Border Router and Firewall Packet Filtering ...........8
+      4.4. DNS Issues .................................................8
+      4.5. Application and Higher Level Protocol Issues ...............9
+      4.6. Use of Local IPv6 Addresses for Local Communication ........9
+      4.7. Use of Local IPv6 Addresses with VPNs .....................10
+
+
+
+Hinden & Haberman           Standards Track                     [Page 1]
+
+RFC 4193          Unique Local IPv6 Unicast Addresses       October 2005
+
+
+   5. Global Routing Considerations ..................................11
+      5.1. From the Standpoint of the Internet .......................11
+      5.2. From the Standpoint of a Site .............................11
+   6. Advantages and Disadvantages ...................................12
+      6.1. Advantages ................................................12
+      6.2. Disadvantages .............................................13
+   7. Security Considerations ........................................13
+   8. IANA Considerations ............................................13
+   9. References .....................................................13
+      9.1. Normative References ......................................13
+      9.2. Informative References ....................................14
+
+1.  Introduction
+
+   This document defines an IPv6 unicast address format that is globally
+   unique and is intended for local communications [IPV6].  These
+   addresses are called Unique Local IPv6 Unicast Addresses and are
+   abbreviated in this document as Local IPv6 addresses.  They are not
+   expected to be routable on the global Internet.  They are routable
+   inside of a more limited area such as a site.  They may also be
+   routed between a limited set of sites.
+
+   Local IPv6 unicast addresses have the following characteristics:
+
+      - Globally unique prefix (with high probability of uniqueness).
+
+      - Well-known prefix to allow for easy filtering at site
+        boundaries.
+
+      - Allow sites to be combined or privately interconnected without
+        creating any address conflicts or requiring renumbering of
+        interfaces that use these prefixes.
+
+      - Internet Service Provider independent and can be used for
+        communications inside of a site without having any permanent or
+        intermittent Internet connectivity.
+
+      - If accidentally leaked outside of a site via routing or DNS,
+        there is no conflict with any other addresses.
+
+      - In practice, applications may treat these addresses like global
+        scoped addresses.
+
+   This document defines the format of Local IPv6 addresses, how to
+   allocate them, and usage considerations including routing, site
+   border routers, DNS, application support, VPN usage, and guidelines
+   for how to use for local communication inside a site.
+
+
+
+
+Hinden & Haberman           Standards Track                     [Page 2]
+
+RFC 4193          Unique Local IPv6 Unicast Addresses       October 2005
+
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+2.  Acknowledgements
+
+   The underlying idea of creating Local IPv6 addresses described in
+   this document has been proposed a number of times by a variety of
+   people.  The authors of this document do not claim exclusive credit.
+   Credit goes to Brian Carpenter, Christian Huitema, Aidan Williams,
+   Andrew White, Charlie Perkins, and many others.  The authors would
+   also like to thank Brian Carpenter, Charlie Perkins, Harald
+   Alvestrand, Keith Moore, Margaret Wasserman, Shannon Behrens, Alan
+   Beard, Hans Kruse, Geoff Huston, Pekka Savola, Christian Huitema, Tim
+   Chown, Steve Bellovin, Alex Zinin, Tony Hain, Bill Fenner, Sam
+   Hartman, and Elwyn Davies for their comments and suggestions on this
+   document.
+
+3.  Local IPv6 Unicast Addresses
+
+3.1.  Format
+
+   The Local IPv6 addresses are created using a pseudo-randomly
+   allocated global ID.  They have the following format:
+
+      | 7 bits |1|  40 bits   |  16 bits  |          64 bits           |
+      +--------+-+------------+-----------+----------------------------+
+      | Prefix |L| Global ID  | Subnet ID |        Interface ID        |
+      +--------+-+------------+-----------+----------------------------+
+
+   Where:
+
+      Prefix            FC00::/7 prefix to identify Local IPv6 unicast
+                        addresses.
+
+      L                 Set to 1 if the prefix is locally assigned.
+                        Set to 0 may be defined in the future.  See
+                        Section 3.2 for additional information.
+
+      Global ID         40-bit global identifier used to create a
+                        globally unique prefix.  See Section 3.2 for
+                        additional information.
+
+      Subnet ID         16-bit Subnet ID is an identifier of a subnet
+                        within the site.
+
+      Interface ID      64-bit Interface ID as defined in [ADDARCH].
+
+
+
+
+Hinden & Haberman           Standards Track                     [Page 3]
+
+RFC 4193          Unique Local IPv6 Unicast Addresses       October 2005
+
+
+3.1.1.  Background
+
+   There were a range of choices available when choosing the size of the
+   prefix and Global ID field length.  There is a direct tradeoff
+   between having a Global ID field large enough to support foreseeable
+   future growth and not using too much of the IPv6 address space
+   needlessly.  A reasonable way of evaluating a specific field length
+   is to compare it to a projected 2050 world population of 9.3 billion
+   [POPUL] and the number of resulting /48 prefixes per person.  A range
+   of prefix choices is shown in the following table:
+
+    Prefix  Global ID     Number of          Prefixes    % of IPv6
+            Length        /48 Prefixes       per Person  Address Space
+
+    /11       37           137,438,953,472     15         0.049%
+    /10       38           274,877,906,944     30         0.098%
+    /9        39           549,755,813,888     59         0.195%
+    /8        40         1,099,511,627,776    118         0.391%
+    /7        41         2,199,023,255,552    236         0.781%
+    /6        42         4,398,046,511,104    473         1.563%
+
+   A very high utilization ratio of these allocations can be assumed
+   because the Global ID field does not require internal structure, and
+   there is no reason to be able to aggregate the prefixes.
+
+   The authors believe that a /7 prefix resulting in a 41-bit Global ID
+   space (including the L bit) is a good choice.  It provides for a
+   large number of assignments (i.e., 2.2 trillion) and at the same time
+   uses less than .8% of the total IPv6 address space.  It is unlikely
+   that this space will be exhausted.  If more than this were to be
+   needed, then additional IPv6 address space could be allocated for
+   this purpose.
+
+3.2.  Global ID
+
+   The allocation of Global IDs is pseudo-random [RANDOM].  They MUST
+   NOT be assigned sequentially or with well-known numbers.  This is to
+   ensure that there is not any relationship between allocations and to
+   help clarify that these prefixes are not intended to be routed
+   globally.  Specifically, these prefixes are not designed to
+   aggregate.
+
+   This document defines a specific local method to allocate Global IDs,
+   indicated by setting the L bit to 1.  Another method, indicated by
+   clearing the L bit, may be defined later.  Apart from the allocation
+   method, all Local IPv6 addresses behave and are treated identically.
+
+
+
+
+
+Hinden & Haberman           Standards Track                     [Page 4]
+
+RFC 4193          Unique Local IPv6 Unicast Addresses       October 2005
+
+
+   The local assignments are self-generated and do not need any central
+   coordination or assignment, but have an extremely high probability of
+   being unique.
+
+3.2.1.  Locally Assigned Global IDs
+
+   Locally assigned Global IDs MUST be generated with a pseudo-random
+   algorithm consistent with [RANDOM].  Section 3.2.2 describes a
+   suggested algorithm.  It is important that all sites generating
+   Global IDs use a functionally similar algorithm to ensure there is a
+   high probability of uniqueness.
+
+   The use of a pseudo-random algorithm to generate Global IDs in the
+   locally assigned prefix gives an assurance that any network numbered
+   using such a prefix is highly unlikely to have that address space
+   clash with any other network that has another locally assigned prefix
+   allocated to it.  This is a particularly useful property when
+   considering a number of scenarios including networks that merge,
+   overlapping VPN address space, or hosts mobile between such networks.
+
+3.2.2.  Sample Code for Pseudo-Random Global ID Algorithm
+
+   The algorithm described below is intended to be used for locally
+   assigned Global IDs.  In each case the resulting global ID will be
+   used in the appropriate prefix as defined in Section 3.2.
+
+     1) Obtain the current time of day in 64-bit NTP format [NTP].
+
+     2) Obtain an EUI-64 identifier from the system running this
+        algorithm.  If an EUI-64 does not exist, one can be created from
+        a 48-bit MAC address as specified in [ADDARCH].  If an EUI-64
+        cannot be obtained or created, a suitably unique identifier,
+        local to the node, should be used (e.g., system serial number).
+
+     3) Concatenate the time of day with the system-specific identifier
+        in order to create a key.
+
+     4) Compute an SHA-1 digest on the key as specified in [FIPS, SHA1];
+        the resulting value is 160 bits.
+
+     5) Use the least significant 40 bits as the Global ID.
+
+     6) Concatenate FC00::/7, the L bit set to 1, and the 40-bit Global
+        ID to create a Local IPv6 address prefix.
+
+   This algorithm will result in a Global ID that is reasonably unique
+   and can be used to create a locally assigned Local IPv6 address
+   prefix.
+
+
+
+Hinden & Haberman           Standards Track                     [Page 5]
+
+RFC 4193          Unique Local IPv6 Unicast Addresses       October 2005
+
+
+3.2.3.  Analysis of the Uniqueness of Global IDs
+
+   The selection of a pseudo random Global ID is similar to the
+   selection of an SSRC identifier in RTP/RTCP defined in Section 8.1 of
+   [RTP].  This analysis is adapted from that document.
+
+   Since Global IDs are chosen randomly (and independently), it is
+   possible that separate networks have chosen the same Global ID.  For
+   any given network, with one or more random Global IDs, that has
+   inter-connections to other such networks, having a total of N such
+   IDs, the probability that two or more of these IDs will collide can
+   be approximated using the formula:
+
+      P = 1 - exp(-N**2 / 2**(L+1))
+
+   where P is the probability of collision, N is the number of
+   interconnected Global IDs, and L is the length of the Global ID.
+
+   The following table shows the probability of a collision for a range
+   of connections using a 40-bit Global ID field.
+
+      Connections      Probability of Collision
+
+          2                1.81*10^-12
+         10                4.54*10^-11
+        100                4.54*10^-09
+       1000                4.54*10^-07
+      10000                4.54*10^-05
+
+   Based on this analysis, the uniqueness of locally generated Global
+   IDs is adequate for sites planning a small to moderate amount of
+   inter-site communication using locally generated Global IDs.
+
+3.3.  Scope Definition
+
+   By default, the scope of these addresses is global.  That is, they
+   are not limited by ambiguity like the site-local addresses defined in
+   [ADDARCH].  Rather, these prefixes are globally unique, and as such,
+   their applicability is greater than site-local addresses.  Their
+   limitation is in the routability of the prefixes, which is limited to
+   a site and any explicit routing agreements with other sites to
+   propagate them (also see Section 4.1).  Also, unlike site-locals, a
+   site may have more than one of these prefixes and use them at the
+   same time.
+
+
+
+
+
+
+
+Hinden & Haberman           Standards Track                     [Page 6]
+
+RFC 4193          Unique Local IPv6 Unicast Addresses       October 2005
+
+
+4.  Operational Guidelines
+
+   The guidelines in this section do not require any change to the
+   normal routing and forwarding functionality in an IPv6 host or
+   router.  These are configuration and operational usage guidelines.
+
+4.1.  Routing
+
+   Local IPv6 addresses are designed to be routed inside of a site in
+   the same manner as other types of unicast addresses.  They can be
+   carried in any IPv6 routing protocol without any change.
+
+   It is expected that they would share the same Subnet IDs with
+   provider-based global unicast addresses, if they were being used
+   concurrently [GLOBAL].
+
+   The default behavior of exterior routing protocol sessions between
+   administrative routing regions must be to ignore receipt of and not
+   advertise prefixes in the FC00::/7 block.  A network operator may
+   specifically configure prefixes longer than FC00::/7 for inter-site
+   communication.
+
+   If BGP is being used at the site border with an ISP, the default BGP
+   configuration must filter out any Local IPv6 address prefixes, both
+   incoming and outgoing.  It must be set both to keep any Local IPv6
+   address prefixes from being advertised outside of the site as well as
+   to keep these prefixes from being learned from another site.  The
+   exception to this is if there are specific /48 or longer routes
+   created for one or more Local IPv6 prefixes.
+
+   For link-state IGPs, it is suggested that a site utilizing IPv6 local
+   address prefixes be contained within one IGP domain or area.  By
+   containing an IPv6 local address prefix to a single link-state area
+   or domain, the distribution of prefixes can be controlled.
+
+4.2.  Renumbering and Site Merging
+
+   The use of Local IPv6 addresses in a site results in making
+   communication that uses these addresses independent of renumbering a
+   site's provider-based global addresses.
+
+   When merging multiple sites, the addresses created with these
+   prefixes are unlikely to need to be renumbered because all of the
+   addresses have a high probability of being unique.  Routes for each
+   specific prefix would have to be configured to allow routing to work
+   correctly between the formerly separate sites.
+
+
+
+
+
+Hinden & Haberman           Standards Track                     [Page 7]
+
+RFC 4193          Unique Local IPv6 Unicast Addresses       October 2005
+
+
+4.3.  Site Border Router and Firewall Packet Filtering
+
+   While no serious harm will be done if packets with these addresses
+   are sent outside of a site via a default route, it is recommended
+   that routers be configured by default to keep any packets with Local
+   IPv6 addresses from leaking outside of the site and to keep any site
+   prefixes from being advertised outside of their site.
+
+   Site border routers and firewalls should be configured to not forward
+   any packets with Local IPv6 source or destination addresses outside
+   of the site, unless they have been explicitly configured with routing
+   information about specific /48 or longer Local IPv6 prefixes.  This
+   will ensure that packets with Local IPv6 destination addresses will
+   not be forwarded outside of the site via a default route.  The
+   default behavior of these devices should be to install a "reject"
+   route for these prefixes.  Site border routers should respond with
+   the appropriate ICMPv6 Destination Unreachable message to inform the
+   source that the packet was not forwarded. [ICMPV6].  This feedback is
+   important to avoid transport protocol timeouts.
+
+   Routers that maintain peering arrangements between Autonomous Systems
+   throughout the Internet should obey the recommendations for site
+   border routers, unless configured otherwise.
+
+4.4.  DNS Issues
+
+   At the present time, AAAA and PTR records for locally assigned local
+   IPv6 addresses are not recommended to be installed in the global DNS.
+
+   For background on this recommendation, one of the concerns about
+   adding AAAA and PTR records to the global DNS for locally assigned
+   Local IPv6 addresses stems from the lack of complete assurance that
+   the prefixes are unique.  There is a small possibility that the same
+   locally assigned IPv6 Local addresses will be used by two different
+   organizations both claiming to be authoritative with different
+   contents.  In this scenario, it is likely there will be a connection
+   attempt to the closest host with the corresponding locally assigned
+   IPv6 Local address.  This may result in connection timeouts,
+   connection failures indicated by ICMP Destination Unreachable
+   messages, or successful connections to the wrong host.  Due to this
+   concern, adding AAAA records for these addresses to the global DNS is
+   thought to be unwise.
+
+   Reverse (address-to-name) queries for locally assigned IPv6 Local
+   addresses MUST NOT be sent to name servers for the global DNS, due to
+   the load that such queries would create for the authoritative name
+   servers for the ip6.arpa zone.  This form of query load is not
+   specific to locally assigned Local IPv6 addresses; any current form
+
+
+
+Hinden & Haberman           Standards Track                     [Page 8]
+
+RFC 4193          Unique Local IPv6 Unicast Addresses       October 2005
+
+
+   of local addressing creates additional load of this kind, due to
+   reverse queries leaking out of the site.  However, since allowing
+   such queries to escape from the site serves no useful purpose, there
+   is no good reason to make the existing load problems worse.
+
+   The recommended way to avoid sending such queries to nameservers for
+   the global DNS is for recursive name server implementations to act as
+   if they were authoritative for an empty d.f.ip6.arpa zone and return
+   RCODE 3 for any such query.  Implementations that choose this
+   strategy should allow it to be overridden, but returning an RCODE 3
+   response for such queries should be the default, both because this
+   will reduce the query load problem and also because, if the site
+   administrator has not set up the reverse tree corresponding to the
+   locally assigned IPv6 Local addresses in use, returning RCODE 3 is in
+   fact the correct answer.
+
+4.5.  Application and Higher Level Protocol Issues
+
+   Application and other higher level protocols can treat Local IPv6
+   addresses in the same manner as other types of global unicast
+   addresses.  No special handling is required.  This type of address
+   may not be reachable, but that is no different from other types of
+   IPv6 global unicast address.  Applications need to be able to handle
+   multiple addresses that may or may not be reachable at any point in
+   time.  In most cases, this complexity should be hidden in APIs.
+
+   From a host's perspective, the difference between Local IPv6 and
+   other types of global unicast addresses shows up as different
+   reachability and could be handled by default in that way.  In some
+   cases, it is better for nodes and applications to treat them
+   differently from global unicast addresses.  A starting point might be
+   to give them preference over global unicast, but fall back to global
+   unicast if a particular destination is found to be unreachable.  Much
+   of this behavior can be controlled by how they are allocated to nodes
+   and put into the DNS.  However, it is useful if a host can have both
+   types of addresses and use them appropriately.
+
+   Note that the address selection mechanisms of [ADDSEL], and in
+   particular the policy override mechanism replacing default address
+   selection, are expected to be used on a site where Local IPv6
+   addresses are configured.
+
+4.6.  Use of Local IPv6 Addresses for Local Communication
+
+   Local IPv6 addresses, like global scope unicast addresses, are only
+   assigned to nodes if their use has been enabled (via IPv6 address
+   autoconfiguration [ADDAUTO], DHCPv6 [DHCP6], or manually).  They are
+
+
+
+
+Hinden & Haberman           Standards Track                     [Page 9]
+
+RFC 4193          Unique Local IPv6 Unicast Addresses       October 2005
+
+
+   not created automatically in the way that IPv6 link-local addresses
+   are and will not appear or be used unless they are purposely
+   configured.
+
+   In order for hosts to autoconfigure Local IPv6 addresses, routers
+   have to be configured to advertise Local IPv6 /64 prefixes in router
+   advertisements, or a DHCPv6 server must have been configured to
+   assign them.  In order for a node to learn the Local IPv6 address of
+   another node, the Local IPv6 address must have been installed in a
+   naming system (e.g., DNS, proprietary naming system, etc.)  For these
+   reasons, controlling their usage in a site is straightforward.
+
+   To limit the use of Local IPv6 addresses the following guidelines
+   apply:
+
+      - Nodes that are to only be reachable inside of a site:  The local
+        DNS should be configured to only include the Local IPv6
+        addresses of these nodes.  Nodes with only Local IPv6 addresses
+        must not be installed in the global DNS.
+
+      - Nodes that are to be limited to only communicate with other
+        nodes in the site:  These nodes should be set to only
+        autoconfigure Local IPv6 addresses via [ADDAUTO] or to only
+        receive Local IPv6 addresses via [DHCP6].  Note: For the case
+        where both global and Local IPv6 prefixes are being advertised
+        on a subnet, this will require a switch in the devices to only
+        autoconfigure Local IPv6 addresses.
+
+      - Nodes that are to be reachable from inside of the site and from
+        outside of the site:  The DNS should be configured to include
+        the global addresses of these nodes.  The local DNS may be
+        configured to also include the Local IPv6 addresses of these
+        nodes.
+
+      - Nodes that can communicate with other nodes inside of the site
+        and outside of the site: These nodes should autoconfigure global
+        addresses via [ADDAUTO] or receive global address via [DHCP6].
+        They may also obtain Local IPv6 addresses via the same
+        mechanisms.
+
+4.7.  Use of Local IPv6 Addresses with VPNs
+
+   Local IPv6 addresses can be used for inter-site Virtual Private
+   Networks (VPN) if appropriate routes are set up.  Because the
+   addresses are unique, these VPNs will work reliably and without the
+   need for translation.  They have the additional property that they
+   will continue to work if the individual sites are renumbered or
+   merged.
+
+
+
+Hinden & Haberman           Standards Track                    [Page 10]
+
+RFC 4193          Unique Local IPv6 Unicast Addresses       October 2005
+
+
+5.  Global Routing Considerations
+
+   Section 4.1 provides operational guidelines that forbid default
+   routing of local addresses between sites.  Concerns were raised to
+   the IPv6 working group and to the IETF as a whole that sites may
+   attempt to use local addresses as globally routed provider-
+   independent addresses.  This section describes why using local
+   addresses as globally-routed provider-independent addresses is
+   unadvisable.
+
+5.1.  From the Standpoint of the Internet
+
+   There is a mismatch between the structure of IPv6 local addresses and
+   the normal IPv6 wide area routing model.  The /48 prefix of an IPv6
+   local addresses fits nowhere in the normal hierarchy of IPv6 unicast
+   addresses.  Normal IPv6 unicast addresses can be routed
+   hierarchically down to physical subnet (link) level and only have to
+   be flat-routed on the physical subnet.  IPv6 local addresses would
+   have to be flat-routed even over the wide area Internet.
+
+   Thus, packets whose destination address is an IPv6 local address
+   could be routed over the wide area only if the corresponding /48
+   prefix were carried by the wide area routing protocol in use, such as
+   BGP.  This contravenes the operational assumption that long prefixes
+   will be aggregated into many fewer short prefixes, to limit the table
+   size and convergence time of the routing protocol.  If a network uses
+   both normal IPv6 addresses [ADDARCH] and IPv6 local addresses, these
+   types of addresses will certainly not aggregate with each other,
+   since they differ from the most significant bit onwards.  Neither
+   will IPv6 local addresses aggregate with each other, due to their
+   random bit patterns.  This means that there would be a very
+   significant operational penalty for attempting to use IPv6 local
+   address prefixes generically with currently known wide area routing
+   technology.
+
+5.2.  From the Standpoint of a Site
+
+   There are a number of design factors in IPv6 local addresses that
+   reduce the likelihood that IPv6 local addresses will be used as
+   arbitrary global unicast addresses.  These include:
+
+      - The default rules to filter packets and routes make it very
+        difficult to use IPv6 local addresses for arbitrary use across
+        the Internet.  For a site to use them as general purpose unicast
+        addresses, it would have to make sure that the default rules
+        were not being used by all other sites and intermediate ISPs
+        used for their current and future communication.
+
+
+
+
+Hinden & Haberman           Standards Track                    [Page 11]
+
+RFC 4193          Unique Local IPv6 Unicast Addresses       October 2005
+
+
+      - They are not mathematically guaranteed to be unique and are not
+        registered in public databases.  Collisions, while highly
+        unlikely, are possible and a collision can compromise the
+        integrity of the communications.  The lack of public
+        registration creates operational problems.
+
+      - The addresses are allocated randomly.  If a site had multiple
+        prefixes that it wanted to be used globally, the cost of
+        advertising them would be very high because they could not be
+        aggregated.
+
+      - They have a long prefix (i.e., /48) so a single local address
+        prefix doesn't provide enough address space to be used
+        exclusively by the largest organizations.
+
+6.  Advantages and Disadvantages
+
+6.1.  Advantages
+
+   This approach has the following advantages:
+
+      - Provides Local IPv6 prefixes that can be used independently of
+        any provider-based IPv6 unicast address allocations.  This is
+        useful for sites not always connected to the Internet or sites
+        that wish to have a distinct prefix that can be used to localize
+        traffic inside of the site.
+
+      - Applications can treat these addresses in an identical manner as
+        any other type of global IPv6 unicast addresses.
+
+      - Sites can be merged without any renumbering of the Local IPv6
+        addresses.
+
+      - Sites can change their provider-based IPv6 unicast address
+        without disrupting any communication that uses Local IPv6
+        addresses.
+
+      - Well-known prefix that allows for easy filtering at site
+        boundary.
+
+      - Can be used for inter-site VPNs.
+
+      - If accidently leaked outside of a site via routing or DNS, there
+        is no conflict with any other addresses.
+
+
+
+
+
+
+
+Hinden & Haberman           Standards Track                    [Page 12]
+
+RFC 4193          Unique Local IPv6 Unicast Addresses       October 2005
+
+
+6.2.  Disadvantages
+
+   This approach has the following disadvantages:
+
+      - Not possible to route Local IPv6 prefixes on the global Internet
+        with current routing technology.  Consequentially, it is
+        necessary to have the default behavior of site border routers to
+        filter these addresses.
+
+      - There is a very low probability of non-unique locally assigned
+        Global IDs being generated by the algorithm in Section 3.2.3.
+        This risk can be ignored for all practical purposes, but it
+        leads to a theoretical risk of clashing address prefixes.
+
+7.  Security Considerations
+
+   Local IPv6 addresses do not provide any inherent security to the
+   nodes that use them.  They may be used with filters at site
+   boundaries to keep Local IPv6 traffic inside of the site, but this is
+   no more or less secure than filtering any other type of global IPv6
+   unicast addresses.
+
+   Local IPv6 addresses do allow for address-based security mechanisms,
+   including IPsec, across end to end VPN connections.
+
+8.  IANA Considerations
+
+   The IANA has assigned the FC00::/7 prefix to "Unique Local Unicast".
+
+9.  References
+
+9.1.  Normative References
+
+   [ADDARCH]  Hinden, R. and S. Deering, "Internet Protocol Version 6
+             (IPv6) Addressing Architecture", RFC 3513, April 2003.
+
+   [FIPS]    "Federal Information Processing Standards Publication",
+             (FIPS PUB) 180-1, Secure Hash Standard, 17 April 1995.
+
+   [GLOBAL]  Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global
+             Unicast Address Format", RFC 3587, August 2003.
+
+   [ICMPV6]  Conta, A. and S. Deering, "Internet Control Message
+             Protocol (ICMPv6) for the Internet Protocol Version 6
+             (IPv6) Specification", RFC 2463, December 1998.
+
+
+
+
+
+
+Hinden & Haberman           Standards Track                    [Page 13]
+
+RFC 4193          Unique Local IPv6 Unicast Addresses       October 2005
+
+
+   [IPV6]    Deering, S. and R. Hinden, "Internet Protocol, Version 6
+             (IPv6) Specification", RFC 2460, December 1998.
+
+   [NTP]     Mills, D., "Network Time Protocol (Version 3)
+             Specification, Implementation and Analysis", RFC 1305,
+             March 1992.
+
+   [RANDOM]  Eastlake, D., 3rd, Schiller, J., and S. Crocker,
+             "Randomness Requirements for Security", BCP 106, RFC 4086,
+             June 2005.
+
+   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+             Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [SHA1]    Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm 1
+             (SHA1)", RFC 3174, September 2001.
+
+9.2.  Informative References
+
+   [ADDAUTO] Thomson, S. and T. Narten, "IPv6 Stateless Address
+             Autoconfiguration", RFC 2462, December 1998.
+
+   [ADDSEL]  Draves, R., "Default Address Selection for Internet
+             Protocol version 6 (IPv6)", RFC 3484, February 2003.
+
+   [DHCP6]   Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and
+             M. Carney, "Dynamic Host Configuration Protocol for IPv6
+             (DHCPv6)", RFC 3315, July 2003.
+
+   [POPUL]   Population Reference Bureau, "World Population Data Sheet
+             of the Population Reference Bureau 2002",  August 2002.
+
+   [RTP]     Schulzrinne, H.,  Casner, S., Frederick, R., and V.
+             Jacobson, "RTP: A Transport Protocol for Real-Time
+             Applications", STD 64, RFC 3550, July 2003.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hinden & Haberman           Standards Track                    [Page 14]
+
+RFC 4193          Unique Local IPv6 Unicast Addresses       October 2005
+
+
+Authors' Addresses
+
+   Robert M. Hinden
+   Nokia
+   313 Fairchild Drive
+   Mountain View, CA 94043
+   USA
+
+   Phone: +1 650 625-2004
+   EMail: bob.hinden@nokia.com
+
+
+   Brian Haberman
+   Johns Hopkins University
+   Applied Physics Lab
+   11100 Johns Hopkins Road
+   Laurel, MD 20723
+   USA
+
+   Phone: +1 443 778 1319
+   EMail: brian@innovationslab.net
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hinden & Haberman           Standards Track                    [Page 15]
+
+RFC 4193          Unique Local IPv6 Unicast Addresses       October 2005
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2005).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at ietf-
+   ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+Hinden & Haberman           Standards Track                    [Page 16]
+
diff --git a/doc/rfc/rfc4255.txt b/doc/rfc/rfc4255.txt
new file mode 100644
index 0000000..f350b7a
--- /dev/null
+++ b/doc/rfc/rfc4255.txt
@@ -0,0 +1,507 @@
+
+
+
+
+
+
+Network Working Group                                        J. Schlyter
+Request for Comments: 4255                                       OpenSSH
+Category: Standards Track                                     W. Griffin
+                                                                  SPARTA
+                                                            January 2006
+
+
+   Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   This document describes a method of verifying Secure Shell (SSH) host
+   keys using Domain Name System Security (DNSSEC).  The document
+   defines a new DNS resource record that contains a standard SSH key
+   fingerprint.
+
+Table of Contents
+
+   1. Introduction ....................................................2
+   2. SSH Host Key Verification .......................................2
+      2.1. Method .....................................................2
+      2.2. Implementation Notes .......................................2
+      2.3. Fingerprint Matching .......................................3
+      2.4. Authentication .............................................3
+   3. The SSHFP Resource Record .......................................3
+      3.1. The SSHFP RDATA Format .....................................4
+           3.1.1. Algorithm Number Specification ......................4
+           3.1.2. Fingerprint Type Specification ......................4
+           3.1.3. Fingerprint .........................................5
+      3.2. Presentation Format of the SSHFP RR ........................5
+   4. Security Considerations .........................................5
+   5. IANA Considerations .............................................6
+   6. Normative References ............................................7
+   7. Informational References ........................................7
+   8. Acknowledgements ................................................8
+
+
+
+
+Schlyter & Griffin          Standards Track                     [Page 1]
+
+RFC 4255                DNS and SSH Fingerprints            January 2006
+
+
+1.  Introduction
+
+   The SSH [6] protocol provides secure remote login and other secure
+   network services over an insecure network.  The security of the
+   connection relies on the server authenticating itself to the client
+   as well as the user authenticating itself to the server.
+
+   If a connection is established to a server whose public key is not
+   already known to the client, a fingerprint of the key is presented to
+   the user for verification.  If the user decides that the fingerprint
+   is correct and accepts the key, the key is saved locally and used for
+   verification for all following connections.  While some security-
+   conscious users verify the fingerprint out-of-band before accepting
+   the key, many users blindly accept the presented key.
+
+   The method described here can provide out-of-band verification by
+   looking up a fingerprint of the server public key in the DNS [1][2]
+   and using DNSSEC [5] to verify the lookup.
+
+   In order to distribute the fingerprint using DNS, this document
+   defines a new DNS resource record, "SSHFP", to carry the fingerprint.
+
+   Basic understanding of the DNS system [1][2] and the DNS security
+   extensions [5] is assumed by this document.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [3].
+
+2.  SSH Host Key Verification
+
+2.1.  Method
+
+   Upon connection to an SSH server, the SSH client MAY look up the
+   SSHFP resource record(s) for the host it is connecting to.  If the
+   algorithm and fingerprint of the key received from the SSH server
+   match the algorithm and fingerprint of one of the SSHFP resource
+   record(s) returned from DNS, the client MAY accept the identity of
+   the server.
+
+2.2.  Implementation Notes
+
+   Client implementors SHOULD provide a configurable policy used to
+   select the order of methods used to verify a host key.  This document
+   defines one method: Fingerprint storage in DNS.  Another method
+   defined in the SSH Architecture [6] uses local files to store keys
+   for comparison.  Other methods that could be defined in the future
+   might include storing fingerprints in LDAP or other databases.  A
+
+
+
+Schlyter & Griffin          Standards Track                     [Page 2]
+
+RFC 4255                DNS and SSH Fingerprints            January 2006
+
+
+   configurable policy will allow administrators to determine which
+   methods they want to use and in what order the methods should be
+   prioritized.  This will allow administrators to determine how much
+   trust they want to place in the different methods.
+
+   One specific scenario for having a configurable policy is where
+   clients do not use fully qualified host names to connect to servers.
+   In this scenario, the implementation SHOULD verify the host key
+   against a local database before verifying the key via the fingerprint
+   returned from DNS.  This would help prevent an attacker from
+   injecting a DNS search path into the local resolver and forcing the
+   client to connect to a different host.
+
+2.3.  Fingerprint Matching
+
+   The public key and the SSHFP resource record are matched together by
+   comparing algorithm number and fingerprint.
+
+      The public key algorithm and the SSHFP algorithm number MUST
+      match.
+
+      A message digest of the public key, using the message digest
+      algorithm specified in the SSHFP fingerprint type, MUST match the
+      SSHFP fingerprint.
+
+2.4.  Authentication
+
+   A public key verified using this method MUST NOT be trusted if the
+   SSHFP resource record (RR) used for verification was not
+   authenticated by a trusted SIG RR.
+
+   Clients that do validate the DNSSEC signatures themselves SHOULD use
+   standard DNSSEC validation procedures.
+
+   Clients that do not validate the DNSSEC signatures themselves MUST
+   use a secure transport (e.g., TSIG [9], SIG(0) [10], or IPsec [8])
+   between themselves and the entity performing the signature
+   validation.
+
+3.  The SSHFP Resource Record
+
+   The SSHFP resource record (RR) is used to store a fingerprint of an
+   SSH public host key that is associated with a Domain Name System
+   (DNS) name.
+
+   The RR type code for the SSHFP RR is 44.
+
+
+
+
+
+Schlyter & Griffin          Standards Track                     [Page 3]
+
+RFC 4255                DNS and SSH Fingerprints            January 2006
+
+
+3.1.  The SSHFP RDATA Format
+
+   The RDATA for a SSHFP RR consists of an algorithm number, fingerprint
+   type and the fingerprint of the public host key.
+
+       1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
+       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |   algorithm   |    fp type    |                               /
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               /
+       /                                                               /
+       /                          fingerprint                          /
+       /                                                               /
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+3.1.1.  Algorithm Number Specification
+
+   This algorithm number octet describes the algorithm of the public
+   key.  The following values are assigned:
+
+          Value    Algorithm name
+          -----    --------------
+          0        reserved
+          1        RSA
+          2        DSS
+
+   Reserving other types requires IETF consensus [4].
+
+3.1.2.  Fingerprint Type Specification
+
+   The fingerprint type octet describes the message-digest algorithm
+   used to calculate the fingerprint of the public key.  The following
+   values are assigned:
+
+          Value    Fingerprint type
+          -----    ----------------
+          0        reserved
+          1        SHA-1
+
+   Reserving other types requires IETF consensus [4].
+
+   For interoperability reasons, as few fingerprint types as possible
+   should be reserved.  The only reason to reserve additional types is
+   to increase security.
+
+
+
+
+
+
+
+Schlyter & Griffin          Standards Track                     [Page 4]
+
+RFC 4255                DNS and SSH Fingerprints            January 2006
+
+
+3.1.3.  Fingerprint
+
+   The fingerprint is calculated over the public key blob as described
+   in [7].
+
+   The message-digest algorithm is presumed to produce an opaque octet
+   string output, which is placed as-is in the RDATA fingerprint field.
+
+3.2.  Presentation Format of the SSHFP RR
+
+   The RDATA of the presentation format of the SSHFP resource record
+   consists of two numbers (algorithm and fingerprint type) followed by
+   the fingerprint itself, presented in hex, e.g.:
+
+       host.example.  SSHFP 2 1 123456789abcdef67890123456789abcdef67890
+
+   The use of mnemonics instead of numbers is not allowed.
+
+4.  Security Considerations
+
+   Currently, the amount of trust a user can realistically place in a
+   server key is proportional to the amount of attention paid to
+   verifying that the public key presented actually corresponds to the
+   private key of the server.  If a user accepts a key without verifying
+   the fingerprint with something learned through a secured channel, the
+   connection is vulnerable to a man-in-the-middle attack.
+
+   The overall security of using SSHFP for SSH host key verification is
+   dependent on the security policies of the SSH host administrator and
+   DNS zone administrator (in transferring the fingerprint), detailed
+   aspects of how verification is done in the SSH implementation, and in
+   the client's diligence in accessing the DNS in a secure manner.
+
+   One such aspect is in which order fingerprints are looked up (e.g.,
+   first checking local file and then SSHFP).  We note that, in addition
+   to protecting the first-time transfer of host keys, SSHFP can
+   optionally be used for stronger host key protection.
+
+      If SSHFP is checked first, new SSH host keys may be distributed by
+      replacing the corresponding SSHFP in DNS.
+
+      If SSH host key verification can be configured to require SSHFP,
+      SSH host key revocation can be implemented by removing the
+      corresponding SSHFP from DNS.
+
+
+
+
+
+
+
+Schlyter & Griffin          Standards Track                     [Page 5]
+
+RFC 4255                DNS and SSH Fingerprints            January 2006
+
+
+   As stated in Section 2.2, we recommend that SSH implementors provide
+   a policy mechanism to control the order of methods used for host key
+   verification.  One specific scenario for having a configurable policy
+   is where clients use unqualified host names to connect to servers.
+   In this case, we recommend that SSH implementations check the host
+   key against a local database before verifying the key via the
+   fingerprint returned from DNS.  This would help prevent an attacker
+   from injecting a DNS search path into the local resolver and forcing
+   the client to connect to a different host.
+
+   A different approach to solve the DNS search path issue would be for
+   clients to use a trusted DNS search path, i.e., one not acquired
+   through DHCP or other autoconfiguration mechanisms.  Since there is
+   no way with current DNS lookup APIs to tell whether a search path is
+   from a trusted source, the entire client system would need to be
+   configured with this trusted DNS search path.
+
+   Another dependency is on the implementation of DNSSEC itself.  As
+   stated in Section 2.4, we mandate the use of secure methods for
+   lookup and that SSHFP RRs are authenticated by trusted SIG RRs.  This
+   is especially important if SSHFP is to be used as a basis for host
+   key rollover and/or revocation, as described above.
+
+   Since DNSSEC only protects the integrity of the host key fingerprint
+   after it is signed by the DNS zone administrator, the fingerprint
+   must be transferred securely from the SSH host administrator to the
+   DNS zone administrator.  This could be done manually between the
+   administrators or automatically using secure DNS dynamic update [11]
+   between the SSH server and the nameserver.  We note that this is no
+   different from other key enrollment situations, e.g., a client
+   sending a certificate request to a certificate authority for signing.
+
+5.  IANA Considerations
+
+   IANA has allocated the RR type code 44 for SSHFP from the standard RR
+   type space.
+
+   IANA has opened a new registry for the SSHFP RR type for public key
+   algorithms.  The defined types are:
+
+      0 is reserved
+      1 is RSA
+      2 is DSA
+
+   Adding new reservations requires IETF consensus [4].
+
+
+
+
+
+
+Schlyter & Griffin          Standards Track                     [Page 6]
+
+RFC 4255                DNS and SSH Fingerprints            January 2006
+
+
+   IANA has opened a new registry for the SSHFP RR type for fingerprint
+   types.  The defined types are:
+
+      0 is reserved
+      1 is SHA-1
+
+   Adding new reservations requires IETF consensus [4].
+
+6.  Normative References
+
+   [1]   Mockapetris, P., "Domain names - concepts and facilities", STD
+         13, RFC 1034, November 1987.
+
+   [2]   Mockapetris, P., "Domain names - implementation and
+         specification", STD 13, RFC 1035, November 1987.
+
+   [3]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
+         Levels", BCP 14, RFC 2119, March 1997.
+
+   [4]   Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
+         Considerations Section in RFCs", BCP 26, RFC 2434, October
+         1998.
+
+   [5]   Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+         "DNS Security Introduction and Requirements", RFC 4033, March
+         2005.
+
+         Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+         "Resource Records for the DNS Security Extensions", RFC 4034,
+         March 2005.
+
+         Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+         "Protocol Modifications for the DNS Security Extensions", RFC
+         4035, March 2005.
+
+   [6]   Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
+         Protocol Architecture", RFC 4251, January 2006.
+
+   [7]   Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
+         Transport Layer Protocol", RFC 4253, January 2006.
+
+7.  Informational References
+
+   [8]   Thayer, R., Doraswamy, N., and R. Glenn, "IP Security Document
+         Roadmap", RFC 2411, November 1998.
+
+
+
+
+
+
+Schlyter & Griffin          Standards Track                     [Page 7]
+
+RFC 4255                DNS and SSH Fingerprints            January 2006
+
+
+   [9]   Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
+         Wellington, "Secret Key Transaction Authentication for DNS
+         (TSIG)", RFC 2845, May 2000.
+
+   [10]  Eastlake 3rd, D., "DNS Request and Transaction Signatures
+         ( SIG(0)s )", RFC 2931, September 2000.
+
+   [11]  Wellington, B., "Secure Domain Name System (DNS) Dynamic
+         Update", RFC 3007, November 2000.
+
+8.  Acknowledgements
+
+   The authors gratefully acknowledge, in no particular order, the
+   contributions of the following persons:
+
+      Martin Fredriksson
+
+      Olafur Gudmundsson
+
+      Edward Lewis
+
+      Bill Sommerfeld
+
+Authors' Addresses
+
+   Jakob Schlyter
+   OpenSSH
+   812 23rd Avenue SE
+   Calgary, Alberta  T2G 1N8
+   Canada
+
+   EMail: jakob@openssh.com
+   URI:   http://www.openssh.com/
+
+
+   Wesley Griffin
+   SPARTA
+   7075 Samuel Morse Drive
+   Columbia, MD  21046
+   USA
+
+   EMail: wgriffin@sparta.com
+   URI:   http://www.sparta.com/
+
+
+
+
+
+
+
+
+Schlyter & Griffin          Standards Track                     [Page 8]
+
+RFC 4255                DNS and SSH Fingerprints            January 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Schlyter & Griffin          Standards Track                     [Page 9]
+
diff --git a/doc/rfc/rfc4343.txt b/doc/rfc/rfc4343.txt
new file mode 100644
index 0000000..621420a
--- /dev/null
+++ b/doc/rfc/rfc4343.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+Network Working Group                                    D. Eastlake 3rd
+Request for Comments: 4343                         Motorola Laboratories
+Updates: 1034, 1035, 2181                                   January 2006
+Category: Standards Track
+
+
+       Domain Name System (DNS) Case Insensitivity Clarification
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   Domain Name System (DNS) names are "case insensitive".  This document
+   explains exactly what that means and provides a clear specification
+   of the rules.  This clarification updates RFCs 1034, 1035, and 2181.
+
+Table of Contents
+
+   1. Introduction ....................................................2
+   2. Case Insensitivity of DNS Labels ................................2
+      2.1. Escaping Unusual DNS Label Octets ..........................2
+      2.2. Example Labels with Escapes ................................3
+   3. Name Lookup, Label Types, and CLASS .............................3
+      3.1. Original DNS Label Types ...................................4
+      3.2. Extended Label Type Case Insensitivity Considerations ......4
+      3.3. CLASS Case Insensitivity Considerations ....................4
+   4. Case on Input and Output ........................................5
+      4.1. DNS Output Case Preservation ...............................5
+      4.2. DNS Input Case Preservation ................................5
+   5. Internationalized Domain Names ..................................6
+   6. Security Considerations .........................................6
+   7. Acknowledgements ................................................7
+   Normative References................................................7
+   Informative References..............................................8
+
+
+
+
+
+
+
+Eastlake 3rd                Standards Track                     [Page 1]
+
+RFC 4343          DNS Case Insensitivity Clarification      January 2006
+
+
+1.  Introduction
+
+   The Domain Name System (DNS) is the global hierarchical replicated
+   distributed database system for Internet addressing, mail proxy, and
+   other information.  Each node in the DNS tree has a name consisting
+   of zero or more labels [STD13, RFC1591, RFC2606] that are treated in
+   a case insensitive fashion.  This document clarifies the meaning of
+   "case insensitive" for the DNS.  This clarification updates RFCs
+   1034, 1035 [STD13], and [RFC2181].
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+2.  Case Insensitivity of DNS Labels
+
+   DNS was specified in the era of [ASCII].  DNS names were expected to
+   look like most host names or Internet email address right halves (the
+   part after the at-sign, "@") or to be numeric, as in the in-addr.arpa
+   part of the DNS name space.  For example,
+
+       foo.example.net.
+       aol.com.
+       www.gnu.ai.mit.edu.
+   or  69.2.0.192.in-addr.arpa.
+
+   Case-varied alternatives to the above [RFC3092] would be DNS names
+   like
+
+       Foo.ExamplE.net.
+       AOL.COM.
+       WWW.gnu.AI.mit.EDU.
+   or  69.2.0.192.in-ADDR.ARPA.
+
+   However, the individual octets of which DNS names consist are not
+   limited to valid ASCII character codes.  They are 8-bit bytes, and
+   all values are allowed.  Many applications, however, interpret them
+   as ASCII characters.
+
+2.1.  Escaping Unusual DNS Label Octets
+
+   In Master Files [STD13] and other human-readable and -writable ASCII
+   contexts, an escape is needed for the byte value for period (0x2E,
+   ".") and all octet values outside of the inclusive range from 0x21
+   ("!") to 0x7E ("~").  That is to say, 0x2E and all octet values in
+   the two inclusive ranges from 0x00 to 0x20 and from 0x7F to 0xFF.
+
+
+
+
+
+Eastlake 3rd                Standards Track                     [Page 2]
+
+RFC 4343          DNS Case Insensitivity Clarification      January 2006
+
+
+   One typographic convention for octets that do not correspond to an
+   ASCII printing graphic is to use a back-slash followed by the value
+   of the octet as an unsigned integer represented by exactly three
+   decimal digits.
+
+   The same convention can be used for printing ASCII characters so that
+   they will be treated as a normal label character.  This includes the
+   back-slash character used in this convention itself, which can be
+   expressed as \092 or \\, and the special label separator period
+   ("."), which can be expressed as and \046 or \.  It is advisable to
+   avoid using a backslash to quote an immediately following non-
+   printing ASCII character code to avoid implementation difficulties.
+
+   A back-slash followed by only one or two decimal digits is undefined.
+   A back-slash followed by four decimal digits produces two octets, the
+   first octet having the value of the first three digits considered as
+   a decimal number, and the second octet being the character code for
+   the fourth decimal digit.
+
+2.2.  Example Labels with Escapes
+
+   The first example below shows embedded spaces and a period (".")
+   within a label.  The second one shows a 5-octet label where the
+   second octet has all bits zero, the third is a backslash, and the
+   fourth octet has all bits one.
+
+         Donald\032E\.\032Eastlake\0323rd.example.
+   and   a\000\\\255z.example.
+
+3.  Name Lookup, Label Types, and CLASS
+
+   According to the original DNS design decision, comparisons on name
+   lookup for DNS queries should be case insensitive [STD13].  That is
+   to say, a lookup string octet with a value in the inclusive range
+   from 0x41 to 0x5A, the uppercase ASCII letters, MUST match the
+   identical value and also match the corresponding value in the
+   inclusive range from 0x61 to 0x7A, the lowercase ASCII letters.  A
+   lookup string octet with a lowercase ASCII letter value MUST
+   similarly match the identical value and also match the corresponding
+   value in the uppercase ASCII letter range.
+
+   (Historical note: The terms "uppercase" and "lowercase" were invented
+   after movable type.  The terms originally referred to the two font
+   trays for storing, in partitioned areas, the different physical type
+   elements.  Before movable type, the nearest equivalent terms were
+   "majuscule" and "minuscule".)
+
+
+
+
+
+Eastlake 3rd                Standards Track                     [Page 3]
+
+RFC 4343          DNS Case Insensitivity Clarification      January 2006
+
+
+   One way to implement this rule would be to subtract 0x20 from all
+   octets in the inclusive range from 0x61 to 0x7A before comparing
+   octets.  Such an operation is commonly known as "case folding", but
+   implementation via case folding is not required.  Note that the DNS
+   case insensitivity does NOT correspond to the case folding specified
+   in [ISO-8859-1] or [ISO-8859-2].  For example, the octets 0xDD (\221)
+   and 0xFD (\253) do NOT match, although in other contexts, where they
+   are interpreted as the upper- and lower-case version of "Y" with an
+   acute accent, they might.
+
+3.1.  Original DNS Label Types
+
+   DNS labels in wire-encoded names have a type associated with them.
+   The original DNS standard [STD13] had only two types: ASCII labels,
+   with a length from zero to 63 octets, and indirect (or compression)
+   labels, which consist of an offset pointer to a name location
+   elsewhere in the wire encoding on a DNS message.  (The ASCII label of
+   length zero is reserved for use as the name of the root node of the
+   name tree.)  ASCII labels follow the ASCII case conventions described
+   herein and, as stated above, can actually contain arbitrary byte
+   values.  Indirect labels are, in effect, replaced by the name to
+   which they point, which is then treated with the case insensitivity
+   rules in this document.
+
+3.2.  Extended Label Type Case Insensitivity Considerations
+
+   DNS was extended by [RFC2671] so that additional label type numbers
+   would be available.  (The only such type defined so far is the BINARY
+   type [RFC2673], which is now Experimental [RFC3363].)
+
+   The ASCII case insensitivity conventions only apply to ASCII labels;
+   that is to say, label type 0x0, whether appearing directly or invoked
+   by indirect labels.
+
+3.3.  CLASS Case Insensitivity Considerations
+
+   As described in [STD13] and [RFC2929], DNS has an additional axis for
+   data location called CLASS.  The only CLASS in global use at this
+   time is the "IN" (Internet) CLASS.
+
+   The handling of DNS label case is not CLASS dependent.  With the
+   original design of DNS, it was intended that a recursive DNS resolver
+   be able to handle new CLASSes that were unknown at the time of its
+   implementation.  This requires uniform handling of label case
+   insensitivity.  Should it become desirable, for example, to allocate
+   a CLASS with "case sensitive ASCII labels", it would be necessary to
+   allocate a new label type for these labels.
+
+
+
+
+Eastlake 3rd                Standards Track                     [Page 4]
+
+RFC 4343          DNS Case Insensitivity Clarification      January 2006
+
+
+4.  Case on Input and Output
+
+   While ASCII label comparisons are case insensitive, [STD13] says case
+   MUST be preserved on output and preserved when convenient on input.
+   However, this means less than it would appear, since the preservation
+   of case on output is NOT required when output is optimized by the use
+   of indirect labels, as explained below.
+
+4.1.  DNS Output Case Preservation
+
+   [STD13] views the DNS namespace as a node tree.  ASCII output is as
+   if a name were marshaled by taking the label on the node whose name
+   is to be output, converting it to a typographically encoded ASCII
+   string, walking up the tree outputting each label encountered, and
+   preceding all labels but the first with a period (".").  Wire output
+   follows the same sequence, but each label is wire encoded, and no
+   periods are inserted.  No "case conversion" or "case folding" is done
+   during such output operations, thus "preserving" case.  However, to
+   optimize output, indirect labels may be used to point to names
+   elsewhere in the DNS answer.  In determining whether the name to be
+   pointed to (for example, the QNAME) is the "same" as the remainder of
+   the name being optimized, the case insensitive comparison specified
+   above is done.  Thus, such optimization may easily destroy the output
+   preservation of case.  This type of optimization is commonly called
+   "name compression".
+
+4.2.  DNS Input Case Preservation
+
+   Originally, DNS data came from an ASCII Master File as defined in
+   [STD13] or a zone transfer.  DNS Dynamic update and incremental zone
+   transfers [RFC1995] have been added as a source of DNS data [RFC2136,
+   RFC3007].  When a node in the DNS name tree is created by any of such
+   inputs, no case conversion is done.  Thus, the case of ASCII labels
+   is preserved if they are for nodes being created.  However, when a
+   name label is input for a node that already exists in DNS data being
+   held, the situation is more complex.  Implementations are free to
+   retain the case first loaded for such a label, to allow new input to
+   override the old case, or even to maintain separate copies preserving
+   the input case.
+
+   For example, if data with owner name "foo.bar.example" [RFC3092] is
+   loaded and then later data with owner name "xyz.BAR.example" is
+   input, the name of the label on the "bar.example" node (i.e., "bar")
+   might or might not be changed to "BAR" in the DNS stored data.  Thus,
+   later retrieval of data stored under "xyz.bar.example" in this case
+   can use "xyz.BAR.example" in all returned data, use "xyz.bar.example"
+   in all returned data, or even, when more than one RR is being
+   returned, use a mixture of these two capitalizations.  This last case
+
+
+
+Eastlake 3rd                Standards Track                     [Page 5]
+
+RFC 4343          DNS Case Insensitivity Clarification      January 2006
+
+
+   is unlikely, as optimization of answer length through indirect labels
+   tends to cause only one copy of the name tail ("bar.example" or
+   "BAR.example") to be used for all returned RRs.  Note that none of
+   this has any effect on the number or completeness of the RR set
+   returned, only on the case of the names in the RR set returned.
+
+   The same considerations apply when inputting multiple data records
+   with owner names differing only in case.  For example, if an "A"
+   record is the first resource record stored under owner name
+   "xyz.BAR.example" and then a second "A" record is stored under
+   "XYZ.BAR.example", the second MAY be stored with the first (lower
+   case initial label) name, the second MAY override the first so that
+   only an uppercase initial label is retained, or both capitalizations
+   MAY be kept in the DNS stored data.  In any case, a retrieval with
+   either capitalization will retrieve all RRs with either
+   capitalization.
+
+   Note that the order of insertion into a server database of the DNS
+   name tree nodes that appear in a Master File is not defined so that
+   the results of inconsistent capitalization in a Master File are
+   unpredictable output capitalization.
+
+5.  Internationalized Domain Names
+
+   A scheme has been adopted for "internationalized domain names" and
+   "internationalized labels" as described in [RFC3490, RFC3454,
+   RFC3491, and RFC3492].  It makes most of [UNICODE] available through
+   a separate application level transformation from internationalized
+   domain name to DNS domain name and from DNS domain name to
+   internationalized domain name.  Any case insensitivity that
+   internationalized domain names and labels have varies depending on
+   the script and is handled entirely as part of the transformation
+   described in [RFC3454] and [RFC3491], which should be seen for
+   further details.  This is not a part of the DNS as standardized in
+   STD 13.
+
+6.  Security Considerations
+
+   The equivalence of certain DNS label types with case differences, as
+   clarified in this document, can lead to security problems.  For
+   example, a user could be confused by believing that two domain names
+   differing only in case were actually different names.
+
+   Furthermore, a domain name may be used in contexts other than the
+   DNS.  It could be used as a case sensitive index into some database
+   or file system.  Or it could be interpreted as binary data by some
+   integrity or authentication code system.  These problems can usually
+   be handled by using a standardized or "canonical" form of the DNS
+
+
+
+Eastlake 3rd                Standards Track                     [Page 6]
+
+RFC 4343          DNS Case Insensitivity Clarification      January 2006
+
+
+   ASCII type labels; that is, always mapping the ASCII letter value
+   octets in ASCII labels to some specific pre-chosen case, either
+   uppercase or lower case.  An example of a canonical form for domain
+   names (and also a canonical ordering for them) appears in Section 6
+   of [RFC4034].  See also [RFC3597].
+
+   Finally, a non-DNS name may be stored into DNS with the false
+   expectation that case will always be preserved.  For example,
+   although this would be quite rare, on a system with case sensitive
+   email address local parts, an attempt to store two Responsible Person
+   (RP) [RFC1183] records that differed only in case would probably
+   produce unexpected results that might have security implications.
+   That is because the entire email address, including the possibly case
+   sensitive local or left-hand part, is encoded into a DNS name in a
+   readable fashion where the case of some letters might be changed on
+   output as described above.
+
+7.  Acknowledgements
+
+   The contributions to this document by Rob Austein, Olafur
+   Gudmundsson, Daniel J. Anderson, Alan Barrett, Marc Blanchet, Dana,
+   Andreas Gustafsson, Andrew Main, Thomas Narten, and Scott Seligman
+   are gratefully acknowledged.
+
+Normative References
+
+   [ASCII]      ANSI, "USA Standard Code for Information Interchange",
+                X3.4, American National Standards Institute: New York,
+                1968.
+
+   [RFC1995]    Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
+                August 1996.
+
+   [RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate
+                Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2136]    Vixie, P., Thomson,  S., Rekhter, Y., and J. Bound,
+                "Dynamic Updates in the Domain Name System (DNS
+                UPDATE)", RFC 2136, April 1997.
+
+   [RFC2181]     Elz, R. and R. Bush, "Clarifications to the DNS
+                Specification", RFC 2181, July 1997.
+
+   [RFC3007]    Wellington, B., "Secure Domain Name System (DNS) Dynamic
+                Update", RFC 3007, November 2000.
+
+
+
+
+
+
+Eastlake 3rd                Standards Track                     [Page 7]
+
+RFC 4343          DNS Case Insensitivity Clarification      January 2006
+
+
+   [RFC3597]    Gustafsson, A., "Handling of Unknown DNS Resource Record
+                (RR) Types", RFC 3597, September 2003.
+
+   [RFC4034]    Arends, R., Austein, R., Larson, M., Massey, D., and S.
+                Rose, "Resource Records for the DNS Security
+                Extensions", RFC 4034, March 2005.
+
+   [STD13]      Mockapetris, P., "Domain names - concepts and
+                facilities", STD 13, RFC 1034, November 1987.
+
+                Mockapetris, P., "Domain names - implementation and
+                specification", STD 13, RFC 1035, November 1987.
+
+Informative References
+
+   [ISO-8859-1] International Standards Organization, Standard for
+                Character Encodings, Latin-1.
+
+   [ISO-8859-2] International Standards Organization, Standard for
+                Character Encodings, Latin-2.
+
+   [RFC1183]    Everhart, C., Mamakos, L., Ullmann, R., and P.
+                Mockapetris, "New DNS RR Definitions", RFC 1183, October
+                1990.
+
+   [RFC1591]    Postel, J., "Domain Name System Structure and
+                Delegation", RFC 1591, March 1994.
+
+   [RFC2606]    Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS
+                Names", BCP 32, RFC 2606, June 1999.
+
+   [RFC2929]    Eastlake 3rd, D., Brunner-Williams, E., and B. Manning,
+                "Domain Name System (DNS) IANA Considerations", BCP 42,
+                RFC 2929, September 2000.
+
+   [RFC2671]    Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
+                2671, August 1999.
+
+   [RFC2673]    Crawford, M., "Binary Labels in the Domain Name System",
+                RFC 2673, August 1999.
+
+   [RFC3092]    Eastlake 3rd, D., Manros, C., and E. Raymond, "Etymology
+                of "Foo"", RFC 3092, 1 April 2001.
+
+   [RFC3363]    Bush, R., Durand, A., Fink, B., Gudmundsson, O., and T.
+                Hain, "Representing Internet Protocol version 6 (IPv6)
+                Addresses in the Domain Name System (DNS)", RFC 3363,
+                August 2002.
+
+
+
+Eastlake 3rd                Standards Track                     [Page 8]
+
+RFC 4343          DNS Case Insensitivity Clarification      January 2006
+
+
+   [RFC3454]    Hoffman, P. and M. Blanchet, "Preparation of
+                Internationalized Strings ("stringprep")", RFC 3454,
+                December 2002.
+
+   [RFC3490]    Faltstrom, P., Hoffman, P., and A. Costello,
+                "Internationalizing Domain Names in Applications
+                (IDNA)", RFC 3490, March 2003.
+
+   [RFC3491]    Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep
+                Profile for Internationalized Domain Names (IDN)", RFC
+                3491, March 2003.
+
+   [RFC3492]    Costello, A., "Punycode: A Bootstring encoding of
+                Unicode for Internationalized Domain Names in
+                Applications (IDNA)", RFC 3492, March 2003.
+
+   [UNICODE]    The Unicode Consortium, "The Unicode Standard",
+                <http://www.unicode.org/unicode/standard/standard.html>.
+
+Author's Address
+
+   Donald E. Eastlake 3rd
+   Motorola Laboratories
+   155 Beaver Street
+   Milford, MA 01757 USA
+
+   Phone: +1 508-786-7554 (w)
+   EMail: Donald.Eastlake@motorola.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake 3rd                Standards Track                     [Page 9]
+
+RFC 4343          DNS Case Insensitivity Clarification      January 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Eastlake 3rd                Standards Track                    [Page 10]
+
diff --git a/doc/rfc/rfc4367.txt b/doc/rfc/rfc4367.txt
new file mode 100644
index 0000000..f066b64
--- /dev/null
+++ b/doc/rfc/rfc4367.txt
@@ -0,0 +1,955 @@
+
+
+
+
+
+
+Network Working Group                                  J. Rosenberg, Ed.
+Request for Comments: 4367                                           IAB
+Category: Informational                                    February 2006
+
+
+          What's in a Name: False Assumptions about DNS Names
+
+Status of This Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   The Domain Name System (DNS) provides an essential service on the
+   Internet, mapping structured names to a variety of data, usually IP
+   addresses.  These names appear in email addresses, Uniform Resource
+   Identifiers (URIs), and other application-layer identifiers that are
+   often rendered to human users.  Because of this, there has been a
+   strong demand to acquire names that have significance to people,
+   through equivalence to registered trademarks, company names, types of
+   services, and so on.  There is a danger in this trend; the humans and
+   automata that consume and use such names will associate specific
+   semantics with some names and thereby make assumptions about the
+   services that are, or should be, provided by the hosts associated
+   with the names.  Those assumptions can often be false, resulting in a
+   variety of failure conditions.  This document discusses this problem
+   in more detail and makes recommendations on how it can be avoided.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rosenberg                    Informational                      [Page 1]
+
+RFC 4367                    Name Assumptions               February 2006
+
+
+Table of Contents
+
+   1. Introduction ....................................................2
+   2. Target Audience .................................................4
+   3. Modeling Usage of the DNS .......................................4
+   4. Possible Assumptions ............................................5
+      4.1. By the User ................................................5
+      4.2. By the Client ..............................................6
+      4.3. By the Server ..............................................7
+   5. Consequences of False Assumptions ...............................8
+   6. Reasons Why the Assumptions Can Be False ........................9
+      6.1. Evolution ..................................................9
+      6.2. Leakage ...................................................10
+      6.3. Sub-Delegation ............................................10
+      6.4. Mobility ..................................................12
+      6.5. Human Error ...............................................12
+   7. Recommendations ................................................12
+   8. A Note on RFC 2219 and RFC 2782 ................................13
+   9. Security Considerations ........................................14
+   10. Acknowledgements ..............................................14
+   11. IAB Members ...................................................14
+   12. Informative References ........................................15
+
+1.  Introduction
+
+   The Domain Name System (DNS) [1] provides an essential service on the
+   Internet, mapping structured names to a variety of different types of
+   data.  Most often it is used to obtain the IP address of a host
+   associated with that name [2] [1] [3].  However, it can be used to
+   obtain other information, and proposals have been made for nearly
+   everything, including geographic information [4].
+
+   Domain names are most often used in identifiers used by application
+   protocols.  The most well known include email addresses and URIs,
+   such as the HTTP URL [5], Real Time Streaming Protocol (RTSP) URL
+   [6], and SIP URI [7].  These identifiers are ubiquitous, appearing on
+   business cards, web pages, street signs, and so on.  Because of this,
+   there has been a strong demand to acquire domain names that have
+   significance to people through equivalence to registered trademarks,
+   company names, types of services, and so on.  Such identifiers serve
+   many business purposes, including extension of brand, advertising,
+   and so on.
+
+   People often make assumptions about the type of service that is or
+   should be provided by a host associated with that name, based on
+   their expectations and understanding of what the name implies.  This,
+   in turn, triggers attempts by organizations to register domain names
+   based on that presumed user expectation.  Examples of this are the
+
+
+
+Rosenberg                    Informational                      [Page 2]
+
+RFC 4367                    Name Assumptions               February 2006
+
+
+   various proposals for a Top-Level Domain (TLD) that could be
+   associated with adult content [8], the requests for creation of TLDs
+   associated with mobile devices and services, and even phishing
+   attacks.
+
+   When these assumptions are codified into the behavior of an
+   automaton, such as an application client or server, as a result of
+   implementor choice, management directive, or domain owner policy, the
+   overall system can fail in various ways.  This document describes a
+   number of typical ways in which these assumptions can be codified,
+   how they can be wrong, the consequences of those mistakes, and the
+   recommended ways in which they can be avoided.
+
+   Section 4 describes some of the possible assumptions that clients,
+   servers, and people can make about a domain name.  In this context,
+   an "assumption" is defined as any behavior that is expected when
+   accessing a service at a domain name, even though the behavior is not
+   explicitly codified in protocol specifications.  Frequently, these
+   assumptions involve ignoring parts of a specification based on an
+   assumption that the client or server is deployed in an environment
+   that is more rigid than the specification allows.  Section 5
+   overviews some of the consequences of these false assumptions.
+   Generally speaking, these consequences can include a variety of
+   different interoperability failures, user experience failures, and
+   system failures.  Section 6 discusses why these assumptions can be
+   false from the very beginning or become false at some point in the
+   future.  Most commonly, they become false because the environment
+   changes in unexpected ways over time, and what was a valid assumption
+   before, no longer is.  Other times, the assumptions prove wrong
+   because they were based on the belief that a specific community of
+   clients and servers was participating, and an element outside of that
+   community began participating.
+
+   Section 7 then provides some recommendations.  These recommendations
+   encapsulate some of the engineering mantras that have been at the
+   root of Internet protocol design for decades.  These include:
+
+      Follow the specifications.
+
+      Use the capability negotiation techniques provided in the
+      protocols.
+
+      Be liberal in what you accept, and conservative in what you send.
+      [18]
+
+   Overall, automata should not change their behavior within a protocol
+   based on the domain name, or some component of the domain name, of
+   the host they are communicating with.
+
+
+
+Rosenberg                    Informational                      [Page 3]
+
+RFC 4367                    Name Assumptions               February 2006
+
+
+2.  Target Audience
+
+   This document has several audiences.  Firstly, it is aimed at
+   implementors who ultimately develop the software that make the false
+   assumptions that are the subject of this document.  The
+   recommendations described here are meant to reinforce the engineering
+   guidelines that are often understood by implementors, but frequently
+   forgotten as deadlines near and pressures mount.
+
+   The document is also aimed at technology managers, who often develop
+   the requirements that lead to these false assumptions.  For them,
+   this document serves as a vehicle for emphasizing the importance of
+   not taking shortcuts in the scope of applicability of a project.
+
+   Finally, this document is aimed at domain name policy makers and
+   administrators.  For them, it points out the perils in establishing
+   domain policies that get codified into the operation of applications
+   running within that domain.
+
+3.  Modeling Usage of the DNS
+
+
+                       +--------+
+                       |        |
+                       |        |
+                       |  DNS   |
+                       |Service |
+                       |        |
+                       +--------+
+                         ^   |
+                         |   |
+                         |   |
+                         |   |
+          /--\           |   |
+         |    |          |   V
+         |    |        +--------+                     +--------+
+          \--/         |        |                     |        |
+            |          |        |                     |        |
+         ---+---       | Client |-------------------->| Server |
+            |          |        |                     |        |
+            |          |        |                     |        |
+           /\          +--------+                     +--------+
+          /  \
+         /    \
+
+         User
+                                 Figure 1
+
+
+
+
+Rosenberg                    Informational                      [Page 4]
+
+RFC 4367                    Name Assumptions               February 2006
+
+
+   Figure 1 shows a simple conceptual model of how the DNS is used by
+   applications.  A user of the application obtains an identifier for
+   particular content or service it wishes to obtain.  This identifier
+   is often a URL or URI that contains a domain name.  The user enters
+   this identifier into its client application (for example, by typing
+   in the URL in a web browser window).  The client is the automaton (a
+   software and/or hardware system) that contacts a server for that
+   application in order to provide service to the user.  To do that, it
+   contacts a DNS server to resolve the domain name in the identifier to
+   an IP address.  It then contacts the server at that IP address.  This
+   simple model applies to application protocols such as HTTP [5], SIP
+   [7], RTSP [6], and SMTP [9].
+
+   >From this model, it is clear that three entities in the system can
+   potentially make false assumptions about the service provided by the
+   server.  The human user may form expectations relating to the content
+   of the service based on a parsing of the host name from which the
+   content originated.  The server might assume that the client
+   connecting to it supports protocols that it does not, can process
+   content that it cannot, or has capabilities that it does not.
+   Similarly, the client might assume that the server supports
+   protocols, content, or capabilities that it does not.  Furthermore,
+   applications can potentially contain a multiplicity of humans,
+   clients, and servers, all of which can independently make these false
+   assumptions.
+
+4.  Possible Assumptions
+
+   For each of the three elements, there are many types of false
+   assumptions that can be made.
+
+4.1.  By the User
+
+   The set of possible assumptions here is nearly boundless.  Users
+   might assume that an HTTP URL that looks like a company name maps to
+   a server run by that company.  They might assume that an email from a
+   email address in the .gov TLD is actually from a government employee.
+   They might assume that the content obtained from a web server within
+   a TLD labeled as containing adult materials (for example, .sex)
+   actually contains adult content [8].  These assumptions are
+   unavoidable, may all be false, and are not the focus of this
+   document.
+
+
+
+
+
+
+
+
+
+Rosenberg                    Informational                      [Page 5]
+
+RFC 4367                    Name Assumptions               February 2006
+
+
+4.2.  By the Client
+
+   Even though the client is an automaton, it can make some of the same
+   assumptions that a human user might make.  For example, many clients
+   assume that any host with a hostname that begins with "www" is a web
+   server, even though this assumption may be false.
+
+   In addition, the client concerns itself with the protocols needed to
+   communicate with the server.  As a result, it might make assumptions
+   about the operation of the protocols for communicating with the
+   server.  These assumptions manifest themselves in an implementation
+   when a standardized protocol negotiation technique defined by the
+   protocol is ignored, and instead, some kind of rule is coded into the
+   software that comes to its own conclusion about what the negotiation
+   would have determined.  The result is often a loss of
+   interoperability, degradation in reliability, and worsening of user
+   experience.
+
+   Authentication Algorithm: Though a protocol might support a
+      multiplicity of authentication techniques, a client might assume
+      that a server always supports one that is only optional according
+      to the protocol.  For example, a SIP client contacting a SIP
+      server in a domain that is apparently used to identify mobile
+      devices (for example, www.example.cellular) might assume that the
+      server supports the optional Authentication and Key Agreement
+      (AKA) digest technique [10], just because of the domain name that
+      was used to access the server.  As another example, a web client
+      might assume that a server with the name https.example.com
+      supports HTTP over Transport Layer Security (TLS) [16].
+
+   Data Formats: Though a protocol might allow a multiplicity of data
+      formats to be sent from the server to the client, the client might
+      assume a specific one, rather than using the content labeling and
+      negotiation capabilities of the underlying protocol.  For example,
+      an RTSP client might assume that all audio content delivered to it
+      from media.example.cellular uses a low-bandwidth codec.  As
+      another example, a mail client might assume that the contents of
+      messages it retrieves from a mail server at mail.example.cellular
+      are always text, instead of checking the MIME headers [11] in the
+      message in order to determine the actual content type.
+
+   Protocol Extensions: A client may attempt an operation on the server
+      that requires the server to support an optional protocol
+      extension.  However, rather than implementing the necessary
+      fallback logic, the client may falsely assume that the extension
+      is supported.  As an example, a SIP client that requires reliable
+      provisional responses to its request (RFC 3262 [17]) might assume
+      that this extension is supported on servers in the domain
+
+
+
+Rosenberg                    Informational                      [Page 6]
+
+RFC 4367                    Name Assumptions               February 2006
+
+
+      sip.example.telecom.  Furthermore, the client would not implement
+      the fallback behavior defined in RFC 3262, since it would assume
+      that all servers it will communicate with are in this domain and
+      that all therefore support this extension.  However, if the
+      assumptions prove wrong, the client is unable to make any phone
+      calls.
+
+   Languages: A client may support facilities for processing text
+      content differently depending on the language of the text.  Rather
+      than determining the language from markers in the message from the
+      server, the client might assume a language based on the domain
+      name.  This assumption can easily be wrong.  For example, a client
+      might assume that any text in a web page retrieved from a server
+      within the .de country code TLD (ccTLD) is in German, and attempt
+      a translation to Finnish.  This would fail dramatically if the
+      text was actually in French.  Unfortunately, this client behavior
+      is sometimes exhibited because the server has not properly labeled
+      the language of the content in the first place, often because the
+      server assumed such a labeling was not needed.  This is an example
+      of how these false assumptions can create vicious cycles.
+
+4.3.  By the Server
+
+   The server, like the client, is an automaton.  Let us consider one
+   servicing a particular domain -- www.company.cellular, for example.
+   It might assume that all clients connecting to this domain support
+   particular capabilities, rather than using the underlying protocol to
+   make this determination.  Some examples include:
+
+   Authentication Algorithm: The server can assume that a client
+      supports a particular, optional, authentication technique, and it
+      therefore does not support the mandatory one.
+
+   Language: The server can serve content in a particular language,
+      based on an assumption that clients accessing the domain speak a
+      particular language, or based on an assumption that clients coming
+      from a particular IP address speak a certain language.
+
+   Data Formats: The server can assume that the client supports a
+      particular set of MIME types and is only capable of sending ones
+      within that set.  When it generates content in a protocol
+      response, it ignores any content negotiation headers that were
+      present in the request.  For example, a web server might ignore
+      the Accept HTTP header field and send a specific image format.
+
+
+
+
+
+
+
+Rosenberg                    Informational                      [Page 7]
+
+RFC 4367                    Name Assumptions               February 2006
+
+
+   Protocol Extensions: The server might assume that the client supports
+      a particular optional protocol extension, and so it does not
+      support the fallback behavior necessary in the case where the
+      client does not.
+
+   Client Characteristics: The server might assume certain things about
+      the physical characteristics of its clients, such as memory
+      footprint, processing power, screen sizes, screen colors, pointing
+      devices, and so on.  Based on these assumptions, it might choose
+      specific behaviors when processing a request.  For example, a web
+      server might always assume that clients connect through cell
+      phones, and therefore return content that lacks images and is
+      tuned for such devices.
+
+5.  Consequences of False Assumptions
+
+   There are numerous negative outcomes that can arise from the various
+   false assumptions that users, servers, and clients can make.  These
+   include:
+
+   Interoperability Failure: In these cases, the client or server
+      assumed some kind of protocol operation, and this assumption was
+      wrong.  The result is that the two are unable to communicate, and
+      the user receives some kind of an error.  This represents a total
+      interoperability failure, manifesting itself as a lack of service
+      to users of the system.  Unfortunately, this kind of failure
+      persists.  Repeated attempts over time by the client to access the
+      service will fail.  Only a change in the server or client software
+      can fix this problem.
+
+   System Failure: In these cases, the client or server misinterpreted a
+      protocol operation, and this misinterpretation was serious enough
+      to uncover a bug in the implementation.  The bug causes a system
+      crash or some kind of outage, either transient or permanent (until
+      user reset).  If this failure occurs in a server, not only will
+      the connecting client lose service, but other clients attempting
+      to connect will not get service.  As an example, if a web server
+      assumes that content passed to it from a client (created, for
+      example, by a digital camera) is of a particular content type, and
+      it always passes image content to a codec for decompression prior
+      to storage, the codec might crash when it unexpectedly receives an
+      image compressed in a different format.  Of course, it might crash
+      even if the Content-Type was correct, but the compressed bitstream
+      was invalid.  False assumptions merely introduce additional
+      failure cases.
+
+
+
+
+
+
+Rosenberg                    Informational                      [Page 8]
+
+RFC 4367                    Name Assumptions               February 2006
+
+
+   Poor User Experience: In these cases, the client and server
+      communicate, but the user receives a diminished user experience.
+      For example, if a client on a PC connects to a web site that
+      provides content for mobile devices, the content may be
+      underwhelming when viewed on the PC.  Or, a client accessing a
+      streaming media service may receive content of very low bitrate,
+      even though the client supported better codecs.  Indeed, if a user
+      wishes to access content from both a cellular device and a PC
+      using a shared address book (that is, an address book shared
+      across multiple devices), the user would need two entries in that
+      address book, and would need to use the right one from the right
+      device.  This is a poor user experience.
+
+   Degraded Security: In these cases, a weaker security mechanism is
+      used than the one that ought to have been used.  As an example, a
+      server in a domain might assume that it is only contacted by
+      clients with a limited set of authentication algorithms, even
+      though the clients have been recently upgraded to support a
+      stronger set.
+
+6.  Reasons Why the Assumptions Can Be False
+
+   Assumptions made by clients and servers about the operation of
+   protocols when contacting a particular domain are brittle, and can be
+   wrong for many reasons.  On the server side, many of the assumptions
+   are based on the notion that a domain name will only be given to, or
+   used by, a restricted set of clients.  If the holder of the domain
+   name assumes something about those clients, and can assume that only
+   those clients use the domain name, then it can configure or program
+   the server to operate specifically for those clients.  Both parts of
+   this assumption can be wrong, as discussed in more detail below.
+
+   On the client side, the notion is similar, being based on the
+   assumption that a server within a particular domain will provide a
+   specific type of service.  Sub-delegation and evolution, both
+   discussed below, can make these assumptions wrong.
+
+6.1.  Evolution
+
+   The Internet and the devices that access it are constantly evolving,
+   often at a rapid pace.  Unfortunately, there is a tendency to build
+   for the here and now, and then worry about the future at a later
+   time.  Many of the assumptions above are predicated on
+   characteristics of today's clients and servers.  Support for specific
+   protocols, authentication techniques, or content are based on today's
+   standards and today's devices.  Even though they may, for the most
+   part, be true, they won't always be.  An excellent example is mobile
+   devices.  A server servicing a domain accessed by mobile devices
+
+
+
+Rosenberg                    Informational                      [Page 9]
+
+RFC 4367                    Name Assumptions               February 2006
+
+
+   might try to make assumptions about the protocols, protocol
+   extensions, security mechanisms, screen sizes, or processor power of
+   such devices.  However, all of these characteristics can and will
+   change over time.
+
+   When they do change, the change is usually evolutionary.  The result
+   is that the assumptions remain valid in some cases, but not in
+   others.  It is difficult to fix such systems, since it requires the
+   server to detect what type of client is connecting, and what its
+   capabilities are.  Unless the system is built and deployed with these
+   capability negotiation techniques built in to begin with, such
+   detection can be extremely difficult.  In fact, fixing it will often
+   require the addition of such capability negotiation features that, if
+   they had been in place and used to begin with, would have avoided the
+   problem altogether.
+
+6.2.  Leakage
+
+   Servers also make assumptions because of the belief that they will
+   only be accessed by specific clients, and in particular, those that
+   are configured or provisioned to use the domain name.  In essence,
+   there is an assumption of community -- that a specific community
+   knows and uses the domain name, while others outside of the community
+   do not.
+
+   The problem is that this notion of community is a false one.  The
+   Internet is global.  The DNS is global.  There is no technical
+   barrier that separates those inside of the community from those
+   outside.  The ease with which information propagates across the
+   Internet makes it extremely likely that such domain names will
+   eventually find their way into clients outside of the presumed
+   community.  The ubiquitous presence of domain names in various URI
+   formats, coupled with the ease of conveyance of URIs, makes such
+   leakage merely a matter of time.  Furthermore, since the DNS is
+   global, and since it can only have one root [12], it becomes possible
+   for clients outside of the community to search and find and use such
+   "special" domain names.
+
+   Indeed, this leakage is a strength of the Internet architecture, not
+   a weakness.  It enables global access to services from any client
+   with a connection to the Internet.  That, in turn, allows for rapid
+   growth in the number of customers for any particular service.
+
+6.3.  Sub-Delegation
+
+   Clients and users make assumptions about domains because of the
+   notion that there is some kind of centralized control that can
+   enforce those assumptions.  However, the DNS is not centralized; it
+
+
+
+Rosenberg                    Informational                     [Page 10]
+
+RFC 4367                    Name Assumptions               February 2006
+
+
+   is distributed.  If a domain doesn't delegate its sub-domains and has
+   its records within a single zone, it is possible to maintain a
+   centralized policy about operation of its domain.  However, once a
+   domain gets sufficiently large that the domain administrators begin
+   to delegate sub-domains to other authorities, it becomes increasingly
+   difficult to maintain any kind of central control on the nature of
+   the service provided in each sub-domain.
+
+   Similarly, the usage of domain names with human semantic connotation
+   tends to lead to a registration of multiple domains in which a
+   particular service is to run.  As an example, a service provider with
+   the name "example" might register and set up its services in
+   "example.com", "example.net", and generally example.foo for each foo
+   that is a valid TLD.  This, like sub-delegation, results in a growth
+   in the number of domains over which it is difficult to maintain
+   centralized control.
+
+   Not that it is not possible, since there are many examples of
+   successful administration of policies across sub-domains many levels
+   deep.  However, it takes an increasing amount of effort to ensure
+   this result, as it requires human intervention and the creation of
+   process and procedure.  Automated validation of adherence to policies
+   is very difficult to do, as there is no way to automatically verify
+   many policies that might be put into place.
+
+   A less costly process for providing centralized management of
+   policies is to just hope that any centralized policies are being
+   followed, and then wait for complaints or perform random audits.
+   Those approaches have many problems.
+
+   The invalidation of assumptions due to sub-delegation is discussed in
+   further detail in Section 4.1.3 of [8] and in Section 3.3 of [20].
+
+   As a result of the fragility of policy continuity across sub-
+   delegations, if a client or user assumes some kind of property
+   associated with a TLD (such as ".wifi"), it becomes increasingly more
+   likely with the number of sub-domains that this property will not
+   exist in a server identified by a particular name.  For example, in
+   "store.chain.company.provider.wifi", there may be four levels of
+   delegation from ".wifi", making it quite likely that, unless the
+   holder of ".wifi" is working diligently, the properties that the
+   holder of ".wifi" wishes to enforce are not present.  These
+   properties may not be present due to human error or due to a willful
+   decision not to adhere to them.
+
+
+
+
+
+
+
+Rosenberg                    Informational                     [Page 11]
+
+RFC 4367                    Name Assumptions               February 2006
+
+
+6.4.  Mobility
+
+   One of the primary value propositions of a hostname as an identifier
+   is its persistence.  A client can change IP addresses, yet still
+   retain a persistent identifier used by other hosts to reach it.
+   Because their value derives from their persistence, hostnames tend to
+   move with a host not just as it changes IP addresses, but as it
+   changes access network providers and technologies.  For this reason,
+   assumptions made about a host based on the presumed access network
+   corresponding to that hostname tend to be wrong over time.  As an
+   example, a PC might normally be connected to its broadband provider,
+   and through dynamic DNS have a hostname within the domain of that
+   provider.  However, one cannot assume that any host within that
+   network has access over a broadband link; the user could connect
+   their PC over a low-bandwidth wireless access network and still
+   retain its domain name.
+
+6.5.  Human Error
+
+   Of course, human error can be the source of errors in any system, and
+   the same is true here.  There are many examples relevant to the
+   problem under discussion.
+
+   A client implementation may make the assumption that, just because a
+   DNS SRV record exists for a particular protocol in a particular
+   domain, indicating that the service is available on some port, that
+   the service is, in fact, running there.  This assumption could be
+   wrong because the SRV records haven't been updated by the system
+   administrators to reflect the services currently running.  As another
+   example, a client might assume that a particular domain policy
+   applies to all sub-domains.  However, a system administrator might
+   have omitted to apply the policy to servers running in one of those
+   sub-domains.
+
+7.  Recommendations
+
+   Based on these problems, the clear conclusion is that clients,
+   servers, and users should not make assumptions on the nature of the
+   service provided to, or by, a domain.  More specifically, however,
+   the following can be said:
+
+   Follow the specifications: When specifications define mandatory
+      baseline procedures and formats, those should be implemented and
+      supported, even if the expectation is that optional procedures
+      will most often be used.  For example, if a specification mandates
+      a particular baseline authentication technique, but allows others
+      to be negotiated and used, implementations need to implement the
+      baseline authentication algorithm even if the other ones are used
+
+
+
+Rosenberg                    Informational                     [Page 12]
+
+RFC 4367                    Name Assumptions               February 2006
+
+
+      most of the time.  Put more simply, the behavior of the protocol
+      machinery should never change based on the domain name of the
+      host.
+
+   Use capability negotiation: Many protocols are engineered with
+      capability negotiation mechanisms.  For example, a content
+      negotiation framework has been defined for protocols using MIME
+      content [13] [14] [15].  SIP allows for clients to negotiate the
+      media types used in the multimedia session, as well as protocol
+      parameters.  HTTP allows for clients to negotiate the media types
+      returned in requests for content.  When such features are
+      available in a protocol, client and servers should make use of
+      them rather than making assumptions about supported capabilities.
+      A corollary is that protocol designers should include such
+      mechanisms when evolution is expected in the usage of the
+      protocol.
+
+   "Be liberal in what you accept, and conservative in what you send"
+      [18]:  This axiom of Internet protocol design is applicable here
+      as well.  Implementations should be prepared for the full breadth
+      of what a protocol allows another entity to send, rather than be
+      limiting in what it is willing to receive.
+
+   To summarize -- there is never a need to make assumptions.  Rather
+   than doing so, utilize the specifications and the negotiation
+   capabilities they provide, and the overall system will be robust and
+   interoperable.
+
+8.  A Note on RFC 2219 and RFC 2782
+
+   Based on the definition of an assumption given here, the behavior
+   hinted at by records in the DNS also represents an assumption.  RFC
+   2219 [19] defines well-known aliases that can be used to construct
+   domain names for reaching various well-known services in a domain.
+   This approach was later followed by the definition of a new resource
+   record, the SRV record [2], which specifies that a particular service
+   is running on a server in a domain.  Although both of these
+   mechanisms are useful as a hint that a particular service is running
+   in a domain, both of them represent assumptions that may be false.
+   However, they differ in the set of reasons why those assumptions
+   might be false.
+
+   A client that assumes that "ftp.example.com" is an FTP server may be
+   wrong because the presumed naming convention in RFC 2219 was not
+   known by, or not followed by, the owner of domain.com.  With RFC
+   2782, an SRV record for a particular service would be present only by
+   explicit choice of the domain administrator, and thus a client that
+
+
+
+
+Rosenberg                    Informational                     [Page 13]
+
+RFC 4367                    Name Assumptions               February 2006
+
+
+   assumes that the corresponding host provides this service would be
+   wrong only because of human error in configuration.  In this case,
+   the assumption is less likely to be wrong, but it certainly can be.
+
+   The only way to determine with certainty that a service is running on
+   a host is to initiate a connection to the port for that service, and
+   check.  Implementations need to be careful not to codify any
+   behaviors that cause failures should the information provided in the
+   record actually be false.  This borders on common sense for robust
+   implementations, but it is valuable to raise this point explicitly.
+
+9.  Security Considerations
+
+   One of the assumptions that can be made by clients or servers is the
+   availability and usage (or lack thereof) of certain security
+   protocols and algorithms.  For example, a client accessing a service
+   in a particular domain might assume a specific authentication
+   algorithm or hash function in the application protocol.  It is
+   possible that, over time, weaknesses are found in such a technique,
+   requiring usage of a different mechanism.  Similarly, a system might
+   start with an insecure mechanism, and then decide later on to use a
+   secure one.  In either case, assumptions made on security properties
+   can result in interoperability failures, or worse yet, providing
+   service in an insecure way, even though the client asked for, and
+   thought it would get, secure service.  These kinds of assumptions are
+   fundamentally unsound even if the records themselves are secured with
+   DNSSEC.
+
+10.  Acknowledgements
+
+   The IAB would like to thank John Klensin, Keith Moore and Peter Koch
+   for their comments.
+
+11.  IAB Members
+
+   Internet Architecture Board members at the time of writing of this
+   document are:
+
+      Bernard Aboba
+
+      Loa Andersson
+
+      Brian Carpenter
+
+      Leslie Daigle
+
+      Patrik Faltstrom
+
+
+
+
+Rosenberg                    Informational                     [Page 14]
+
+RFC 4367                    Name Assumptions               February 2006
+
+
+      Bob Hinden
+
+      Kurtis Lindqvist
+
+      David Meyer
+
+      Pekka Nikander
+
+      Eric Rescorla
+
+      Pete Resnick
+
+      Jonathan Rosenberg
+
+12.  Informative References
+
+   [1]   Mockapetris, P., "Domain names - concepts and facilities",
+         STD 13, RFC 1034, November 1987.
+
+   [2]   Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
+         specifying the location of services (DNS SRV)", RFC 2782,
+         February 2000.
+
+   [3]   Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
+         Three: The Domain Name System (DNS) Database", RFC 3403,
+         October 2002.
+
+   [4]   Davis, C., Vixie, P., Goodwin, T., and I. Dickinson, "A Means
+         for Expressing Location Information in the Domain Name System",
+         RFC 1876, January 1996.
+
+   [5]   Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
+         Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol --
+         HTTP/1.1", RFC 2616, June 1999.
+
+   [6]   Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming
+         Protocol (RTSP)", RFC 2326, April 1998.
+
+   [7]   Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
+         Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
+         Session Initiation Protocol", RFC 3261, June 2002.
+
+   [8]   Eastlake, D., ".sex Considered Dangerous", RFC 3675,
+         February 2004.
+
+   [9]   Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
+         April 2001.
+
+
+
+
+Rosenberg                    Informational                     [Page 15]
+
+RFC 4367                    Name Assumptions               February 2006
+
+
+   [10]  Niemi, A., Arkko, J., and V. Torvinen, "Hypertext Transfer
+         Protocol (HTTP) Digest Authentication Using Authentication and
+         Key Agreement (AKA)", RFC 3310, September 2002.
+
+   [11]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+         Extensions (MIME) Part One: Format of Internet Message Bodies",
+         RFC 2045, November 1996.
+
+   [12]  Internet Architecture Board, "IAB Technical Comment on the
+         Unique DNS Root", RFC 2826, May 2000.
+
+   [13]  Klyne, G., "Indicating Media Features for MIME Content",
+         RFC 2912, September 2000.
+
+   [14]  Klyne, G., "A Syntax for Describing Media Feature Sets",
+         RFC 2533, March 1999.
+
+   [15]  Klyne, G., "Protocol-independent Content Negotiation
+         Framework", RFC 2703, September 1999.
+
+   [16]  Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
+
+   [17]  Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional
+         Responses in Session Initiation Protocol (SIP)", RFC 3262,
+         June 2002.
+
+   [18]  Braden, R., "Requirements for Internet Hosts - Communication
+         Layers", STD 3, RFC 1122, October 1989.
+
+   [19]  Hamilton, M. and R. Wright, "Use of DNS Aliases for Network
+         Services", BCP 17, RFC 2219, October 1997.
+
+   [20]  Faltstrom, P., "Design Choices When Expanding DNS", Work in
+         Progress, June 2005.
+
+Author's Address
+
+   Jonathan Rosenberg, Editor
+   IAB
+   600 Lanidex Plaza
+   Parsippany, NJ  07054
+   US
+
+   Phone: +1 973 952-5000
+   EMail: jdrosen@cisco.com
+   URI:   http://www.jdrosen.net
+
+
+
+
+
+Rosenberg                    Informational                     [Page 16]
+
+RFC 4367                    Name Assumptions               February 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Rosenberg                    Informational                     [Page 17]
+
diff --git a/doc/rfc/rfc4398.txt b/doc/rfc/rfc4398.txt
new file mode 100644
index 0000000..6437436
--- /dev/null
+++ b/doc/rfc/rfc4398.txt
@@ -0,0 +1,955 @@
+
+
+
+
+
+
+Network Working Group                                       S. Josefsson
+Request for Comments: 4398                                    March 2006
+Obsoletes: 2538
+Category: Standards Track
+
+
+          Storing Certificates in the Domain Name System (DNS)
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   Cryptographic public keys are frequently published, and their
+   authenticity is demonstrated by certificates.  A CERT resource record
+   (RR) is defined so that such certificates and related certificate
+   revocation lists can be stored in the Domain Name System (DNS).
+
+   This document obsoletes RFC 2538.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Josefsson                   Standards Track                     [Page 1]
+
+RFC 4398            Storing Certificates in the DNS        February 2006
+
+
+Table of Contents
+
+   1. Introduction ....................................................3
+   2. The CERT Resource Record ........................................3
+      2.1. Certificate Type Values ....................................4
+      2.2. Text Representation of CERT RRs ............................6
+      2.3. X.509 OIDs .................................................6
+   3. Appropriate Owner Names for CERT RRs ............................7
+      3.1. Content-Based X.509 CERT RR Names ..........................8
+      3.2. Purpose-Based X.509 CERT RR Names ..........................9
+      3.3. Content-Based OpenPGP CERT RR Names ........................9
+      3.4. Purpose-Based OpenPGP CERT RR Names .......................10
+      3.5. Owner Names for IPKIX, ISPKI, IPGP, and IACPKIX ...........10
+   4. Performance Considerations .....................................11
+   5. Contributors ...................................................11
+   6. Acknowledgements ...............................................11
+   7. Security Considerations ........................................12
+   8. IANA Considerations ............................................12
+   9. Changes since RFC 2538 .........................................13
+   10. References ....................................................14
+      10.1. Normative References .....................................14
+      10.2. Informative References ...................................15
+   Appendix A.  Copying Conditions ...................................16
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Josefsson                   Standards Track                     [Page 2]
+
+RFC 4398            Storing Certificates in the DNS        February 2006
+
+
+1.  Introduction
+
+   Public keys are frequently published in the form of a certificate,
+   and their authenticity is commonly demonstrated by certificates and
+   related certificate revocation lists (CRLs).  A certificate is a
+   binding, through a cryptographic digital signature, of a public key,
+   a validity interval and/or conditions, and identity, authorization,
+   or other information.  A certificate revocation list is a list of
+   certificates that are revoked, and of incidental information, all
+   signed by the signer (issuer) of the revoked certificates.  Examples
+   are X.509 certificates/CRLs in the X.500 directory system or OpenPGP
+   certificates/revocations used by OpenPGP software.
+
+   Section 2 specifies a CERT resource record (RR) for the storage of
+   certificates in the Domain Name System [1] [2].
+
+   Section 3 discusses appropriate owner names for CERT RRs.
+
+   Sections 4, 7, and 8 cover performance, security, and IANA
+   considerations, respectively.
+
+   Section 9 explains the changes in this document compared to RFC 2538.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [3].
+
+2.  The CERT Resource Record
+
+   The CERT resource record (RR) has the structure given below.  Its RR
+   type code is 37.
+
+                       1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
+   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |             type              |             key tag           |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |   algorithm   |                                               /
+   +---------------+            certificate or CRL                 /
+   /                                                               /
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
+
+   The type field is the certificate type as defined in Section 2.1
+   below.
+
+   The key tag field is the 16-bit value computed for the key embedded
+   in the certificate, using the RRSIG Key Tag algorithm described in
+   Appendix B of [12].  This field is used as an efficiency measure to
+
+
+
+Josefsson                   Standards Track                     [Page 3]
+
+RFC 4398            Storing Certificates in the DNS        February 2006
+
+
+   pick which CERT RRs may be applicable to a particular key.  The key
+   tag can be calculated for the key in question, and then only CERT RRs
+   with the same key tag need to be examined.  Note that two different
+   keys can have the same key tag.  However, the key MUST be transformed
+   to the format it would have as the public key portion of a DNSKEY RR
+   before the key tag is computed.  This is only possible if the key is
+   applicable to an algorithm and complies to limits (such as key size)
+   defined for DNS security.  If it is not, the algorithm field MUST be
+   zero and the tag field is meaningless and SHOULD be zero.
+
+   The algorithm field has the same meaning as the algorithm field in
+   DNSKEY and RRSIG RRs [12], except that a zero algorithm field
+   indicates that the algorithm is unknown to a secure DNS, which may
+   simply be the result of the algorithm not having been standardized
+   for DNSSEC [11].
+
+2.1.  Certificate Type Values
+
+   The following values are defined or reserved:
+
+         Value  Mnemonic  Certificate Type
+         -----  --------  ----------------
+             0            Reserved
+             1  PKIX      X.509 as per PKIX
+             2  SPKI      SPKI certificate
+             3  PGP       OpenPGP packet
+             4  IPKIX     The URL of an X.509 data object
+             5  ISPKI     The URL of an SPKI certificate
+             6  IPGP      The fingerprint and URL of an OpenPGP packet
+             7  ACPKIX    Attribute Certificate
+             8  IACPKIX   The URL of an Attribute Certificate
+         9-252            Available for IANA assignment
+           253  URI       URI private
+           254  OID       OID private
+           255            Reserved
+     256-65279            Available for IANA assignment
+   65280-65534            Experimental
+         65535            Reserved
+
+   These values represent the initial content of the IANA registry; see
+   Section 8.
+
+   The PKIX type is reserved to indicate an X.509 certificate conforming
+   to the profile defined by the IETF PKIX working group [8].  The
+   certificate section will start with a one-octet unsigned OID length
+   and then an X.500 OID indicating the nature of the remainder of the
+
+
+
+
+
+Josefsson                   Standards Track                     [Page 4]
+
+RFC 4398            Storing Certificates in the DNS        February 2006
+
+
+   certificate section (see Section 2.3, below).  (NOTE: X.509
+   certificates do not include their X.500 directory-type-designating
+   OID as a prefix.)
+
+   The SPKI and ISPKI types are reserved to indicate the SPKI
+   certificate format [15], for use when the SPKI documents are moved
+   from experimental status.  The format for these two CERT RR types
+   will need to be specified later.
+
+   The PGP type indicates an OpenPGP packet as described in [5] and its
+   extensions and successors.  This is used to transfer public key
+   material and revocation signatures.  The data is binary and MUST NOT
+   be encoded into an ASCII armor.  An implementation SHOULD process
+   transferable public keys as described in Section 10.1 of [5], but it
+   MAY handle additional OpenPGP packets.
+
+   The ACPKIX type indicates an Attribute Certificate format [9].
+
+   The IPKIX and IACPKIX types indicate a URL that will serve the
+   content that would have been in the "certificate, CRL, or URL" field
+   of the corresponding type (PKIX or ACPKIX, respectively).
+
+   The IPGP type contains both an OpenPGP fingerprint for the key in
+   question, as well as a URL.  The certificate portion of the IPGP CERT
+   RR is defined as a one-octet fingerprint length, followed by the
+   OpenPGP fingerprint, followed by the URL.  The OpenPGP fingerprint is
+   calculated as defined in RFC 2440 [5].  A zero-length fingerprint or
+   a zero-length URL are legal, and indicate URL-only IPGP data or
+   fingerprint-only IPGP data, respectively.  A zero-length fingerprint
+   and a zero-length URL are meaningless and invalid.
+
+   The IPKIX, ISPKI, IPGP, and IACPKIX types are known as "indirect".
+   These types MUST be used when the content is too large to fit in the
+   CERT RR and MAY be used at the implementer's discretion.  They SHOULD
+   NOT be used where the DNS message is 512 octets or smaller and could
+   thus be expected to fit a UDP packet.
+
+   The URI private type indicates a certificate format defined by an
+   absolute URI.  The certificate portion of the CERT RR MUST begin with
+   a null-terminated URI [10], and the data after the null is the
+   private format certificate itself.  The URI SHOULD be such that a
+   retrieval from it will lead to documentation on the format of the
+   certificate.  Recognition of private certificate types need not be
+   based on URI equality but can use various forms of pattern matching
+   so that, for example, subtype or version information can also be
+   encoded into the URI.
+
+
+
+
+
+Josefsson                   Standards Track                     [Page 5]
+
+RFC 4398            Storing Certificates in the DNS        February 2006
+
+
+   The OID private type indicates a private format certificate specified
+   by an ISO OID prefix.  The certificate section will start with a
+   one-octet unsigned OID length and then a BER-encoded OID indicating
+   the nature of the remainder of the certificate section.  This can be
+   an X.509 certificate format or some other format.  X.509 certificates
+   that conform to the IETF PKIX profile SHOULD be indicated by the PKIX
+   type, not the OID private type.  Recognition of private certificate
+   types need not be based on OID equality but can use various forms of
+   pattern matching such as OID prefix.
+
+2.2.  Text Representation of CERT RRs
+
+   The RDATA portion of a CERT RR has the type field as an unsigned
+   decimal integer or as a mnemonic symbol as listed in Section 2.1,
+   above.
+
+   The key tag field is represented as an unsigned decimal integer.
+
+   The algorithm field is represented as an unsigned decimal integer or
+   a mnemonic symbol as listed in [12].
+
+   The certificate/CRL portion is represented in base 64 [16] and may be
+   divided into any number of white-space-separated substrings, down to
+   single base-64 digits, which are concatenated to obtain the full
+   signature.  These substrings can span lines using the standard
+   parenthesis.
+
+   Note that the certificate/CRL portion may have internal sub-fields,
+   but these do not appear in the master file representation.  For
+   example, with type 254, there will be an OID size, an OID, and then
+   the certificate/CRL proper.  However, only a single logical base-64
+   string will appear in the text representation.
+
+2.3.  X.509 OIDs
+
+   OIDs have been defined in connection with the X.500 directory for
+   user certificates, certification authority certificates, revocations
+   of certification authority, and revocations of user certificates.
+   The following table lists the OIDs, their BER encoding, and their
+   length-prefixed hex format for use in CERT RRs:
+
+
+
+
+
+
+
+
+
+
+
+Josefsson                   Standards Track                     [Page 6]
+
+RFC 4398            Storing Certificates in the DNS        February 2006
+
+
+       id-at-userCertificate
+           = { joint-iso-ccitt(2) ds(5) at(4) 36 }
+              == 0x 03 55 04 24
+       id-at-cACertificate
+           = { joint-iso-ccitt(2) ds(5) at(4) 37 }
+              == 0x 03 55 04 25
+       id-at-authorityRevocationList
+           = { joint-iso-ccitt(2) ds(5) at(4) 38 }
+              == 0x 03 55 04 26
+       id-at-certificateRevocationList
+           = { joint-iso-ccitt(2) ds(5) at(4) 39 }
+              == 0x 03 55 04 27
+
+3.  Appropriate Owner Names for CERT RRs
+
+   It is recommended that certificate CERT RRs be stored under a domain
+   name related to their subject, i.e., the name of the entity intended
+   to control the private key corresponding to the public key being
+   certified.  It is recommended that certificate revocation list CERT
+   RRs be stored under a domain name related to their issuer.
+
+   Following some of the guidelines below may result in DNS names with
+   characters that require DNS quoting as per Section 5.1 of RFC 1035
+   [2].
+
+   The choice of name under which CERT RRs are stored is important to
+   clients that perform CERT queries.  In some situations, the clients
+   may not know all information about the CERT RR object it wishes to
+   retrieve.  For example, a client may not know the subject name of an
+   X.509 certificate, or the email address of the owner of an OpenPGP
+   key.  Further, the client might only know the hostname of a service
+   that uses X.509 certificates or the Key ID of an OpenPGP key.
+
+   Therefore, two owner name guidelines are defined: content-based owner
+   names and purpose-based owner names.  A content-based owner name is
+   derived from the content of the CERT RR data; for example, the
+   Subject field in an X.509 certificate or the User ID field in OpenPGP
+   keys.  A purpose-based owner name is a name that a client retrieving
+   CERT RRs ought to know already; for example, the host name of an
+   X.509 protected service or the Key ID of an OpenPGP key.  The
+   content-based and purpose-based owner name may be the same; for
+   example, when a client looks up a key based on the From: address of
+   an incoming email.
+
+   Implementations SHOULD use the purpose-based owner name guidelines
+   described in this document and MAY use CNAME RRs at content-based
+   owner names (or other names), pointing to the purpose-based owner
+   name.
+
+
+
+Josefsson                   Standards Track                     [Page 7]
+
+RFC 4398            Storing Certificates in the DNS        February 2006
+
+
+   Note that this section describes an application-based mapping from
+   the name space used in a certificate to the name space used by DNS.
+   The DNS does not infer any relationship amongst CERT resource records
+   based on similarities or differences of the DNS owner name(s) of CERT
+   resource records.  For example, if multiple labels are used when
+   mapping from a CERT identifier to a domain name, then care must be
+   taken in understanding wildcard record synthesis.
+
+3.1.  Content-Based X.509 CERT RR Names
+
+   Some X.509 versions, such as the PKIX profile of X.509 [8], permit
+   multiple names to be associated with subjects and issuers under
+   "Subject Alternative Name" and "Issuer Alternative Name".  For
+   example, the PKIX profile has such Alternate Names with an ASN.1
+   specification as follows:
+
+      GeneralName ::= CHOICE {
+           otherName                       [0]     OtherName,
+           rfc822Name                      [1]     IA5String,
+           dNSName                         [2]     IA5String,
+           x400Address                     [3]     ORAddress,
+           directoryName                   [4]     Name,
+           ediPartyName                    [5]     EDIPartyName,
+           uniformResourceIdentifier       [6]     IA5String,
+           iPAddress                       [7]     OCTET STRING,
+           registeredID                    [8]     OBJECT IDENTIFIER }
+
+   The recommended locations of CERT storage are as follows, in priority
+   order:
+
+   1.  If a domain name is included in the identification in the
+       certificate or CRL, that ought to be used.
+   2.  If a domain name is not included but an IP address is included,
+       then the translation of that IP address into the appropriate
+       inverse domain name ought to be used.
+   3.  If neither of the above is used, but a URI containing a domain
+       name is present, that domain name ought to be used.
+   4.  If none of the above is included but a character string name is
+       included, then it ought to be treated as described below for
+       OpenPGP names.
+   5.  If none of the above apply, then the distinguished name (DN)
+       ought to be mapped into a domain name as specified in [4].
+
+   Example 1: An X.509v3 certificate is issued to /CN=John Doe /DC=Doe/
+   DC=com/DC=xy/O=Doe Inc/C=XY/ with Subject Alternative Names of (a)
+   string "John (the Man) Doe", (b) domain name john-doe.com, and (c)
+   URI <https://www.secure.john-doe.com:8080/>.  The storage locations
+   recommended, in priority order, would be
+
+
+
+Josefsson                   Standards Track                     [Page 8]
+
+RFC 4398            Storing Certificates in the DNS        February 2006
+
+
+   1.  john-doe.com,
+   2.  www.secure.john-doe.com, and
+   3.  Doe.com.xy.
+
+   Example 2: An X.509v3 certificate is issued to /CN=James Hacker/
+   L=Basingstoke/O=Widget Inc/C=GB/ with Subject Alternate names of (a)
+   domain name widget.foo.example, (b) IPv4 address 10.251.13.201, and
+   (c) string "James Hacker <hacker@mail.widget.foo.example>".  The
+   storage locations recommended, in priority order, would be
+
+   1.  widget.foo.example,
+   2.  201.13.251.10.in-addr.arpa, and
+   3.  hacker.mail.widget.foo.example.
+
+3.2.  Purpose-Based X.509 CERT RR Names
+
+   Due to the difficulty for clients that do not already possess a
+   certificate to reconstruct the content-based owner name,
+   purpose-based owner names are recommended in this section.
+   Recommendations for purpose-based owner names vary per scenario.  The
+   following table summarizes the purpose-based X.509 CERT RR owner name
+   guidelines for use with S/MIME [17], SSL/TLS [13], and IPsec [14]:
+
+    Scenario             Owner name
+    ------------------   ----------------------------------------------
+    S/MIME Certificate   Standard translation of an RFC 2822 email
+                         address.  Example: An S/MIME certificate for
+                         "postmaster@example.org" will use a standard
+                         hostname translation of the owner name,
+                         "postmaster.example.org".
+
+    TLS Certificate      Hostname of the TLS server.
+
+    IPsec Certificate    Hostname of the IPsec machine and/or, for IPv4
+                         or IPv6 addresses, the fully qualified domain
+                         name in the appropriate reverse domain.
+
+   An alternate approach for IPsec is to store raw public keys [18].
+
+3.3.  Content-Based OpenPGP CERT RR Names
+
+   OpenPGP signed keys (certificates) use a general character string
+   User ID [5].  However, it is recommended by OpenPGP that such names
+   include the RFC 2822 [7] email address of the party, as in "Leslie
+   Example <Leslie@host.example>".  If such a format is used, the CERT
+   ought to be under the standard translation of the email address into
+
+
+
+
+
+Josefsson                   Standards Track                     [Page 9]
+
+RFC 4398            Storing Certificates in the DNS        February 2006
+
+
+   a domain name, which would be leslie.host.example in this case.  If
+   no RFC 2822 name can be extracted from the string name, no specific
+   domain name is recommended.
+
+   If a user has more than one email address, the CNAME type can be used
+   to reduce the amount of data stored in the DNS.  For example:
+
+      $ORIGIN example.org.
+      smith        IN CERT PGP 0 0 <OpenPGP binary>
+      john.smith   IN CNAME smith
+      js           IN CNAME smith
+
+3.4.  Purpose-Based OpenPGP CERT RR Names
+
+   Applications that receive an OpenPGP packet containing encrypted or
+   signed data but do not know the email address of the sender will have
+   difficulties constructing the correct owner name and cannot use the
+   content-based owner name guidelines.  However, these clients commonly
+   know the key fingerprint or the Key ID.  The key ID is found in
+   OpenPGP packets, and the key fingerprint is commonly found in
+   auxiliary data that may be available.  In this case, use of an owner
+   name identical to the key fingerprint and the key ID expressed in
+   hexadecimal [16] is recommended.  For example:
+
+      $ORIGIN example.org.
+      0424D4EE81A0E3D119C6F835EDA21E94B565716F IN CERT PGP ...
+      F835EDA21E94B565716F                     IN CERT PGP ...
+      B565716F                                 IN CERT PGP ...
+
+   If the same key material is stored for several owner names, the use
+   of CNAME may help avoid data duplication.  Note that CNAME is not
+   always applicable, because it maps one owner name to the other for
+   all purposes, which may be sub-optimal when two keys with the same
+   Key ID are stored.
+
+3.5.  Owner Names for IPKIX, ISPKI, IPGP, and IACPKIX
+
+   These types are stored under the same owner names, both purpose- and
+   content-based, as the PKIX, SPKI, PGP, and ACPKIX types.
+
+
+
+
+
+
+
+
+
+
+
+
+Josefsson                   Standards Track                    [Page 10]
+
+RFC 4398            Storing Certificates in the DNS        February 2006
+
+
+4.  Performance Considerations
+
+   The Domain Name System (DNS) protocol was designed for small
+   transfers, typically below 512 octets.  While larger transfers will
+   perform correctly and work is underway to make larger transfers more
+   efficient, it is still advisable at this time that every reasonable
+   effort be made to minimize the size of certificates stored within the
+   DNS.  Steps that can be taken may include using the fewest possible
+   optional or extension fields and using short field values for
+   necessary variable-length fields.
+
+   The RDATA field in the DNS protocol may only hold data of size 65535
+   octets (64kb) or less.  This means that each CERT RR MUST NOT contain
+   more than 64kb of payload, even if the corresponding certificate or
+   certificate revocation list is larger.  This document addresses this
+   by defining "indirect" data types for each normal type.
+
+   Deploying CERT RRs to support digitally signed email changes the
+   access patterns of DNS lookups from per-domain to per-user.  If
+   digitally signed email and a key/certificate lookup based on CERT RRs
+   are deployed on a wide scale, this may lead to an increased DNS load,
+   with potential performance and cache effectiveness consequences.
+   Whether or not this load increase will be noticeable is not known.
+
+5.  Contributors
+
+   The majority of this document is copied verbatim from RFC 2538, by
+   Donald Eastlake 3rd and Olafur Gudmundsson.
+
+6.  Acknowledgements
+
+   Thanks to David Shaw and Michael Graff for their contributions to
+   earlier works that motivated, and served as inspiration for, this
+   document.
+
+   This document was improved by suggestions and comments from Olivier
+   Dubuisson, Scott Hollenbeck, Russ Housley, Peter Koch, Olaf M.
+   Kolkman, Ben Laurie, Edward Lewis, John Loughney, Allison Mankin,
+   Douglas Otis, Marcos Sanz, Pekka Savola, Jason Sloderbeck, Samuel
+   Weiler, and Florian Weimer.  No doubt the list is incomplete.  We
+   apologize to anyone we left out.
+
+
+
+
+
+
+
+
+
+
+Josefsson                   Standards Track                    [Page 11]
+
+RFC 4398            Storing Certificates in the DNS        February 2006
+
+
+7.  Security Considerations
+
+   By definition, certificates contain their own authenticating
+   signatures.  Thus, it is reasonable to store certificates in
+   non-secure DNS zones or to retrieve certificates from DNS with DNS
+   security checking not implemented or deferred for efficiency.  The
+   results may be trusted if the certificate chain is verified back to a
+   known trusted key and this conforms with the user's security policy.
+
+   Alternatively, if certificates are retrieved from a secure DNS zone
+   with DNS security checking enabled and are verified by DNS security,
+   the key within the retrieved certificate may be trusted without
+   verifying the certificate chain if this conforms with the user's
+   security policy.
+
+   If an organization chooses to issue certificates for its employees,
+   placing CERT RRs in the DNS by owner name, and if DNSSEC (with NSEC)
+   is in use, it is possible for someone to enumerate all employees of
+   the organization.  This is usually not considered desirable, for the
+   same reason that enterprise phone listings are not often publicly
+   published and are even marked confidential.
+
+   Using the URI type introduces another level of indirection that may
+   open a new vulnerability.  One method of securing that indirection is
+   to include a hash of the certificate in the URI itself.
+
+   If DNSSEC is used, then the non-existence of a CERT RR and,
+   consequently, certificates or revocation lists can be securely
+   asserted.  Without DNSSEC, this is not possible.
+
+8.  IANA Considerations
+
+   The IANA has created a new registry for CERT RR: certificate types.
+   The initial contents of this registry is:
+
+       Decimal   Type     Meaning                           Reference
+       -------   ----     -------                           ---------
+             0            Reserved                          RFC 4398
+             1   PKIX     X.509 as per PKIX                 RFC 4398
+             2   SPKI     SPKI certificate                  RFC 4398
+             3   PGP      OpenPGP packet                    RFC 4398
+             4   IPKIX    The URL of an X.509 data object   RFC 4398
+             5   ISPKI    The URL of an SPKI certificate    RFC 4398
+             6   IPGP     The fingerprint and URL           RFC 4398
+                          of an OpenPGP packet
+             7   ACPKIX   Attribute Certificate             RFC 4398
+             8   IACPKIX  The URL of an Attribute           RFC 4398
+                             Certificate
+
+
+
+Josefsson                   Standards Track                    [Page 12]
+
+RFC 4398            Storing Certificates in the DNS        February 2006
+
+
+         9-252            Available for IANA assignment
+                             by IETF Standards action
+           253   URI      URI private                       RFC 4398
+           254   OID      OID private                       RFC 4398
+           255            Reserved                          RFC 4398
+     256-65279            Available for IANA assignment
+                          by IETF Consensus
+   65280-65534            Experimental                      RFC 4398
+         65535            Reserved                          RFC 4398
+
+   Certificate types 0x0000 through 0x00FF and 0xFF00 through 0xFFFF can
+   only be assigned by an IETF standards action [6].  This document
+   assigns 0x0001 through 0x0008 and 0x00FD and 0x00FE.  Certificate
+   types 0x0100 through 0xFEFF are assigned through IETF Consensus [6]
+   based on RFC documentation of the certificate type.  The availability
+   of private types under 0x00FD and 0x00FE ought to satisfy most
+   requirements for proprietary or private types.
+
+   The CERT RR reuses the DNS Security Algorithm Numbers registry.  In
+   particular, the CERT RR requires that algorithm number 0 remain
+   reserved, as described in Section 2.  The IANA will reference the
+   CERT RR as a user of this registry and value 0, in particular.
+
+9.  Changes since RFC 2538
+
+   1.   Editorial changes to conform with new document requirements,
+        including splitting reference section into two parts and
+        updating the references to point at latest versions, and to add
+        some additional references.
+   2.   Improve terminology.  For example replace "PGP" with "OpenPGP",
+        to align with RFC 2440.
+   3.   In Section 2.1, clarify that OpenPGP public key data are binary,
+        not the ASCII armored format, and reference 10.1 in RFC 2440 on
+        how to deal with OpenPGP keys, and acknowledge that
+        implementations may handle additional packet types.
+   4.   Clarify that integers in the representation format are decimal.
+   5.   Replace KEY/SIG with DNSKEY/RRSIG etc, to align with DNSSECbis
+        terminology.  Improve reference for Key Tag Algorithm
+        calculations.
+   6.   Add examples that suggest use of CNAME to reduce bandwidth.
+   7.   In Section 3, appended the last paragraphs that discuss
+        "content-based" vs "purpose-based" owner names.  Add Section 3.2
+        for purpose-based X.509 CERT owner names, and Section 3.4 for
+        purpose-based OpenPGP CERT owner names.
+   8.   Added size considerations.
+   9.   The SPKI types has been reserved, until RFC 2692/2693 is moved
+        from the experimental status.
+   10.  Added indirect types IPKIX, ISPKI, IPGP, and IACPKIX.
+
+
+
+Josefsson                   Standards Track                    [Page 13]
+
+RFC 4398            Storing Certificates in the DNS        February 2006
+
+
+   11.  An IANA registry of CERT type values was created.
+
+10.  References
+
+10.1.  Normative References
+
+   [1]   Mockapetris, P., "Domain names - concepts and facilities",
+         STD 13, RFC 1034, November 1987.
+
+   [2]   Mockapetris, P., "Domain names - implementation and
+         specification", STD 13, RFC 1035, November 1987.
+
+   [3]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
+         Levels", BCP 14, RFC 2119, March 1997.
+
+   [4]   Kille, S., Wahl, M., Grimstad, A., Huber, R., and S. Sataluri,
+         "Using Domains in LDAP/X.500 Distinguished Names", RFC 2247,
+         January 1998.
+
+   [5]   Callas, J., Donnerhacke, L., Finney, H., and R. Thayer,
+         "OpenPGP Message Format", RFC 2440, November 1998.
+
+   [6]   Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
+         Considerations Section in RFCs", BCP 26, RFC 2434,
+         October 1998.
+
+   [7]   Resnick, P., "Internet Message Format", RFC 2822, April 2001.
+
+   [8]   Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509
+         Public Key Infrastructure Certificate and Certificate
+         Revocation List (CRL) Profile", RFC 3280, April 2002.
+
+   [9]   Farrell, S. and R. Housley, "An Internet Attribute Certificate
+         Profile for Authorization", RFC 3281, April 2002.
+
+   [10]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
+         Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986,
+         January 2005.
+
+   [11]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+         "DNS Security Introduction and Requirements", RFC 4033,
+         March 2005.
+
+   [12]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+         "Resource Records for the DNS Security Extensions", RFC 4034,
+         March 2005.
+
+
+
+
+
+Josefsson                   Standards Track                    [Page 14]
+
+RFC 4398            Storing Certificates in the DNS        February 2006
+
+
+10.2.  Informative References
+
+   [13]  Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
+         RFC 2246, January 1999.
+
+   [14]  Kent, S. and K. Seo, "Security Architecture for the Internet
+         Protocol", RFC 4301, December 2005.
+
+   [15]  Ellison, C., Frantz, B., Lampson, B., Rivest, R., Thomas, B.,
+         and T. Ylonen, "SPKI Certificate Theory", RFC 2693,
+         September 1999.
+
+   [16]  Josefsson, S., "The Base16, Base32, and Base64 Data Encodings",
+         RFC 3548, July 2003.
+
+   [17]  Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions
+         (S/MIME) Version 3.1 Message Specification", RFC 3851,
+         July 2004.
+
+   [18]  Richardson, M., "A Method for Storing IPsec Keying Material in
+         DNS", RFC 4025, March 2005.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Josefsson                   Standards Track                    [Page 15]
+
+RFC 4398            Storing Certificates in the DNS        February 2006
+
+
+Appendix A.  Copying Conditions
+
+   Regarding the portion of this document that was written by Simon
+   Josefsson ("the author", for the remainder of this section), the
+   author makes no guarantees and is not responsible for any damage
+   resulting from its use.  The author grants irrevocable permission to
+   anyone to use, modify, and distribute it in any way that does not
+   diminish the rights of anyone else to use, modify, and distribute it,
+   provided that redistributed derivative works do not contain
+   misleading author or version information.  Derivative works need not
+   be licensed under similar terms.
+
+Author's Address
+
+   Simon Josefsson
+
+   EMail: simon@josefsson.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Josefsson                   Standards Track                    [Page 16]
+
+RFC 4398            Storing Certificates in the DNS        February 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Josefsson                   Standards Track                    [Page 17]
+
diff --git a/doc/rfc/rfc4408.txt b/doc/rfc/rfc4408.txt
new file mode 100644
index 0000000..bc1b3f5
--- /dev/null
+++ b/doc/rfc/rfc4408.txt
@@ -0,0 +1,2691 @@
+
+
+
+
+
+
+Network Working Group                                            M. Wong
+Request for Comments: 4408                                    W. Schlitt
+Category: Experimental                                        April 2006
+
+
+                   Sender Policy Framework (SPF) for
+            Authorizing Use of Domains in E-Mail, Version 1
+
+Status of This Memo
+
+   This memo defines an Experimental Protocol for the Internet
+   community.  It does not specify an Internet standard of any kind.
+   Discussion and suggestions for improvement are requested.
+   Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+IESG Note
+
+   The following documents  (RFC 4405, RFC 4406, RFC 4407, and RFC 4408)
+   are published simultaneously as Experimental RFCs, although there is
+   no general technical consensus and efforts to reconcile the two
+   approaches have failed.  As such, these documents have not received
+   full IETF review and are published "AS-IS" to document the different
+   approaches as they were considered in the MARID working group.
+
+   The IESG takes no position about which approach is to be preferred
+   and cautions the reader that there are serious open issues for each
+   approach and concerns about using them in tandem.  The IESG believes
+   that documenting the different approaches does less harm than not
+   documenting them.
+
+   Note that the Sender ID experiment may use DNS records that may have
+   been created for the current SPF experiment or earlier versions in
+   this set of experiments.  Depending on the content of the record,
+   this may mean that Sender-ID heuristics would be applied incorrectly
+   to a message.  Depending on the actions associated by the recipient
+   with those heuristics, the message may not be delivered or may be
+   discarded on receipt.
+
+   Participants relying on Sender ID experiment DNS records are warned
+   that they may lose valid messages in this set of circumstances.
+   aParticipants publishing SPF experiment DNS records should consider
+   the advice given in section 3.4 of RFC 4406 and may wish to publish
+   both v=spf1 and spf2.0 records to avoid the conflict.
+
+
+
+
+Wong & Schlitt                Experimental                      [Page 1]
+
+RFC 4408             Sender Policy Framework (SPF)            April 2006
+
+
+   Participants in the Sender-ID experiment need to be aware that the
+   way Resent-* header fields are used will result in failure to receive
+   legitimate email when interacting with standards-compliant systems
+   (specifically automatic forwarders which comply with the standards by
+   not adding Resent-* headers, and systems which comply with RFC 822
+   but have not yet implemented RFC 2822 Resent-* semantics).  It would
+   be inappropriate to advance Sender-ID on the standards track without
+   resolving this interoperability problem.
+
+   The community is invited to observe the success or failure of the two
+   approaches during the two years following publication, in order that
+   a community consensus can be reached in the future.
+
+Abstract
+
+   E-mail on the Internet can be forged in a number of ways.  In
+   particular, existing protocols place no restriction on what a sending
+   host can use as the reverse-path of a message or the domain given on
+   the SMTP HELO/EHLO commands.  This document describes version 1 of
+   the Sender Policy Framework (SPF) protocol, whereby a domain may
+   explicitly authorize the hosts that are allowed to use its domain
+   name, and a receiving host may check such authorization.
+
+Table of Contents
+
+   1. Introduction ....................................................4
+      1.1. Protocol Status ............................................4
+      1.2. Terminology ................................................5
+   2. Operation .......................................................5
+      2.1. The HELO Identity ..........................................5
+      2.2. The MAIL FROM Identity .....................................5
+      2.3. Publishing Authorization ...................................6
+      2.4. Checking Authorization .....................................6
+      2.5. Interpreting the Result ....................................7
+           2.5.1. None ................................................8
+           2.5.2. Neutral .............................................8
+           2.5.3. Pass ................................................8
+           2.5.4. Fail ................................................8
+           2.5.5. SoftFail ............................................9
+           2.5.6. TempError ...........................................9
+           2.5.7. PermError ...........................................9
+   3. SPF Records .....................................................9
+      3.1. Publishing ................................................10
+           3.1.1. DNS Resource Record Types ..........................10
+           3.1.2. Multiple DNS Records ...............................11
+           3.1.3. Multiple Strings in a Single DNS record ............11
+           3.1.4. Record Size ........................................11
+           3.1.5. Wildcard Records ...................................11
+
+
+
+Wong & Schlitt                Experimental                      [Page 2]
+
+RFC 4408             Sender Policy Framework (SPF)            April 2006
+
+
+   4. The check_host() Function ......................................12
+      4.1. Arguments .................................................12
+      4.2. Results ...................................................13
+      4.3. Initial Processing ........................................13
+      4.4. Record Lookup .............................................13
+      4.5. Selecting Records .........................................13
+      4.6. Record Evaluation .........................................14
+           4.6.1. Term Evaluation ....................................14
+           4.6.2. Mechanisms .........................................15
+           4.6.3. Modifiers ..........................................15
+      4.7. Default Result ............................................16
+      4.8. Domain Specification ......................................16
+   5. Mechanism Definitions ..........................................16
+      5.1. "all" .....................................................17
+      5.2. "include" .................................................18
+      5.3. "a" .......................................................19
+      5.4. "mx" ......................................................20
+      5.5. "ptr" .....................................................20
+      5.6. "ip4" and "ip6" ...........................................21
+      5.7. "exists" ..................................................22
+   6. Modifier Definitions ...........................................22
+      6.1. redirect: Redirected Query ................................23
+      6.2. exp: Explanation ..........................................23
+   7. The Received-SPF Header Field ..................................25
+   8. Macros .........................................................27
+      8.1. Macro Definitions .........................................27
+      8.2. Expansion Examples ........................................30
+   9. Implications ...................................................31
+      9.1. Sending Domains ...........................................31
+      9.2. Mailing Lists .............................................32
+      9.3. Forwarding Services and Aliases ...........................32
+      9.4. Mail Services .............................................34
+      9.5. MTA Relays ................................................34
+   10. Security Considerations .......................................35
+      10.1. Processing Limits ........................................35
+      10.2. SPF-Authorized E-Mail May Contain Other False
+            Identities ...............................................37
+      10.3. Spoofed DNS and IP Data ..................................37
+      10.4. Cross-User Forgery .......................................37
+      10.5. Untrusted Information Sources ............................38
+      10.6. Privacy Exposure .........................................38
+   11. Contributors and Acknowledgements .............................38
+   12. IANA Considerations ...........................................39
+      12.1. The SPF DNS Record Type ..................................39
+      12.2. The Received-SPF Mail Header Field .......................39
+   13. References ....................................................39
+      13.1. Normative References .....................................39
+      13.2. Informative References ...................................40
+
+
+
+Wong & Schlitt                Experimental                      [Page 3]
+
+RFC 4408             Sender Policy Framework (SPF)            April 2006
+
+
+   Appendix A.  Collected ABNF .......................................42
+   Appendix B.  Extended Examples ....................................44
+      B.1.  Simple Examples ..........................................44
+      B.2.  Multiple Domain Example ..................................45
+      B.3.  DNSBL Style Example ......................................46
+      B.4.  Multiple Requirements Example ............................46
+
+1.  Introduction
+
+   The current E-Mail infrastructure has the property that any host
+   injecting mail into the mail system can identify itself as any domain
+   name it wants.  Hosts can do this at a variety of levels: in
+   particular, the session, the envelope, and the mail headers.
+   Although this feature is desirable in some circumstances, it is a
+   major obstacle to reducing Unsolicited Bulk E-Mail (UBE, aka spam).
+   Furthermore, many domain name holders are understandably concerned
+   about the ease with which other entities may make use of their domain
+   names, often with malicious intent.
+
+   This document defines a protocol by which domain owners may authorize
+   hosts to use their domain name in the "MAIL FROM" or "HELO" identity.
+   Compliant domain holders publish Sender Policy Framework (SPF)
+   records specifying which hosts are permitted to use their names, and
+   compliant mail receivers use the published SPF records to test the
+   authorization of sending Mail Transfer Agents (MTAs) using a given
+   "HELO" or "MAIL FROM" identity during a mail transaction.
+
+   An additional benefit to mail receivers is that after the use of an
+   identity is verified, local policy decisions about the mail can be
+   made based on the sender's domain, rather than the host's IP address.
+   This is advantageous because reputation of domain names is likely to
+   be more accurate than reputation of host IP addresses.  Furthermore,
+   if a claimed identity fails verification, local policy can take
+   stronger action against such E-Mail, such as rejecting it.
+
+1.1.  Protocol Status
+
+   SPF has been in development since the summer of 2003 and has seen
+   deployment beyond the developers beginning in December 2003.  The
+   design of SPF slowly evolved until the spring of 2004 and has since
+   stabilized.  There have been quite a number of forms of SPF, some
+   written up as documents, some submitted as Internet Drafts, and many
+   discussed and debated in development forums.
+
+   The goal of this document is to clearly document the protocol defined
+   by earlier draft specifications of SPF as used in existing
+   implementations.  This conception of SPF is sometimes called "SPF
+   Classic".  It is understood that particular implementations and
+
+
+
+Wong & Schlitt                Experimental                      [Page 4]
+
+RFC 4408             Sender Policy Framework (SPF)            April 2006
+
+
+   deployments may differ from, and build upon, this work.  It is hoped
+   that we have nonetheless captured the common understanding of SPF
+   version 1.
+
+1.2.  Terminology
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+   This document is concerned with the portion of a mail message
+   commonly called "envelope sender", "return path", "reverse path",
+   "bounce address", "2821 FROM", or "MAIL FROM".  Since these terms are
+   either not well defined or often used casually, this document defines
+   the "MAIL FROM" identity in Section 2.2.  Note that other terms that
+   may superficially look like the common terms, such as "reverse-path",
+   are used only with the defined meanings from normative documents.
+
+2.  Operation
+
+2.1.  The HELO Identity
+
+   The "HELO" identity derives from either the SMTP HELO or EHLO command
+   (see [RFC2821]).  These commands supply the SMTP client (sending
+   host) for the SMTP session.  Note that requirements for the domain
+   presented in the EHLO or HELO command are not always clear to the
+   sending party, and SPF clients must be prepared for the "HELO"
+   identity to be malformed or an IP address literal.  At the time of
+   this writing, many legitimate E-Mails are delivered with invalid HELO
+   domains.
+
+   It is RECOMMENDED that SPF clients not only check the "MAIL FROM"
+   identity, but also separately check the "HELO" identity by applying
+   the check_host() function (Section 4) to the "HELO" identity as the
+   <sender>.
+
+2.2.  The MAIL FROM Identity
+
+   The "MAIL FROM" identity derives from the SMTP MAIL command (see
+   [RFC2821]).  This command supplies the "reverse-path" for a message,
+   which generally consists of the sender mailbox, and is the mailbox to
+   which notification messages are to be sent if there are problems
+   delivering the message.
+
+   [RFC2821] allows the reverse-path to be null (see Section 4.5.5 in
+   RFC 2821).  In this case, there is no explicit sender mailbox, and
+   such a message can be assumed to be a notification message from the
+   mail system itself.  When the reverse-path is null, this document
+
+
+
+Wong & Schlitt                Experimental                      [Page 5]
+
+RFC 4408             Sender Policy Framework (SPF)            April 2006
+
+
+   defines the "MAIL FROM" identity to be the mailbox composed of the
+   localpart "postmaster" and the "HELO" identity (which may or may not
+   have been checked separately before).
+
+   SPF clients MUST check the "MAIL FROM" identity.  SPF clients check
+   the "MAIL FROM" identity by applying the check_host() function to the
+   "MAIL FROM" identity as the <sender>.
+
+2.3.  Publishing Authorization
+
+   An SPF-compliant domain MUST publish a valid SPF record as described
+   in Section 3.  This record authorizes the use of the domain name in
+   the "HELO" and "MAIL FROM" identities by the MTAs it specifies.
+
+   If domain owners choose to publish SPF records, it is RECOMMENDED
+   that they end in "-all", or redirect to other records that do, so
+   that a definitive determination of authorization can be made.
+
+   Domain holders may publish SPF records that explicitly authorize no
+   hosts if mail should never originate using that domain.
+
+   When changing SPF records, care must be taken to ensure that there is
+   a transition period so that the old policy remains valid until all
+   legitimate E-Mail has been checked.
+
+2.4.  Checking Authorization
+
+   A mail receiver can perform a set of SPF checks for each mail message
+   it receives.  An SPF check tests the authorization of a client host
+   to emit mail with a given identity.  Typically, such checks are done
+   by a receiving MTA, but can be performed elsewhere in the mail
+   processing chain so long as the required information is available and
+   reliable.  At least the "MAIL FROM" identity MUST be checked, but it
+   is RECOMMENDED that the "HELO" identity also be checked beforehand.
+
+   Without explicit approval of the domain owner, checking other
+   identities against SPF version 1 records is NOT RECOMMENDED because
+   there are cases that are known to give incorrect results.  For
+   example, almost all mailing lists rewrite the "MAIL FROM" identity
+   (see Section 9.2), but some do not change any other identities in the
+   message.  The scenario described in Section 9.3, sub-section 1.2, is
+   another example.  Documents that define other identities should
+   define the method for explicit approval.
+
+   It is possible that mail receivers will use the SPF check as part of
+   a larger set of tests on incoming mail.  The results of other tests
+   may influence whether or not a particular SPF check is performed.
+   For example, finding the sending host's IP address on a local white
+
+
+
+Wong & Schlitt                Experimental                      [Page 6]
+
+RFC 4408             Sender Policy Framework (SPF)            April 2006
+
+
+   list may cause all other tests to be skipped and all mail from that
+   host to be accepted.
+
+   When a mail receiver decides to perform an SPF check, it MUST use a
+   correctly-implemented check_host() function (Section 4) evaluated
+   with the correct parameters.  Although the test as a whole is
+   optional, once it has been decided to perform a test it must be
+   performed as specified so that the correct semantics are preserved
+   between publisher and receiver.
+
+   To make the test, the mail receiver MUST evaluate the check_host()
+   function with the arguments set as follows:
+
+   <ip>     - the IP address of the SMTP client that is emitting the
+              mail, either IPv4 or IPv6.
+
+   <domain> - the domain portion of the "MAIL FROM" or "HELO" identity.
+
+   <sender> - the "MAIL FROM" or "HELO" identity.
+
+   Note that the <domain> argument may not be a well-formed domain name.
+   For example, if the reverse-path was null, then the EHLO/HELO domain
+   is used, with its associated problems (see Section 2.1).  In these
+   cases, check_host() is defined in Section 4.3 to return a "None"
+   result.
+
+   Although invalid, malformed, or non-existent domains cause SPF checks
+   to return "None" because no SPF record can be found, it has long been
+   the policy of many MTAs to reject E-Mail from such domains,
+   especially in the case of invalid "MAIL FROM".  In order to prevent
+   the circumvention of SPF records, rejecting E-Mail from invalid
+   domains should be considered.
+
+   Implementations must take care to correctly extract the <domain> from
+   the data given with the SMTP MAIL FROM command as many MTAs will
+   still accept such things as source routes (see [RFC2821], Appendix
+   C), the %-hack (see [RFC1123]), and bang paths (see [RFC1983]).
+   These archaic features have been maliciously used to bypass security
+   systems.
+
+2.5.  Interpreting the Result
+
+   This section describes how software that performs the authorization
+   should interpret the results of the check_host() function.  The
+   authorization check SHOULD be performed during the processing of the
+   SMTP transaction that sends the mail.  This allows errors to be
+   returned directly to the sending MTA by way of SMTP replies.
+
+
+
+
+Wong & Schlitt                Experimental                      [Page 7]
+
+RFC 4408             Sender Policy Framework (SPF)            April 2006
+
+
+   Performing the authorization after the SMTP transaction has finished
+   may cause problems, such as the following: (1) It may be difficult to
+   accurately extract the required information from potentially
+   deceptive headers; (2) legitimate E-Mail may fail because the
+   sender's policy may have since changed.
+
+   Generating non-delivery notifications to forged identities that have
+   failed the authorization check is generally abusive and against the
+   explicit wishes of the identity owner.
+
+2.5.1.  None
+
+   A result of "None" means that no records were published by the domain
+   or that no checkable sender domain could be determined from the given
+   identity.  The checking software cannot ascertain whether or not the
+   client host is authorized.
+
+2.5.2.  Neutral
+
+   The domain owner has explicitly stated that he cannot or does not
+   want to assert whether or not the IP address is authorized.  A
+   "Neutral" result MUST be treated exactly like the "None" result; the
+   distinction exists only for informational purposes.  Treating
+   "Neutral" more harshly than "None" would discourage domain owners
+   from testing the use of SPF records (see Section 9.1).
+
+2.5.3.  Pass
+
+   A "Pass" result means that the client is authorized to inject mail
+   with the given identity.  The domain can now, in the sense of
+   reputation, be considered responsible for sending the message.
+   Further policy checks can now proceed with confidence in the
+   legitimate use of the identity.
+
+2.5.4.  Fail
+
+   A "Fail" result is an explicit statement that the client is not
+   authorized to use the domain in the given identity.  The checking
+   software can choose to mark the mail based on this or to reject the
+   mail outright.
+
+   If the checking software chooses to reject the mail during the SMTP
+   transaction, then it SHOULD use an SMTP reply code of 550 (see
+   [RFC2821]) and, if supported, the 5.7.1 Delivery Status Notification
+   (DSN) code (see [RFC3464]), in addition to an appropriate reply text.
+   The check_host() function may return either a default explanation
+   string or one from the domain that published the SPF records (see
+   Section 6.2).  If the information does not originate with the
+
+
+
+Wong & Schlitt                Experimental                      [Page 8]
+
+RFC 4408             Sender Policy Framework (SPF)            April 2006
+
+
+   checking software, it should be made clear that the text is provided
+   by the sender's domain.  For example:
+
+       550-5.7.1 SPF MAIL FROM check failed:
+       550-5.7.1 The domain example.com explains:
+       550 5.7.1 Please see http://www.example.com/mailpolicy.html
+
+2.5.5.  SoftFail
+
+   A "SoftFail" result should be treated as somewhere between a "Fail"
+   and a "Neutral".  The domain believes the host is not authorized but
+   is not willing to make that strong of a statement.  Receiving
+   software SHOULD NOT reject the message based solely on this result,
+   but MAY subject the message to closer scrutiny than normal.
+
+   The domain owner wants to discourage the use of this host and thus
+   desires limited feedback when a "SoftFail" result occurs.  For
+   example, the recipient's Mail User Agent (MUA) could highlight the
+   "SoftFail" status, or the receiving MTA could give the sender a
+   message using a technique called "greylisting" whereby the MTA can
+   issue an SMTP reply code of 451 (4.3.0 DSN code) with a note the
+   first time the message is received, but accept it the second time.
+
+2.5.6.  TempError
+
+   A "TempError" result means that the SPF client encountered a
+   transient error while performing the check.  Checking software can
+   choose to accept or temporarily reject the message.  If the message
+   is rejected during the SMTP transaction for this reason, the software
+   SHOULD use an SMTP reply code of 451 and, if supported, the 4.4.3 DSN
+   code.
+
+2.5.7.  PermError
+
+   A "PermError" result means that the domain's published records could
+   not be correctly interpreted.  This signals an error condition that
+   requires manual intervention to be resolved, as opposed to the
+   TempError result.  Be aware that if the domain owner uses macros
+   (Section 8), it is possible that this result is due to the checked
+   identities having an unexpected format.
+
+3.  SPF Records
+
+   An SPF record is a DNS Resource Record (RR) that declares which hosts
+   are, and are not, authorized to use a domain name for the "HELO" and
+   "MAIL FROM" identities.  Loosely, the record partitions all hosts
+   into permitted and not-permitted sets (though some hosts might fall
+   into neither category).
+
+
+
+Wong & Schlitt                Experimental                      [Page 9]
+
+RFC 4408             Sender Policy Framework (SPF)            April 2006
+
+
+   The SPF record is a single string of text.  An example record is the
+   following:
+
+      v=spf1 +mx a:colo.example.com/28 -all
+
+   This record has a version of "spf1" and three directives: "+mx",
+   "a:colo.example.com/28" (the + is implied), and "-all".
+
+3.1.  Publishing
+
+   Domain owners wishing to be SPF compliant must publish SPF records
+   for the hosts that are used in the "MAIL FROM" and "HELO" identities.
+   The SPF records are placed in the DNS tree at the host name it
+   pertains to, not a subdomain under it, such as is done with SRV
+   records.  This is the same whether the TXT or SPF RR type (see
+   Section 3.1.1) is used.
+
+   The example above in Section 3 might be published via these lines in
+   a domain zone file:
+
+      example.com.          TXT "v=spf1 +mx a:colo.example.com/28 -all"
+      smtp-out.example.com. TXT "v=spf1 a -all"
+
+   When publishing via TXT records, beware of other TXT records
+   published there for other purposes.  They may cause problems with
+   size limits (see Section 3.1.4).
+
+3.1.1.  DNS Resource Record Types
+
+   This document defines a new DNS RR of type SPF, code 99.  The format
+   of this type is identical to the TXT RR [RFC1035].  For either type,
+   the character content of the record is encoded as [US-ASCII].
+
+   It is recognized that the current practice (using a TXT record) is
+   not optimal, but it is necessary because there are a number of DNS
+   server and resolver implementations in common use that cannot handle
+   the new RR type.  The two-record-type scheme provides a forward path
+   to the better solution of using an RR type reserved for this purpose.
+
+   An SPF-compliant domain name SHOULD have SPF records of both RR
+   types.  A compliant domain name MUST have a record of at least one
+   type.  If a domain has records of both types, they MUST have
+   identical content.  For example, instead of publishing just one
+   record as in Section 3.1 above, it is better to publish:
+
+      example.com. IN TXT "v=spf1 +mx a:colo.example.com/28 -all"
+      example.com. IN SPF "v=spf1 +mx a:colo.example.com/28 -all"
+
+
+
+
+Wong & Schlitt                Experimental                     [Page 10]
+
+RFC 4408             Sender Policy Framework (SPF)            April 2006
+
+
+   Example RRs in this document are shown with the TXT record type;
+   however, they could be published with the SPF type or with both
+   types.
+
+3.1.2.  Multiple DNS Records
+
+   A domain name MUST NOT have multiple records that would cause an
+   authorization check to select more than one record.  See Section 4.5
+   for the selection rules.
+
+3.1.3.  Multiple Strings in a Single DNS record
+
+   As defined in [RFC1035] sections 3.3.14 and 3.3, a single text DNS
+   record (either TXT or SPF RR types) can be composed of more than one
+   string.  If a published record contains multiple strings, then the
+   record MUST be treated as if those strings are concatenated together
+   without adding spaces.  For example:
+
+      IN TXT "v=spf1 .... first" "second string..."
+
+   MUST be treated as equivalent to
+
+      IN TXT "v=spf1 .... firstsecond string..."
+
+   SPF or TXT records containing multiple strings are useful in
+   constructing records that would exceed the 255-byte maximum length of
+   a string within a single TXT or SPF RR record.
+
+3.1.4.  Record Size
+
+   The published SPF record for a given domain name SHOULD remain small
+   enough that the results of a query for it will fit within 512 octets.
+   This will keep even older DNS implementations from falling over to
+   TCP.  Since the answer size is dependent on many things outside the
+   scope of this document, it is only possible to give this guideline:
+   If the combined length of the DNS name and the text of all the
+   records of a given type (TXT or SPF) is under 450 characters, then
+   DNS answers should fit in UDP packets.  Note that when computing the
+   sizes for queries of the TXT format, one must take into account any
+   other TXT records published at the domain name.  Records that are too
+   long to fit in a single UDP packet MAY be silently ignored by SPF
+   clients.
+
+3.1.5.  Wildcard Records
+
+   Use of wildcard records for publishing is not recommended.  Care must
+   be taken if wildcard records are used.  If a domain publishes
+   wildcard MX records, it may want to publish wildcard declarations,
+
+
+
+Wong & Schlitt                Experimental                     [Page 11]
+
+RFC 4408             Sender Policy Framework (SPF)            April 2006
+
+
+   subject to the same requirements and problems.  In particular, the
+   declaration must be repeated for any host that has any RR records at
+   all, and for subdomains thereof.  For example, the example given in
+   [RFC1034], Section 4.3.3, could be extended with the following:
+
+       X.COM.          MX      10      A.X.COM
+       X.COM.          TXT     "v=spf1 a:A.X.COM -all"
+
+       *.X.COM.        MX      10      A.X.COM
+       *.X.COM.        TXT     "v=spf1 a:A.X.COM -all"
+
+       A.X.COM.        A       1.2.3.4
+       A.X.COM.        MX      10      A.X.COM
+       A.X.COM.        TXT     "v=spf1 a:A.X.COM -all"
+
+       *.A.X.COM.      MX      10      A.X.COM
+       *.A.X.COM.      TXT     "v=spf1 a:A.X.COM -all"
+
+   Notice that SPF records must be repeated twice for every name within
+   the domain: once for the name, and once with a wildcard to cover the
+   tree under the name.
+
+   Use of wildcards is discouraged in general as they cause every name
+   under the domain to exist and queries against arbitrary names will
+   never return RCODE 3 (Name Error).
+
+4.  The check_host() Function
+
+   The check_host() function fetches SPF records, parses them, and
+   interprets them to determine whether a particular host is or is not
+   permitted to send mail with a given identity.  Mail receivers that
+   perform this check MUST correctly evaluate the check_host() function
+   as described here.
+
+   Implementations MAY use a different algorithm than the canonical
+   algorithm defined here, so long as the results are the same in all
+   cases.
+
+4.1.  Arguments
+
+   The check_host() function takes these arguments:
+
+   <ip>     - the IP address of the SMTP client that is emitting the
+              mail, either IPv4 or IPv6.
+
+   <domain> - the domain that provides the sought-after authorization
+              information; initially, the domain portion of the "MAIL
+              FROM" or "HELO" identity.
+
+
+
+Wong & Schlitt                Experimental                     [Page 12]
+
+RFC 4408             Sender Policy Framework (SPF)            April 2006
+
+
+   <sender> - the "MAIL FROM" or "HELO" identity.
+
+   The domain portion of <sender> will usually be the same as the
+   <domain> argument when check_host() is initially evaluated.  However,
+   this will generally not be true for recursive evaluations (see
+   Section 5.2 below).
+
+   Actual implementations of the check_host() function may need
+   additional arguments.
+
+4.2.  Results
+
+   The function check_host() can return one of several results described
+   in Section 2.5.  Based on the result, the action to be taken is
+   determined by the local policies of the receiver.
+
+4.3.  Initial Processing
+
+   If the <domain> is malformed (label longer than 63 characters, zero-
+   length label not at the end, etc.) or is not a fully qualified domain
+   name, or if the DNS lookup returns "domain does not exist" (RCODE 3),
+   check_host() immediately returns the result "None".
+
+   If the <sender> has no localpart, substitute the string "postmaster"
+   for the localpart.
+
+4.4.  Record Lookup
+
+   In accordance with how the records are published (see Section 3.1
+   above), a DNS query needs to be made for the <domain> name, querying
+   for either RR type TXT, SPF, or both.  If both SPF and TXT RRs are
+   looked up, the queries MAY be done in parallel.
+
+   If all DNS lookups that are made return a server failure (RCODE 2),
+   or other error (RCODE other than 0 or 3), or time out, then
+   check_host() exits immediately with the result "TempError".
+
+4.5.  Selecting Records
+
+   Records begin with a version section:
+
+   record           = version terms *SP
+   version          = "v=spf1"
+
+   Starting with the set of records that were returned by the lookup,
+   record selection proceeds in two steps:
+
+
+
+
+
+Wong & Schlitt                Experimental                     [Page 13]
+
+RFC 4408             Sender Policy Framework (SPF)            April 2006
+
+
+   1. Records that do not begin with a version section of exactly
+      "v=spf1" are discarded.  Note that the version section is
+      terminated either by an SP character or the end of the record.  A
+      record with a version section of "v=spf10" does not match and must
+      be discarded.
+
+   2. If any records of type SPF are in the set, then all records of
+      type TXT are discarded.
+
+   After the above steps, there should be exactly one record remaining
+   and evaluation can proceed.  If there are two or more records
+   remaining, then check_host() exits immediately with the result of
+   "PermError".
+
+   If no matching records are returned, an SPF client MUST assume that
+   the domain makes no SPF declarations.  SPF processing MUST stop and
+   return "None".
+
+4.6.  Record Evaluation
+
+   After one SPF record has been selected, the check_host() function
+   parses and interprets it to find a result for the current test.  If
+   there are any syntax errors, check_host() returns immediately with
+   the result "PermError".
+
+   Implementations MAY choose to parse the entire record first and
+   return "PermError" if the record is not syntactically well formed.
+   However, in all cases, any syntax errors anywhere in the record MUST
+   be detected.
+
+4.6.1.  Term Evaluation
+
+   There are two types of terms: mechanisms and modifiers.  A record
+   contains an ordered list of these as specified in the following
+   Augmented Backus-Naur Form (ABNF).
+
+   terms            = *( 1*SP ( directive / modifier ) )
+
+   directive        = [ qualifier ] mechanism
+   qualifier        = "+" / "-" / "?" / "~"
+   mechanism        = ( all / include
+                      / A / MX / PTR / IP4 / IP6 / exists )
+   modifier         = redirect / explanation / unknown-modifier
+   unknown-modifier = name "=" macro-string
+
+   name             = ALPHA *( ALPHA / DIGIT / "-" / "_" / "." )
+
+   Most mechanisms allow a ":" or "/" character after the name.
+
+
+
+Wong & Schlitt                Experimental                     [Page 14]
+
+RFC 4408             Sender Policy Framework (SPF)            April 2006
+
+
+   Modifiers always contain an equals ('=') character immediately after
+   the name, and before any ":" or "/" characters that may be part of
+   the macro-string.
+
+   Terms that do not contain any of "=", ":", or "/" are mechanisms, as
+   defined in Section 5.
+
+   As per the definition of the ABNF notation in [RFC4234], mechanism
+   and modifier names are case-insensitive.
+
+4.6.2.  Mechanisms
+
+   Each mechanism is considered in turn from left to right.  If there
+   are no more mechanisms, the result is specified in Section 4.7.
+
+   When a mechanism is evaluated, one of three things can happen: it can
+   match, not match, or throw an exception.
+
+   If it matches, processing ends and the qualifier value is returned as
+   the result of that record.  If it does not match, processing
+   continues with the next mechanism.  If it throws an exception,
+   mechanism processing ends and the exception value is returned.
+
+   The possible qualifiers, and the results they return are as follows:
+
+      "+" Pass
+      "-" Fail
+      "~" SoftFail
+      "?" Neutral
+
+   The qualifier is optional and defaults to "+".
+
+   When a mechanism matches and the qualifier is "-", then a "Fail"
+   result is returned and the explanation string is computed as
+   described in Section 6.2.
+
+   The specific mechanisms are described in Section 5.
+
+4.6.3.  Modifiers
+
+   Modifiers are not mechanisms: they do not return match or not-match.
+   Instead they provide additional information.  Although modifiers do
+   not directly affect the evaluation of the record, the "redirect"
+   modifier has an effect after all the mechanisms have been evaluated.
+
+
+
+
+
+
+
+Wong & Schlitt                Experimental                     [Page 15]
+
+RFC 4408             Sender Policy Framework (SPF)            April 2006
+
+
+4.7.  Default Result
+
+   If none of the mechanisms match and there is no "redirect" modifier,
+   then the check_host() returns a result of "Neutral", just as if
+   "?all" were specified as the last directive.  If there is a
+   "redirect" modifier, check_host() proceeds as defined in Section 6.1.
+
+   Note that records SHOULD always use either a "redirect" modifier or
+   an "all" mechanism to explicitly terminate processing.
+
+   For example:
+
+      v=spf1 +mx -all
+   or
+      v=spf1 +mx redirect=_spf.example.com
+
+4.8.  Domain Specification
+
+   Several of these mechanisms and modifiers have a <domain-spec>
+   section.  The <domain-spec> string is macro expanded (see Section 8).
+   The resulting string is the common presentation form of a fully-
+   qualified DNS name: a series of labels separated by periods.  This
+   domain is called the <target-name> in the rest of this document.
+
+   Note: The result of the macro expansion is not subject to any further
+   escaping.  Hence, this facility cannot produce all characters that
+   are legal in a DNS label (e.g., the control characters).  However,
+   this facility is powerful enough to express legal host names and
+   common utility labels (such as "_spf") that are used in DNS.
+
+   For several mechanisms, the <domain-spec> is optional.  If it is not
+   provided, the <domain> is used as the <target-name>.
+
+5.  Mechanism Definitions
+
+   This section defines two types of mechanisms.
+
+   Basic mechanisms contribute to the language framework.  They do not
+   specify a particular type of authorization scheme.
+
+      all
+      include
+
+   Designated sender mechanisms are used to designate a set of <ip>
+   addresses as being permitted or not permitted to use the <domain> for
+   sending mail.
+
+
+
+
+
+Wong & Schlitt                Experimental                     [Page 16]
+
+RFC 4408             Sender Policy Framework (SPF)            April 2006
+
+
+      a
+      mx
+      ptr
+      ip4
+      ip6
+      exists
+
+   The following conventions apply to all mechanisms that perform a
+   comparison between <ip> and an IP address at any point:
+
+   If no CIDR-length is given in the directive, then <ip> and the IP
+   address are compared for equality. (Here, CIDR is Classless Inter-
+   Domain Routing.)
+
+   If a CIDR-length is specified, then only the specified number of
+   high-order bits of <ip> and the IP address are compared for equality.
+
+   When any mechanism fetches host addresses to compare with <ip>, when
+   <ip> is an IPv4 address, A records are fetched, when <ip> is an IPv6
+   address, AAAA records are fetched.  Even if the SMTP connection is
+   via IPv6, an IPv4-mapped IPv6 IP address (see [RFC3513], Section
+   2.5.5) MUST still be considered an IPv4 address.
+
+   Several mechanisms rely on information fetched from DNS.  For these
+   DNS queries, except where noted, if the DNS server returns an error
+   (RCODE other than 0 or 3) or the query times out, the mechanism
+   throws the exception "TempError".  If the server returns "domain does
+   not exist" (RCODE 3), then evaluation of the mechanism continues as
+   if the server returned no error (RCODE 0) and zero answer records.
+
+5.1.  "all"
+
+   all              = "all"
+
+   The "all" mechanism is a test that always matches.  It is used as the
+   rightmost mechanism in a record to provide an explicit default.
+
+   For example:
+
+      v=spf1 a mx -all
+
+   Mechanisms after "all" will never be tested.  Any "redirect" modifier
+   (Section 6.1) has no effect when there is an "all" mechanism.
+
+
+
+
+
+
+
+
+Wong & Schlitt                Experimental                     [Page 17]
+
+RFC 4408             Sender Policy Framework (SPF)            April 2006
+
+
+5.2.  "include"
+
+      include          = "include"  ":" domain-spec
+
+   The "include" mechanism triggers a recursive evaluation of
+   check_host().  The domain-spec is expanded as per Section 8.  Then
+   check_host() is evaluated with the resulting string as the <domain>.
+   The <ip> and <sender> arguments remain the same as in the current
+   evaluation of check_host().
+
+   In hindsight, the name "include" was poorly chosen.  Only the
+   evaluated result of the referenced SPF record is used, rather than
+   acting as if the referenced SPF record was literally included in the
+   first.  For example, evaluating a "-all" directive in the referenced
+   record does not terminate the overall processing and does not
+   necessarily result in an overall "Fail".  (Better names for this
+   mechanism would have been "if-pass", "on-pass", etc.)
+
+   The "include" mechanism makes it possible for one domain to designate
+   multiple administratively-independent domains.  For example, a vanity
+   domain "example.net" might send mail using the servers of
+   administratively-independent domains example.com and example.org.
+
+   Example.net could say
+
+      IN TXT "v=spf1 include:example.com include:example.org -all"
+
+   This would direct check_host() to, in effect, check the records of
+   example.com and example.org for a "Pass" result.  Only if the host
+   were not permitted for either of those domains would the result be
+   "Fail".
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wong & Schlitt                Experimental                     [Page 18]
+
+RFC 4408             Sender Policy Framework (SPF)            April 2006
+
+
+   Whether this mechanism matches, does not match, or throws an
+   exception depends on the result of the recursive evaluation of
+   check_host():
+
+   +---------------------------------+---------------------------------+
+   | A recursive check_host() result | Causes the "include" mechanism  |
+   | of:                             | to:                             |
+   +---------------------------------+---------------------------------+
+   | Pass                            | match                           |
+   |                                 |                                 |
+   | Fail                            | not match                       |
+   |                                 |                                 |
+   | SoftFail                        | not match                       |
+   |                                 |                                 |
+   | Neutral                         | not match                       |
+   |                                 |                                 |
+   | TempError                       | throw TempError                 |
+   |                                 |                                 |
+   | PermError                       | throw PermError                 |
+   |                                 |                                 |
+   | None                            | throw PermError                 |
+   +---------------------------------+---------------------------------+
+
+   The "include" mechanism is intended for crossing administrative
+   boundaries.  Although it is possible to use includes to consolidate
+   multiple domains that share the same set of designated hosts, domains
+   are encouraged to use redirects where possible, and to minimize the
+   number of includes within a single administrative domain.  For
+   example, if example.com and example.org were managed by the same
+   entity, and if the permitted set of hosts for both domains was
+   "mx:example.com", it would be possible for example.org to specify
+   "include:example.com", but it would be preferable to specify
+   "redirect=example.com" or even "mx:example.com".
+
+5.3.  "a"
+
+   This mechanism matches if <ip> is one of the <target-name>'s IP
+   addresses.
+
+   A                = "a"      [ ":" domain-spec ] [ dual-cidr-length ]
+
+   An address lookup is done on the <target-name>.  The <ip> is compared
+   to the returned address(es).  If any address matches, the mechanism
+   matches.
+
+
+
+
+
+
+
+Wong & Schlitt                Experimental                     [Page 19]
+
+RFC 4408             Sender Policy Framework (SPF)            April 2006
+
+
+5.4.  "mx"
+
+   This mechanism matches if <ip> is one of the MX hosts for a domain
+   name.
+
+   MX               = "mx"     [ ":" domain-spec ] [ dual-cidr-length ]
+
+   check_host() first performs an MX lookup on the <target-name>.  Then
+   it performs an address lookup on each MX name returned.  The <ip> is
+   compared to each returned IP address.  To prevent Denial of Service
+   (DoS) attacks, more than 10 MX names MUST NOT be looked up during the
+   evaluation of an "mx" mechanism (see Section 10).  If any address
+   matches, the mechanism matches.
+
+   Note regarding implicit MXs: If the <target-name> has no MX records,
+   check_host() MUST NOT pretend the target is its single MX, and MUST
+   NOT default to an A lookup on the <target-name> directly.  This
+   behavior breaks with the legacy "implicit MX" rule.  See [RFC2821],
+   Section 5.  If such behavior is desired, the publisher should specify
+   an "a" directive.
+
+5.5.  "ptr"
+
+   This mechanism tests whether the DNS reverse-mapping for <ip> exists
+   and correctly points to a domain name within a particular domain.
+
+   PTR              = "ptr"    [ ":" domain-spec ]
+
+   First, the <ip>'s name is looked up using this procedure: perform a
+   DNS reverse-mapping for <ip>, looking up the corresponding PTR record
+   in "in-addr.arpa." if the address is an IPv4 one and in "ip6.arpa."
+   if it is an IPv6 address.  For each record returned, validate the
+   domain name by looking up its IP address.  To prevent DoS attacks,
+   more than 10 PTR names MUST NOT be looked up during the evaluation of
+   a "ptr" mechanism (see Section 10).  If <ip> is among the returned IP
+   addresses, then that domain name is validated.  In pseudocode:
+
+   sending-domain_names := ptr_lookup(sending-host_IP); if more than 10
+   sending-domain_names are found, use at most 10.  for each name in
+   (sending-domain_names) {
+     IP_addresses := a_lookup(name);
+     if the sending-domain_IP is one of the IP_addresses {
+       validated-sending-domain_names += name;
+     } }
+
+   Check all validated domain names to see if they end in the
+   <target-name> domain.  If any do, this mechanism matches.  If no
+   validated domain name can be found, or if none of the validated
+
+
+
+Wong & Schlitt                Experimental                     [Page 20]
+
+RFC 4408             Sender Policy Framework (SPF)            April 2006
+
+
+   domain names end in the <target-name>, this mechanism fails to match.
+   If a DNS error occurs while doing the PTR RR lookup, then this
+   mechanism fails to match.  If a DNS error occurs while doing an A RR
+   lookup, then that domain name is skipped and the search continues.
+
+   Pseudocode:
+
+   for each name in (validated-sending-domain_names) {
+     if name ends in <domain-spec>, return match.
+     if name is <domain-spec>, return match.
+   }
+   return no-match.
+
+   This mechanism matches if the <target-name> is either an ancestor of
+   a validated domain name or if the <target-name> and a validated
+   domain name are the same.  For example: "mail.example.com" is within
+   the domain "example.com", but "mail.bad-example.com" is not.
+
+   Note: Use of this mechanism is discouraged because it is slow, it is
+   not as reliable as other mechanisms in cases of DNS errors, and it
+   places a large burden on the arpa name servers.  If used, proper PTR
+   records must be in place for the domain's hosts and the "ptr"
+   mechanism should be one of the last mechanisms checked.
+
+5.6.  "ip4" and "ip6"
+
+   These mechanisms test whether <ip> is contained within a given IP
+   network.
+
+   IP4              = "ip4"      ":" ip4-network   [ ip4-cidr-length ]
+   IP6              = "ip6"      ":" ip6-network   [ ip6-cidr-length ]
+
+   ip4-cidr-length  = "/" 1*DIGIT
+   ip6-cidr-length  = "/" 1*DIGIT
+   dual-cidr-length = [ ip4-cidr-length ] [ "/" ip6-cidr-length ]
+
+   ip4-network      = qnum "." qnum "." qnum "." qnum
+   qnum             = DIGIT                 ; 0-9
+                      / %x31-39 DIGIT       ; 10-99
+                      / "1" 2DIGIT          ; 100-199
+                      / "2" %x30-34 DIGIT   ; 200-249
+                      / "25" %x30-35        ; 250-255
+            ; as per conventional dotted quad notation.  e.g., 192.0.2.0
+   ip6-network      = <as per [RFC 3513], section 2.2>
+            ; e.g., 2001:DB8::CD30
+
+   The <ip> is compared to the given network.  If CIDR-length high-order
+   bits match, the mechanism matches.
+
+
+
+Wong & Schlitt                Experimental                     [Page 21]
+
+RFC 4408             Sender Policy Framework (SPF)            April 2006
+
+
+   If ip4-cidr-length is omitted, it is taken to be "/32".  If
+   ip6-cidr-length is omitted, it is taken to be "/128".  It is not
+   permitted to omit parts of the IP address instead of using CIDR
+   notations.  That is, use 192.0.2.0/24 instead of 192.0.2.
+
+5.7.  "exists"
+
+   This mechanism is used to construct an arbitrary domain name that is
+   used for a DNS A record query.  It allows for complicated schemes
+   involving arbitrary parts of the mail envelope to determine what is
+   permitted.
+
+   exists           = "exists"   ":" domain-spec
+
+   The domain-spec is expanded as per Section 8.  The resulting domain
+   name is used for a DNS A RR lookup.  If any A record is returned,
+   this mechanism matches.  The lookup type is A even when the
+   connection type is IPv6.
+
+   Domains can use this mechanism to specify arbitrarily complex
+   queries.  For example, suppose example.com publishes the record:
+
+      v=spf1 exists:%{ir}.%{l1r+-}._spf.%{d} -all
+
+   The <target-name> might expand to
+   "1.2.0.192.someuser._spf.example.com".  This makes fine-grained
+   decisions possible at the level of the user and client IP address.
+
+   This mechanism enables queries that mimic the style of tests that
+   existing anti-spam DNS blacklists (DNSBL) use.
+
+6.  Modifier Definitions
+
+   Modifiers are name/value pairs that provide additional information.
+   Modifiers always have an "=" separating the name and the value.
+
+   The modifiers defined in this document ("redirect" and "exp") MAY
+   appear anywhere in the record, but SHOULD appear at the end, after
+   all mechanisms.  Ordering of these two modifiers does not matter.
+   These two modifiers MUST NOT appear in a record more than once each.
+   If they do, then check_host() exits with a result of "PermError".
+
+   Unrecognized modifiers MUST be ignored no matter where in a record,
+   or how often.  This allows implementations of this document to
+   gracefully handle records with modifiers that are defined in other
+   specifications.
+
+
+
+
+
+Wong & Schlitt                Experimental                     [Page 22]
+
+RFC 4408             Sender Policy Framework (SPF)            April 2006
+
+
+6.1.  redirect: Redirected Query
+
+   If all mechanisms fail to match, and a "redirect" modifier is
+   present, then processing proceeds as follows:
+
+   redirect         = "redirect" "=" domain-spec
+
+   The domain-spec portion of the redirect section is expanded as per
+   the macro rules in Section 8.  Then check_host() is evaluated with
+   the resulting string as the <domain>.  The <ip> and <sender>
+   arguments remain the same as current evaluation of check_host().
+
+   The result of this new evaluation of check_host() is then considered
+   the result of the current evaluation with the exception that if no
+   SPF record is found, or if the target-name is malformed, the result
+   is a "PermError" rather than "None".
+
+   Note that the newly-queried domain may itself specify redirect
+   processing.
+
+   This facility is intended for use by organizations that wish to apply
+   the same record to multiple domains.  For example:
+
+     la.example.com. TXT "v=spf1 redirect=_spf.example.com"
+     ny.example.com. TXT "v=spf1 redirect=_spf.example.com"
+     sf.example.com. TXT "v=spf1 redirect=_spf.example.com"
+   _spf.example.com. TXT "v=spf1 mx:example.com -all"
+
+   In this example, mail from any of the three domains is described by
+   the same record.  This can be an administrative advantage.
+
+   Note: In general, the domain "A" cannot reliably use a redirect to
+   another domain "B" not under the same administrative control.  Since
+   the <sender> stays the same, there is no guarantee that the record at
+   domain "B" will correctly work for mailboxes in domain "A",
+   especially if domain "B" uses mechanisms involving localparts.  An
+   "include" directive may be more appropriate.
+
+   For clarity, it is RECOMMENDED that any "redirect" modifier appear as
+   the very last term in a record.
+
+6.2.  exp: Explanation
+
+   explanation      = "exp" "=" domain-spec
+
+   If check_host() results in a "Fail" due to a mechanism match (such as
+   "-all"), and the "exp" modifier is present, then the explanation
+   string returned is computed as described below.  If no "exp" modifier
+
+
+
+Wong & Schlitt                Experimental                     [Page 23]
+
+RFC 4408             Sender Policy Framework (SPF)            April 2006
+
+
+   is present, then either a default explanation string or an empty
+   explanation string may be returned.
+
+   The <domain-spec> is macro expanded (see Section 8) and becomes the
+   <target-name>.  The DNS TXT record for the <target-name> is fetched.
+
+   If <domain-spec> is empty, or there are any DNS processing errors
+   (any RCODE other than 0), or if no records are returned, or if more
+   than one record is returned, or if there are syntax errors in the
+   explanation string, then proceed as if no exp modifier was given.
+
+   The fetched TXT record's strings are concatenated with no spaces, and
+   then treated as an <explain-string>, which is macro-expanded.  This
+   final result is the explanation string.  Implementations MAY limit
+   the length of the resulting explanation string to allow for other
+   protocol constraints and/or reasonable processing limits.  Since the
+   explanation string is intended for an SMTP response and [RFC2821]
+   Section 2.4 says that responses are in [US-ASCII], the explanation
+   string is also limited to US-ASCII.
+
+   Software evaluating check_host() can use this string to communicate
+   information from the publishing domain in the form of a short message
+   or URL.  Software SHOULD make it clear that the explanation string
+   comes from a third party.  For example, it can prepend the macro
+   string "%{o} explains: " to the explanation, such as shown in Section
+   2.5.4.
+
+   Suppose example.com has this record:
+
+      v=spf1 mx -all exp=explain._spf.%{d}
+
+   Here are some examples of possible explanation TXT records at
+   explain._spf.example.com:
+
+      "Mail from example.com should only be sent by its own servers."
+         -- a simple, constant message
+
+      "%{i} is not one of %{d}'s designated mail servers."
+         -- a message with a little more information, including the IP
+            address that failed the check
+
+      "See http://%{d}/why.html?s=%{S}&i=%{I}"
+         -- a complicated example that constructs a URL with the
+            arguments to check_host() so that a web page can be
+            generated with detailed, custom instructions
+
+   Note: During recursion into an "include" mechanism, an exp= modifier
+   from the <target-name> MUST NOT be used.  In contrast, when executing
+
+
+
+Wong & Schlitt                Experimental                     [Page 24]
+
+RFC 4408             Sender Policy Framework (SPF)            April 2006
+
+
+   a "redirect" modifier, an exp= modifier from the original domain MUST
+   NOT be used.
+
+7.  The Received-SPF Header Field
+
+   It is RECOMMENDED that SMTP receivers record the result of SPF
+   processing in the message header.  If an SMTP receiver chooses to do
+   so, it SHOULD use the "Received-SPF" header field defined here for
+   each identity that was checked.  This information is intended for the
+   recipient.  (Information intended for the sender is described in
+   Section 6.2, Explanation.)
+
+   The Received-SPF header field is a trace field (see [RFC2822] Section
+   3.6.7) and SHOULD be prepended to the existing header, above the
+   Received: field that is generated by the SMTP receiver.  It MUST
+   appear above all other Received-SPF fields in the message.  The
+   header field has the following format:
+
+   header-field     = "Received-SPF:" [CFWS] result FWS [comment FWS]
+                      [ key-value-list ] CRLF
+
+   result           = "Pass" / "Fail" / "SoftFail" / "Neutral" /
+                      "None" / "TempError" / "PermError"
+
+   key-value-list   = key-value-pair *( ";" [CFWS] key-value-pair )
+                      [";"]
+
+   key-value-pair   = key [CFWS] "=" ( dot-atom / quoted-string )
+
+   key              = "client-ip" / "envelope-from" / "helo" /
+                      "problem" / "receiver" / "identity" /
+                       mechanism / "x-" name / name
+
+   identity         = "mailfrom"   ; for the "MAIL FROM" identity
+                      / "helo"     ; for the "HELO" identity
+                      / name       ; other identities
+
+   dot-atom         = <unquoted word as per [RFC2822]>
+   quoted-string    = <quoted string as per [RFC2822]>
+   comment          = <comment string as per [RFC2822]>
+   CFWS             = <comment or folding white space as per [RFC2822]>
+   FWS              = <folding white space as per [RFC2822]>
+   CRLF             = <standard end-of-line token as per [RFC2822]>
+
+   The header field SHOULD include a "(...)" style <comment> after the
+   result, conveying supporting information for the result, such as
+   <ip>, <sender>, and <domain>.
+
+
+
+
+Wong & Schlitt                Experimental                     [Page 25]
+
+RFC 4408             Sender Policy Framework (SPF)            April 2006
+
+
+   The following key-value pairs are designed for later machine parsing.
+   SPF clients SHOULD give enough information so that the SPF results
+   can be verified.  That is, at least "client-ip", "helo", and, if the
+   "MAIL FROM" identity was checked, "envelope-from".
+
+   client-ip      the IP address of the SMTP client
+
+   envelope-from  the envelope sender mailbox
+
+   helo           the host name given in the HELO or EHLO command
+
+   mechanism      the mechanism that matched (if no mechanisms matched,
+                  substitute the word "default")
+
+   problem        if an error was returned, details about the error
+
+   receiver       the host name of the SPF client
+
+   identity       the identity that was checked; see the <identity> ABNF
+                  rule
+
+   Other keys may be defined by SPF clients.  Until a new key name
+   becomes widely accepted, new key names should start with "x-".
+
+   SPF clients MUST make sure that the Received-SPF header field does
+   not contain invalid characters, is not excessively long, and does not
+   contain malicious data that has been provided by the sender.
+
+   Examples of various header styles that could be generated are the
+   following:
+
+   Received-SPF: Pass (mybox.example.org: domain of
+    myname@example.com designates 192.0.2.1 as permitted sender)
+       receiver=mybox.example.org; client-ip=192.0.2.1;
+       envelope-from=<myname@example.com>; helo=foo.example.com;
+
+   Received-SPF: Fail (mybox.example.org: domain of
+                     myname@example.com does not designate
+                     192.0.2.1 as permitted sender)
+                     identity=mailfrom; client-ip=192.0.2.1;
+                     envelope-from=<myname@example.com>;
+
+
+
+
+
+
+
+
+
+
+Wong & Schlitt                Experimental                     [Page 26]
+
+RFC 4408             Sender Policy Framework (SPF)            April 2006
+
+
+8.  Macros
+
+8.1.  Macro Definitions
+
+   Many mechanisms and modifiers perform macro expansion on part of the
+   term.
+
+   domain-spec      = macro-string domain-end
+   domain-end       = ( "." toplabel [ "." ] ) / macro-expand
+
+   toplabel         = ( *alphanum ALPHA *alphanum ) /
+                      ( 1*alphanum "-" *( alphanum / "-" ) alphanum )
+                      ; LDH rule plus additional TLD restrictions
+                      ; (see [RFC3696], Section 2)
+   alphanum         = ALPHA / DIGIT
+
+   explain-string   = *( macro-string / SP )
+
+   macro-string     = *( macro-expand / macro-literal )
+   macro-expand     = ( "%{" macro-letter transformers *delimiter "}" )
+                      / "%%" / "%_" / "%-"
+   macro-literal    = %x21-24 / %x26-7E
+                      ; visible characters except "%"
+   macro-letter     = "s" / "l" / "o" / "d" / "i" / "p" / "h" /
+                      "c" / "r" / "t"
+   transformers     = *DIGIT [ "r" ]
+   delimiter        = "." / "-" / "+" / "," / "/" / "_" / "="
+
+   A literal "%" is expressed by "%%".
+
+      "%_" expands to a single " " space.
+      "%-" expands to a URL-encoded space, viz., "%20".
+
+   The following macro letters are expanded in term arguments:
+
+      s = <sender>
+      l = local-part of <sender>
+      o = domain of <sender>
+      d = <domain>
+      i = <ip>
+      p = the validated domain name of <ip>
+      v = the string "in-addr" if <ip> is ipv4, or "ip6" if <ip> is ipv6
+      h = HELO/EHLO domain
+
+
+
+
+
+
+
+
+Wong & Schlitt                Experimental                     [Page 27]
+
+RFC 4408             Sender Policy Framework (SPF)            April 2006
+
+
+   The following macro letters are allowed only in "exp" text:
+
+      c = SMTP client IP (easily readable format)
+      r = domain name of host performing the check
+      t = current timestamp
+
+   A '%' character not followed by a '{', '%', '-', or '_' character is
+   a syntax error.  So
+
+      -exists:%(ir).sbl.spamhaus.example.org
+
+   is incorrect and will cause check_host() to return a "PermError".
+   Instead, say
+
+      -exists:%{ir}.sbl.spamhaus.example.org
+
+   Optional transformers are the following:
+
+      *DIGIT = zero or more digits
+      'r'    = reverse value, splitting on dots by default
+
+   If transformers or delimiters are provided, the replacement value for
+   a macro letter is split into parts.  After performing any reversal
+   operation and/or removal of left-hand parts, the parts are rejoined
+   using "." and not the original splitting characters.
+
+   By default, strings are split on "." (dots).  Note that no special
+   treatment is given to leading, trailing, or consecutive delimiters,
+   and so the list of parts may contain empty strings.  Older
+   implementations of SPF prohibit trailing dots in domain names, so
+   trailing dots should not be published by domain owners, although they
+   must be accepted by implementations conforming to this document.
+   Macros may specify delimiter characters that are used instead of ".".
+
+   The 'r' transformer indicates a reversal operation: if the client IP
+   address were 192.0.2.1, the macro %{i} would expand to "192.0.2.1"
+   and the macro %{ir} would expand to "1.2.0.192".
+
+   The DIGIT transformer indicates the number of right-hand parts to
+   use, after optional reversal.  If a DIGIT is specified, the value
+   MUST be nonzero.  If no DIGITs are specified, or if the value
+   specifies more parts than are available, all the available parts are
+   used.  If the DIGIT was 5, and only 3 parts were available, the macro
+   interpreter would pretend the DIGIT was 3.  Implementations MUST
+   support at least a value of 128, as that is the maximum number of
+   labels in a domain name.
+
+
+
+
+
+Wong & Schlitt                Experimental                     [Page 28]
+
+RFC 4408             Sender Policy Framework (SPF)            April 2006
+
+
+   The "s" macro expands to the <sender> argument.  It is an E-Mail
+   address with a localpart, an "@" character, and a domain.  The "l"
+   macro expands to just the localpart.  The "o" macro expands to just
+   the domain part.  Note that these values remain the same during
+   recursive and chained evaluations due to "include" and/or "redirect".
+   Note also that if the original <sender> had no localpart, the
+   localpart was set to "postmaster" in initial processing (see Section
+   4.3).
+
+   For IPv4 addresses, both the "i" and "c" macros expand to the
+   standard dotted-quad format.
+
+   For IPv6 addresses, the "i" macro expands to a dot-format address; it
+   is intended for use in %{ir}.  The "c" macro may expand to any of the
+   hexadecimal colon-format addresses specified in [RFC3513], Section
+   2.2.  It is intended for humans to read.
+
+   The "p" macro expands to the validated domain name of <ip>.  The
+   procedure for finding the validated domain name is defined in Section
+   5.5.  If the <domain> is present in the list of validated domains, it
+   SHOULD be used.  Otherwise, if a subdomain of the <domain> is
+   present, it SHOULD be used.  Otherwise, any name from the list may be
+   used.  If there are no validated domain names or if a DNS error
+   occurs, the string "unknown" is used.
+
+   The "r" macro expands to the name of the receiving MTA.  This SHOULD
+   be a fully qualified domain name, but if one does not exist (as when
+   the checking is done by a MUA) or if policy restrictions dictate
+   otherwise, the word "unknown" SHOULD be substituted.  The domain name
+   may be different from the name found in the MX record that the client
+   MTA used to locate the receiving MTA.
+
+   The "t" macro expands to the decimal representation of the
+   approximate number of seconds since the Epoch (Midnight, January 1,
+   1970, UTC).  This is the same value as is returned by the POSIX
+   time() function in most standards-compliant libraries.
+
+   When the result of macro expansion is used in a domain name query, if
+   the expanded domain name exceeds 253 characters (the maximum length
+   of a domain name), the left side is truncated to fit, by removing
+   successive domain labels until the total length does not exceed 253
+   characters.
+
+   Uppercased macros expand exactly as their lowercased equivalents, and
+   are then URL escaped.  URL escaping must be performed for characters
+   not in the "uric" set, which is defined in [RFC3986].
+
+
+
+
+
+Wong & Schlitt                Experimental                     [Page 29]
+
+RFC 4408             Sender Policy Framework (SPF)            April 2006
+
+
+   Note: Care must be taken so that macro expansion for legitimate
+   E-Mail does not exceed the 63-character limit on DNS labels.  The
+   localpart of E-Mail addresses, in particular, can have more than 63
+   characters between dots.
+
+   Note: Domains should avoid using the "s", "l", "o", or "h" macros in
+   conjunction with any mechanism directive.  Although these macros are
+   powerful and allow per-user records to be published, they severely
+   limit the ability of implementations to cache results of check_host()
+   and they reduce the effectiveness of DNS caches.
+
+   Implementations should be aware that if no directive processed during
+   the evaluation of check_host() contains an "s", "l", "o", or "h"
+   macro, then the results of the evaluation can be cached on the basis
+   of <domain> and <ip> alone for as long as the shortest Time To Live
+   (TTL) of all the DNS records involved.
+
+8.2.  Expansion Examples
+
+      The <sender> is strong-bad@email.example.com.
+      The IPv4 SMTP client IP is 192.0.2.3.
+      The IPv6 SMTP client IP is 2001:DB8::CB01.
+      The PTR domain name of the client IP is mx.example.org.
+
+   macro                       expansion
+   -------  ----------------------------
+   %{s}     strong-bad@email.example.com
+   %{o}                email.example.com
+   %{d}                email.example.com
+   %{d4}               email.example.com
+   %{d3}               email.example.com
+   %{d2}                     example.com
+   %{d1}                             com
+   %{dr}               com.example.email
+   %{d2r}                  example.email
+   %{l}                       strong-bad
+   %{l-}                      strong.bad
+   %{lr}                      strong-bad
+   %{lr-}                     bad.strong
+   %{l1r-}                        strong
+
+
+
+
+
+
+
+
+
+
+
+Wong & Schlitt                Experimental                     [Page 30]
+
+RFC 4408             Sender Policy Framework (SPF)            April 2006
+
+
+   macro-string                                               expansion
+   --------------------------------------------------------------------
+   %{ir}.%{v}._spf.%{d2}             3.2.0.192.in-addr._spf.example.com
+   %{lr-}.lp._spf.%{d2}                  bad.strong.lp._spf.example.com
+
+   %{lr-}.lp.%{ir}.%{v}._spf.%{d2}
+                       bad.strong.lp.3.2.0.192.in-addr._spf.example.com
+
+   %{ir}.%{v}.%{l1r-}.lp._spf.%{d2}
+                           3.2.0.192.in-addr.strong.lp._spf.example.com
+
+   %{d2}.trusted-domains.example.net
+                                example.com.trusted-domains.example.net
+
+   IPv6:
+   %{ir}.%{v}._spf.%{d2}                               1.0.B.C.0.0.0.0.
+   0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.B.D.0.1.0.0.2.ip6._spf.example.com
+
+9.  Implications
+
+   This section outlines the major implications that adoption of this
+   document will have on various entities involved in Internet E-Mail.
+   It is intended to make clear to the reader where this document
+   knowingly affects the operation of such entities.  This section is
+   not a "how-to" manual, or a "best practices" document, and it is not
+   a comprehensive list of what such entities should do in light of this
+   document.
+
+   This section is non-normative.
+
+9.1.  Sending Domains
+
+   Domains that wish to be compliant with this specification will need
+   to determine the list of hosts that they allow to use their domain
+   name in the "HELO" and "MAIL FROM" identities.  It is recognized that
+   forming such a list is not just a simple technical exercise, but
+   involves policy decisions with both technical and administrative
+   considerations.
+
+   It can be helpful to publish records that include a "tracking
+   exists:" mechanism.  By looking at the name server logs, a rough list
+   may then be generated.  For example:
+
+      v=spf1 exists:_h.%{h}._l.%{l}._o.%{o}._i.%{i}._spf.%{d} ?all
+
+
+
+
+
+
+
+Wong & Schlitt                Experimental                     [Page 31]
+
+RFC 4408             Sender Policy Framework (SPF)            April 2006
+
+
+9.2.  Mailing Lists
+
+   Mailing lists must be aware of how they re-inject mail that is sent
+   to the list.  Mailing lists MUST comply with the requirements in
+   [RFC2821], Section 3.10, and [RFC1123], Section 5.3.6, that say that
+   the reverse-path MUST be changed to be the mailbox of a person or
+   other entity who administers the list.  Whereas the reasons for
+   changing the reverse-path are many and long-standing, SPF adds
+   enforcement to this requirement.
+
+   In practice, almost all mailing list software in use already complies
+   with this requirement.  Mailing lists that do not comply may or may
+   not encounter problems depending on how access to the list is
+   restricted.  Such lists that are entirely internal to a domain (only
+   people in the domain can send to or receive from the list) are not
+   affected.
+
+9.3.  Forwarding Services and Aliases
+
+   Forwarding services take mail that is received at a mailbox and
+   direct it to some external mailbox.  At the time of this writing, the
+   near-universal practice of such services is to use the original "MAIL
+   FROM" of a message when re-injecting it for delivery to the external
+   mailbox.  [RFC1123] and [RFC2821] describe this action as an "alias"
+   rather than a "mail list".  This means that the external mailbox's
+   MTA sees all such mail in a connection from a host of the forwarding
+   service, and so the "MAIL FROM" identity will not, in general, pass
+   authorization.
+
+   There are three places that techniques can be used to ameliorate this
+   problem.
+
+   1. The beginning, when E-Mail is first sent.
+
+       1. "Neutral" results could be given for IP addresses that may be
+          forwarders, instead of "Fail" results.  For example:
+
+             "v=spf1 mx -exists:%{ir}.sbl.spamhaus.example.org ?all"
+
+          This would cause a lookup on an anti-spam DNS blacklist
+          (DNSBL) and cause a result of "Fail" only for E-Mail coming
+          from listed sources.  All other E-Mail, including E-Mail sent
+          through forwarders, would receive a "Neutral" result.  By
+          checking the DNSBL after the known good sources, problems with
+          incorrect listing on the DNSBL are greatly reduced.
+
+
+
+
+
+
+Wong & Schlitt                Experimental                     [Page 32]
+
+RFC 4408             Sender Policy Framework (SPF)            April 2006
+
+
+       2. The "MAIL FROM" identity could have additional information in
+          the localpart that cryptographically identifies the mail as
+          coming from an authorized source.  In this case, such an SPF
+          record could be used:
+
+             "v=spf1 mx exists:%{l}._spf_verify.%{d} -all"
+
+          Then, a specialized DNS server can be set up to serve the
+          _spf_verify subdomain that validates the localpart.  Although
+          this requires an extra DNS lookup, this happens only when the
+          E-Mail would otherwise be rejected as not coming from a known
+          good source.
+
+          Note that due to the 63-character limit for domain labels,
+          this approach only works reliably if the localpart signature
+          scheme is guaranteed either to only produce localparts with a
+          maximum of 63 characters or to gracefully handle truncated
+          localparts.
+
+       3. Similarly, a specialized DNS server could be set up that will
+          rate-limit the E-Mail coming from unexpected IP addresses.
+
+             "v=spf1 mx exists:%{ir}._spf_rate.%{d} -all"
+
+       4. SPF allows the creation of per-user policies for special
+          cases.  For example, the following SPF record and appropriate
+          wildcard DNS records can be used:
+
+                 "v=spf1 mx redirect=%{l1r+}._at_.%{o}._spf.%{d}"
+
+   2.  The middle, when E-Mail is forwarded.
+
+       1. Forwarding services can solve the problem by rewriting the
+          "MAIL FROM" to be in their own domain.  This means that mail
+          bounced from the external mailbox will have to be re-bounced
+          by the forwarding service.  Various schemes to do this exist
+          though they vary widely in complexity and resource
+          requirements on the part of the forwarding service.
+
+       2. Several popular MTAs can be forced from "alias" semantics to
+          "mailing list" semantics by configuring an additional alias
+          with "owner-" prepended to the original alias name (e.g., an
+          alias of "friends: george@example.com, fred@example.org" would
+          need another alias of the form "owner-friends:  localowner").
+
+
+
+
+
+
+
+Wong & Schlitt                Experimental                     [Page 33]
+
+RFC 4408             Sender Policy Framework (SPF)            April 2006
+
+
+   3. The end, when E-Mail is received.
+
+       1. If the owner of the external mailbox wishes to trust the
+          forwarding service, he can direct the external mailbox's MTA
+          to skip SPF tests when the client host belongs to the
+          forwarding service.
+
+       2. Tests against other identities, such as the "HELO" identity,
+          may be used to override a failed test against the "MAIL FROM"
+          identity.
+
+       3. For larger domains, it may not be possible to have a complete
+          or accurate list of forwarding services used by the owners of
+          the domain's mailboxes.  In such cases, whitelists of
+          generally-recognized forwarding services could be employed.
+
+9.4.  Mail Services
+
+   Service providers that offer mail services to third-party domains,
+   such as sending of bulk mail, may want to adjust their setup in light
+   of the authorization check described in this document.  If the "MAIL
+   FROM" identity used for such E-Mail uses the domain of the service
+   provider, then the provider needs only to ensure that its sending
+   host is authorized by its own SPF record, if any.
+
+   If the "MAIL FROM" identity does not use the mail service provider's
+   domain, then extra care must be taken.  The SPF record format has
+   several options for the third-party domain to authorize the service
+   provider's MTAs to send mail on its behalf.  For mail service
+   providers, such as ISPs, that have a wide variety of customers using
+   the same MTA, steps should be taken to prevent cross-customer forgery
+   (see Section 10.4).
+
+9.5.  MTA Relays
+
+   The authorization check generally precludes the use of arbitrary MTA
+   relays between sender and receiver of an E-Mail message.
+
+   Within an organization, MTA relays can be effectively deployed.
+   However, for purposes of this document, such relays are effectively
+   transparent.  The SPF authorization check is a check between border
+   MTAs of different domains.
+
+   For mail senders, this means that published SPF records must
+   authorize any MTAs that actually send across the Internet.  Usually,
+   these are just the border MTAs as internal MTAs simply forward mail
+   to these MTAs for delivery.
+
+
+
+
+Wong & Schlitt                Experimental                     [Page 34]
+
+RFC 4408             Sender Policy Framework (SPF)            April 2006
+
+
+   Mail receivers will generally want to perform the authorization check
+   at the border MTAs, specifically including all secondary MXs.  This
+   allows mail that fails to be rejected during the SMTP session rather
+   than bounced.  Internal MTAs then do not perform the authorization
+   test.  To perform the authorization test other than at the border,
+   the host that first transferred the message to the organization must
+   be determined, which can be difficult to extract from the message
+   header.  Testing other than at the border is not recommended.
+
+10.  Security Considerations
+
+10.1.  Processing Limits
+
+   As with most aspects of E-Mail, there are a number of ways that
+   malicious parties could use the protocol as an avenue for a
+   Denial-of-Service (DoS) attack.  The processing limits outlined here
+   are designed to prevent attacks such as the following:
+
+   o  A malicious party could create an SPF record with many references
+      to a victim's domain and send many E-Mails to different SPF
+      clients; those SPF clients would then create a DoS attack.  In
+      effect, the SPF clients are being used to amplify the attacker's
+      bandwidth by using fewer bytes in the SMTP session than are used
+      by the DNS queries.  Using SPF clients also allows the attacker to
+      hide the true source of the attack.
+
+   o  Whereas implementations of check_host() are supposed to limit the
+      number of DNS lookups, malicious domains could publish records
+      that exceed these limits in an attempt to waste computation effort
+      at their targets when they send them mail.  Malicious domains
+      could also design SPF records that cause particular
+      implementations to use excessive memory or CPU usage, or to
+      trigger bugs.
+
+   o  Malicious parties could send a large volume of mail purporting to
+      come from the intended target to a wide variety of legitimate mail
+      hosts.  These legitimate machines would then present a DNS load on
+      the target as they fetched the relevant records.
+
+   Of these, the case of a third party referenced in the SPF record is
+   the easiest for a DoS attack to effectively exploit.  As a result,
+   limits that may seem reasonable for an individual mail server can
+   still allow an unreasonable amount of bandwidth amplification.
+   Therefore, the processing limits need to be quite low.
+
+   SPF implementations MUST limit the number of mechanisms and modifiers
+   that do DNS lookups to at most 10 per SPF check, including any
+   lookups caused by the use of the "include" mechanism or the
+
+
+
+Wong & Schlitt                Experimental                     [Page 35]
+
+RFC 4408             Sender Policy Framework (SPF)            April 2006
+
+
+   "redirect" modifier.  If this number is exceeded during a check, a
+   PermError MUST be returned.  The "include", "a", "mx", "ptr", and
+   "exists" mechanisms as well as the "redirect" modifier do count
+   against this limit.  The "all", "ip4", and "ip6" mechanisms do not
+   require DNS lookups and therefore do not count against this limit.
+   The "exp" modifier does not count against this limit because the DNS
+   lookup to fetch the explanation string occurs after the SPF record
+   has been evaluated.
+
+   When evaluating the "mx" and "ptr" mechanisms, or the %{p} macro,
+   there MUST be a limit of no more than 10 MX or PTR RRs looked up and
+   checked.
+
+   SPF implementations SHOULD limit the total amount of data obtained
+   from the DNS queries.  For example, when DNS over TCP or EDNS0 are
+   available, there may need to be an explicit limit to how much data
+   will be accepted to prevent excessive bandwidth usage or memory usage
+   and DoS attacks.
+
+   MTAs or other processors MAY also impose a limit on the maximum
+   amount of elapsed time to evaluate check_host().  Such a limit SHOULD
+   allow at least 20 seconds.  If such a limit is exceeded, the result
+   of authorization SHOULD be "TempError".
+
+   Domains publishing records SHOULD try to keep the number of "include"
+   mechanisms and chained "redirect" modifiers to a minimum.  Domains
+   SHOULD also try to minimize the amount of other DNS information
+   needed to evaluate a record.  This can be done by choosing directives
+   that require less DNS information and placing lower-cost mechanisms
+   earlier in the SPF record.
+
+   For example, consider a domain set up as follows:
+
+   example.com.      IN MX   10 mx.example.com.
+   mx.example.com.   IN A    192.0.2.1
+   a.example.com.    IN TXT  "v=spf1 mx:example.com -all"
+   b.example.com.    IN TXT  "v=spf1 a:mx.example.com -all"
+   c.example.com.    IN TXT  "v=spf1 ip4:192.0.2.1 -all"
+
+   Evaluating check_host() for the domain "a.example.com" requires the
+   MX records for "example.com", and then the A records for the listed
+   hosts.  Evaluating for "b.example.com" requires only the A records.
+   Evaluating for "c.example.com" requires none.
+
+   However, there may be administrative considerations: using "a" over
+   "ip4" allows hosts to be renumbered easily.  Using "mx" over "a"
+   allows the set of mail hosts to be changed easily.
+
+
+
+
+Wong & Schlitt                Experimental                     [Page 36]
+
+RFC 4408             Sender Policy Framework (SPF)            April 2006
+
+
+10.2.  SPF-Authorized E-Mail May Contain Other False Identities
+
+   The "MAIL FROM" and "HELO" identity authorizations must not be
+   construed to provide more assurance than they do.  It is entirely
+   possible for a malicious sender to inject a message using his own
+   domain in the identities used by SPF, to have that domain's SPF
+   record authorize the sending host, and yet the message can easily
+   list other identities in its header.  Unless the user or the MUA
+   takes care to note that the authorized identity does not match the
+   other more commonly-presented identities (such as the From:  header
+   field), the user may be lulled into a false sense of security.
+
+10.3.  Spoofed DNS and IP Data
+
+   There are two aspects of this protocol that malicious parties could
+   exploit to undermine the validity of the check_host() function:
+
+   o  The evaluation of check_host() relies heavily on DNS.  A malicious
+      attacker could attack the DNS infrastructure and cause
+      check_host() to see spoofed DNS data, and then return incorrect
+      results.  This could include returning "Pass" for an <ip> value
+      where the actual domain's record would evaluate to "Fail".  See
+      [RFC3833] for a description of DNS weaknesses.
+
+   o  The client IP address, <ip>, is assumed to be correct.  A
+      malicious attacker could spoof TCP sequence numbers to make mail
+      appear to come from a permitted host for a domain that the
+      attacker is impersonating.
+
+10.4.  Cross-User Forgery
+
+   By definition, SPF policies just map domain names to sets of
+   authorized MTAs, not whole E-Mail addresses to sets of authorized
+   users.  Although the "l" macro (Section 8) provides a limited way to
+   define individual sets of authorized MTAs for specific E-Mail
+   addresses, it is generally impossible to verify, through SPF, the use
+   of specific E-Mail addresses by individual users of the same MTA.
+
+   It is up to mail services and their MTAs to directly prevent
+   cross-user forgery: based on SMTP AUTH ([RFC2554]), users should be
+   restricted to using only those E-Mail addresses that are actually
+   under their control (see [RFC4409], Section 6.1).  Another means to
+   verify the identity of individual users is message cryptography such
+   as PGP ([RFC2440]) or S/MIME ([RFC3851]).
+
+
+
+
+
+
+
+Wong & Schlitt                Experimental                     [Page 37]
+
+RFC 4408             Sender Policy Framework (SPF)            April 2006
+
+
+10.5.  Untrusted Information Sources
+
+   SPF uses information supplied by third parties, such as the "HELO"
+   domain name, the "MAIL FROM" address, and SPF records.  This
+   information is then passed to the receiver in the Received-SPF: trace
+   fields and possibly returned to the client MTA in the form of an SMTP
+   rejection message.  This information must be checked for invalid
+   characters and excessively long lines.
+
+   When the authorization check fails, an explanation string may be
+   included in the reject response.  Both the sender and the rejecting
+   receiver need to be aware that the explanation was determined by the
+   publisher of the SPF record checked and, in general, not the
+   receiver.  The explanation may contain malicious URLs, or it may be
+   offensive or misleading.
+
+   This is probably less of a concern than it may initially seem since
+   such messages are returned to the sender, and the explanation strings
+   come from the sender policy published by the domain in the identity
+   claimed by that very sender.  As long as the DSN is not redirected to
+   someone other than the actual sender, the only people who see
+   malicious explanation strings are people whose messages claim to be
+   from domains that publish such strings in their SPF records.  In
+   practice, DSNs can be misdirected, such as when an MTA accepts an
+   E-Mail and then later generates a DSN to a forged address, or when an
+   E-Mail forwarder does not direct the DSN back to the original sender.
+
+10.6.  Privacy Exposure
+
+   Checking SPF records causes DNS queries to be sent to the domain
+   owner.  These DNS queries, especially if they are caused by the
+   "exists" mechanism, can contain information about who is sending
+   E-Mail and likely to which MTA the E-Mail is being sent.  This can
+   introduce some privacy concerns, which may be more or less of an
+   issue depending on local laws and the relationship between the domain
+   owner and the person sending the E-Mail.
+
+11.  Contributors and Acknowledgements
+
+   This document is largely based on the work of Meng Weng Wong and Mark
+   Lentczner.  Although, as this section acknowledges, many people have
+   contributed to this document, a very large portion of the writing and
+   editing are due to Meng and Mark.
+
+   This design owes a debt of parentage to [RMX] by Hadmut Danisch and
+   to [DMP] by Gordon Fecyk.  The idea of using a DNS record to check
+   the legitimacy of an E-Mail address traces its ancestry further back
+   through messages on the namedroppers mailing list by Paul Vixie
+
+
+
+Wong & Schlitt                Experimental                     [Page 38]
+
+RFC 4408             Sender Policy Framework (SPF)            April 2006
+
+
+   [Vixie] (based on suggestion by Jim Miller) and by David Green
+   [Green].
+
+   Philip Gladstone contributed the concept of macros to the
+   specification, multiplying the expressiveness of the language and
+   making per-user and per-IP lookups possible.
+
+   The authors would also like to thank the literally hundreds of
+   individuals who have participated in the development of this design.
+   They are far too numerous to name, but they include the following:
+
+      The folks on the spf-discuss mailing list.
+      The folks on the SPAM-L mailing list.
+      The folks on the IRTF ASRG mailing list.
+      The folks on the IETF MARID mailing list.
+      The folks on #perl.
+
+12.  IANA Considerations
+
+12.1.  The SPF DNS Record Type
+
+   The IANA has assigned a new Resource Record Type and Qtype from the
+   DNS Parameters Registry for the SPF RR type with code 99.
+
+12.2.  The Received-SPF Mail Header Field
+
+   Per [RFC3864], the "Received-SPF:" header field is added to the IANA
+   Permanent Message Header Field Registry.  The following is the
+   registration template:
+
+      Header field name: Received-SPF
+      Applicable protocol: mail ([RFC2822])
+      Status: Experimental
+      Author/Change controller: IETF
+      Specification document(s): RFC 4408
+      Related information:
+      Requesting SPF Council review of any proposed changes and
+      additions to this field are recommended.  For information about
+      the SPF Council see http://www.openspf.org/Council
+
+13.  References
+
+13.1.  Normative References
+
+   [RFC1035]  Mockapetris, P., "Domain names - implementation and
+              specification", STD 13, RFC 1035, November 1987.
+
+
+
+
+
+Wong & Schlitt                Experimental                     [Page 39]
+
+RFC 4408             Sender Policy Framework (SPF)            April 2006
+
+
+   [RFC1123]  Braden, R., "Requirements for Internet Hosts - Application
+              and Support", STD 3, RFC 1123, October 1989.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2821]  Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
+              April 2001.
+
+   [RFC2822]  Resnick, P., "Internet Message Format", RFC 2822, April
+              2001.
+
+   [RFC3464]  Moore, K. and G. Vaudreuil, "An Extensible Message Format
+              for Delivery Status Notifications", RFC 3464, January
+              2003.
+
+   [RFC3513]  Hinden, R. and S. Deering, "Internet Protocol Version 6
+              (IPv6) Addressing Architecture", RFC 3513, April 2003.
+
+   [RFC3864]  Klyne, G., Nottingham, M., and J. Mogul, "Registration
+              Procedures for Message Header Fields", BCP 90, RFC 3864,
+              September 2004.
+
+   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
+              Resource Identifier (URI): Generic Syntax", STD 66, RFC
+              3986, January 2005.
+
+   [RFC4234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
+              Specifications: ABNF", RFC 4234, October 2005.
+
+   [US-ASCII] American National Standards Institute (formerly United
+              States of America Standards Institute), "USA Code for
+              Information Interchange, X3.4", 1968.
+
+   ANSI X3.4-1968 has been replaced by newer versions with slight
+              modifications, but the 1968 version remains definitive for
+              the Internet.
+
+13.2  Informative References
+
+   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
+              STD 13, RFC 1034, November 1987.
+
+   [RFC1983]  Malkin, G., "Internet Users' Glossary", RFC 1983, August
+              1996.
+
+   [RFC2440]  Callas, J., Donnerhacke, L., Finney, H., and R. Thayer,
+              "OpenPGP Message Format", RFC 2440, November 1998.
+
+
+
+Wong & Schlitt                Experimental                     [Page 40]
+
+RFC 4408             Sender Policy Framework (SPF)            April 2006
+
+
+   [RFC2554]  Myers, J., "SMTP Service Extension for Authentication",
+              RFC 2554, March 1999.
+
+   [RFC3696]  Klensin, J., "Application Techniques for Checking and
+              Transformation of Names", RFC 3696, February 2004.
+
+   [RFC3833]  Atkins, D. and R. Austein, "Threat Analysis of the Domain
+              Name System (DNS)", RFC 3833, August 2004.
+
+   [RFC3851]  Ramsdell, B., "Secure/Multipurpose Internet Mail
+              Extensions (S/MIME) Version 3.1 Message Specification",
+              RFC 3851, July 2004.
+
+   [RFC4409]  Gellens, R. and J. Klensin, "Message Submission for Mail",
+              RFC 4409, April 2006.
+
+   [RMX]      Danish, H., "The RMX DNS RR Type for light weight sender
+              authentication", Work In Progress
+
+   [DMP]      Fecyk, G., "Designated Mailers Protocol", Work In Progress
+
+   [Vixie]    Vixie, P., "Repudiating MAIL FROM", 2002.
+
+   [Green]    Green, D., "Domain-Authorized SMTP Mail", 2002.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wong & Schlitt                Experimental                     [Page 41]
+
+RFC 4408             Sender Policy Framework (SPF)            April 2006
+
+
+Appendix A.  Collected ABNF
+
+   This section is normative and any discrepancies with the ABNF
+   fragments in the preceding text are to be resolved in favor of this
+   grammar.
+
+   See [RFC4234] for ABNF notation.  Please note that as per this ABNF
+   definition, literal text strings (those in quotes) are case-
+   insensitive.  Hence, "mx" matches "mx", "MX", "mX", and "Mx".
+
+   record           = version terms *SP
+   version          = "v=spf1"
+
+   terms            = *( 1*SP ( directive / modifier ) )
+
+   directive        = [ qualifier ] mechanism
+   qualifier        = "+" / "-" / "?" / "~"
+   mechanism        = ( all / include
+                      / A / MX / PTR / IP4 / IP6 / exists )
+
+   all              = "all"
+   include          = "include"  ":" domain-spec
+   A                = "a"      [ ":" domain-spec ] [ dual-cidr-length ]
+   MX               = "mx"     [ ":" domain-spec ] [ dual-cidr-length ]
+   PTR              = "ptr"    [ ":" domain-spec ]
+   IP4              = "ip4"      ":" ip4-network   [ ip4-cidr-length ]
+   IP6              = "ip6"      ":" ip6-network   [ ip6-cidr-length ]
+   exists           = "exists"   ":" domain-spec
+
+   modifier         = redirect / explanation / unknown-modifier
+   redirect         = "redirect" "=" domain-spec
+   explanation      = "exp" "=" domain-spec
+   unknown-modifier = name "=" macro-string
+
+   ip4-cidr-length  = "/" 1*DIGIT
+   ip6-cidr-length  = "/" 1*DIGIT
+   dual-cidr-length = [ ip4-cidr-length ] [ "/" ip6-cidr-length ]
+
+   ip4-network      = qnum "." qnum "." qnum "." qnum
+   qnum             = DIGIT                 ; 0-9
+                      / %x31-39 DIGIT       ; 10-99
+                      / "1" 2DIGIT          ; 100-199
+                      / "2" %x30-34 DIGIT   ; 200-249
+                      / "25" %x30-35        ; 250-255
+             ; conventional dotted quad notation.  e.g., 192.0.2.0
+   ip6-network      = <as per [RFC 3513], section 2.2>
+             ; e.g., 2001:DB8::CD30
+
+
+
+
+Wong & Schlitt                Experimental                     [Page 42]
+
+RFC 4408             Sender Policy Framework (SPF)            April 2006
+
+
+   domain-spec      = macro-string domain-end
+   domain-end       = ( "." toplabel [ "." ] ) / macro-expand
+   toplabel         = ( *alphanum ALPHA *alphanum ) /
+                      ( 1*alphanum "-" *( alphanum / "-" ) alphanum )
+                      ; LDH rule plus additional TLD restrictions
+                      ; (see [RFC3696], Section 2)
+
+   alphanum         = ALPHA / DIGIT
+
+   explain-string   = *( macro-string / SP )
+
+   macro-string     = *( macro-expand / macro-literal )
+   macro-expand     = ( "%{" macro-letter transformers *delimiter "}" )
+                      / "%%" / "%_" / "%-"
+   macro-literal    = %x21-24 / %x26-7E
+                      ; visible characters except "%"
+   macro-letter     = "s" / "l" / "o" / "d" / "i" / "p" / "h" /
+                      "c" / "r" / "t"
+   transformers     = *DIGIT [ "r" ]
+   delimiter        = "." / "-" / "+" / "," / "/" / "_" / "="
+
+   name             = ALPHA *( ALPHA / DIGIT / "-" / "_" / "." )
+
+   header-field     = "Received-SPF:" [CFWS] result FWS [comment FWS]
+                      [ key-value-list ] CRLF
+
+   result           = "Pass" / "Fail" / "SoftFail" / "Neutral" /
+                      "None" / "TempError" / "PermError"
+
+   key-value-list   = key-value-pair *( ";" [CFWS] key-value-pair )
+                      [";"]
+
+   key-value-pair   = key [CFWS] "=" ( dot-atom / quoted-string )
+
+   key              = "client-ip" / "envelope-from" / "helo" /
+                      "problem" / "receiver" / "identity" /
+                       mechanism / "x-" name / name
+
+   identity         = "mailfrom"   ; for the "MAIL FROM" identity
+                      / "helo"     ; for the "HELO" identity
+                      / name       ; other identities
+
+   dot-atom         = <unquoted word as per [RFC2822]>
+   quoted-string    = <quoted string as per [RFC2822]>
+   comment          = <comment string as per [RFC2822]>
+   CFWS             = <comment or folding white space as per [RFC2822]>
+   FWS              = <folding white space as per [RFC2822]>
+   CRLF             = <standard end-of-line token as per [RFC2822]>
+
+
+
+Wong & Schlitt                Experimental                     [Page 43]
+
+RFC 4408             Sender Policy Framework (SPF)            April 2006
+
+
+Appendix B.  Extended Examples
+
+   These examples are based on the following DNS setup:
+
+   ; A domain with two mail servers, two hosts
+   ; and two servers at the domain name
+   $ORIGIN example.com.
+   @           MX  10 mail-a
+               MX  20 mail-b
+               A   192.0.2.10
+               A   192.0.2.11
+   amy         A   192.0.2.65
+   bob         A   192.0.2.66
+   mail-a      A   192.0.2.129
+   mail-b      A   192.0.2.130
+   www         CNAME example.com.
+
+   ; A related domain
+   $ORIGIN example.org.
+   @           MX  10 mail-c
+   mail-c      A   192.0.2.140
+
+   ; The reverse IP for those addresses
+   $ORIGIN 2.0.192.in-addr.arpa.
+   10          PTR example.com.
+   11          PTR example.com.
+   65          PTR amy.example.com.
+   66          PTR bob.example.com.
+   129         PTR mail-a.example.com.
+   130         PTR mail-b.example.com.
+   140         PTR mail-c.example.org.
+
+   ; A rogue reverse IP domain that claims to be
+   ; something it's not
+   $ORIGIN 0.0.10.in-addr.arpa.
+   4           PTR bob.example.com.
+
+B.1.  Simple Examples
+
+   These examples show various possible published records for
+   example.com and which values if <ip> would cause check_host() to
+   return "Pass".  Note that <domain> is "example.com".
+
+   v=spf1 +all
+      -- any <ip> passes
+
+   v=spf1 a -all
+      -- hosts 192.0.2.10 and 192.0.2.11 pass
+
+
+
+Wong & Schlitt                Experimental                     [Page 44]
+
+RFC 4408             Sender Policy Framework (SPF)            April 2006
+
+
+   v=spf1 a:example.org -all
+      -- no sending hosts pass since example.org has no A records
+
+   v=spf1 mx -all
+      -- sending hosts 192.0.2.129 and 192.0.2.130 pass
+
+   v=spf1 mx:example.org -all
+      -- sending host 192.0.2.140 passes
+
+   v=spf1 mx mx:example.org -all
+      -- sending hosts 192.0.2.129, 192.0.2.130, and 192.0.2.140 pass
+
+   v=spf1 mx/30 mx:example.org/30 -all
+      -- any sending host in 192.0.2.128/30 or 192.0.2.140/30 passes
+
+   v=spf1 ptr -all
+      -- sending host 192.0.2.65 passes (reverse DNS is valid and is in
+         example.com)
+      -- sending host 192.0.2.140 fails (reverse DNS is valid, but not
+         in example.com)
+      -- sending host 10.0.0.4 fails (reverse IP is not valid)
+
+   v=spf1 ip4:192.0.2.128/28 -all
+      -- sending host 192.0.2.65 fails
+      -- sending host 192.0.2.129 passes
+
+B.2.  Multiple Domain Example
+
+   These examples show the effect of related records:
+
+      example.org: "v=spf1 include:example.com include:example.net -all"
+
+   This record would be used if mail from example.org actually came
+   through servers at example.com and example.net.  Example.org's
+   designated servers are the union of example.com's and example.net's
+   designated servers.
+
+      la.example.org: "v=spf1 redirect=example.org"
+      ny.example.org: "v=spf1 redirect=example.org"
+      sf.example.org: "v=spf1 redirect=example.org"
+
+   These records allow a set of domains that all use the same mail
+   system to make use of that mail system's record.  In this way, only
+   the mail system's record needs to be updated when the mail setup
+   changes.  These domains' records never have to change.
+
+
+
+
+
+
+Wong & Schlitt                Experimental                     [Page 45]
+
+RFC 4408             Sender Policy Framework (SPF)            April 2006
+
+
+B.3.  DNSBL Style Example
+
+   Imagine that, in addition to the domain records listed above, there
+   are these:
+
+   $ORIGIN _spf.example.com.  mary.mobile-users                   A
+   127.0.0.2 fred.mobile-users                   A 127.0.0.2
+   15.15.168.192.joel.remote-users     A 127.0.0.2
+   16.15.168.192.joel.remote-users     A 127.0.0.2
+
+   The following records describe users at example.com who mail from
+   arbitrary servers, or who mail from personal servers.
+
+   example.com:
+
+   v=spf1 mx
+          include:mobile-users._spf.%{d}
+          include:remote-users._spf.%{d}
+          -all
+
+   mobile-users._spf.example.com:
+
+   v=spf1 exists:%{l1r+}.%{d}
+
+   remote-users._spf.example.com:
+
+   v=spf1 exists:%{ir}.%{l1r+}.%{d}
+
+B.4.  Multiple Requirements Example
+
+   Say that your sender policy requires both that the IP address is
+   within a certain range and that the reverse DNS for the IP matches.
+   This can be done several ways, including the following:
+
+   example.com.           SPF  ( "v=spf1 "
+                                 "-include:ip4._spf.%{d} "
+                                 "-include:ptr._spf.%{d} "
+                                 "+all" )
+   ip4._spf.example.com.  SPF  "v=spf1 -ip4:192.0.2.0/24 +all"
+   ptr._spf.example.com.  SPF  "v=spf1 -ptr +all"
+
+   This example shows how the "-include" mechanism can be useful, how an
+   SPF record that ends in "+all" can be very restrictive, and the use
+   of De Morgan's Law.
+
+
+
+
+
+
+
+Wong & Schlitt                Experimental                     [Page 46]
+
+RFC 4408             Sender Policy Framework (SPF)            April 2006
+
+
+Authors' Addresses
+
+   Meng Weng Wong
+   Singapore
+
+   EMail: mengwong+spf@pobox.com
+
+
+   Wayne Schlitt
+   4615 Meredeth #9
+   Lincoln Nebraska, NE  68506
+   United States of America
+
+   EMail: wayne@schlitt.net
+   URI:   http://www.schlitt.net/spf/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wong & Schlitt                Experimental                     [Page 47]
+
+RFC 4408             Sender Policy Framework (SPF)            April 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Wong & Schlitt                Experimental                     [Page 48]
+
diff --git a/doc/rfc/rfc4431.txt b/doc/rfc/rfc4431.txt
new file mode 100644
index 0000000..8b38872
--- /dev/null
+++ b/doc/rfc/rfc4431.txt
@@ -0,0 +1,227 @@
+
+
+
+
+
+
+Network Working Group                                         M. Andrews
+Request for Comments: 4431                   Internet Systems Consortium
+Category: Informational                                        S. Weiler
+                                                            SPARTA, Inc.
+                                                           February 2006
+
+
+       The DNSSEC Lookaside Validation (DLV) DNS Resource Record
+
+Status of This Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   This document defines a new DNS resource record, called the DNSSEC
+   Lookaside Validation (DLV) RR, for publishing DNSSEC trust anchors
+   outside of the DNS delegation chain.
+
+1.  Introduction
+
+   DNSSEC [1] [2] [3] authenticates DNS data by building public-key
+   signature chains along the DNS delegation chain from a trust anchor,
+   ideally a trust anchor for the DNS root.
+
+   This document defines a new resource record for publishing such trust
+   anchors outside of the DNS's normal delegation chain.  Use of these
+   records by DNSSEC validators is outside the scope of this document,
+   but it is expected that these records will help resolvers validate
+   DNSSEC-signed data from zones whose ancestors either aren't signed or
+   refuse to publish delegation signer (DS) records for their children.
+
+2.  DLV Resource Record
+
+   The DLV resource record has exactly the same wire and presentation
+   formats as the DS resource record, defined in RFC 4034, Section 5.
+   It uses the same IANA-assigned values in the algorithm and digest
+   type fields as the DS record.  (Those IANA registries are known as
+   the "DNS Security Algorithm Numbers" and "DS RR Type Algorithm
+   Numbers" registries.)
+
+
+
+
+
+Andrews & Weiler             Informational                      [Page 1]
+
+RFC 4431                  DLV Resource Record              February 2006
+
+
+   The DLV record is a normal DNS record type without any special
+   processing requirements.  In particular, the DLV record does not
+   inherit any of the special processing or handling requirements of the
+   DS record type (described in Section 3.1.4.1 of RFC 4035).  Unlike
+   the DS record, the DLV record may not appear on the parent's side of
+   a zone cut.  A DLV record may, however, appear at the apex of a zone.
+
+3.  Security Considerations
+
+   For authoritative servers and resolvers that do not attempt to use
+   DLV RRs as part of DNSSEC validation, there are no particular
+   security concerns -- DLV RRs are just like any other DNS data.
+
+   Software using DLV RRs as part of DNSSEC validation will almost
+   certainly want to impose constraints on their use, but those
+   constraints are best left to be described by the documents that more
+   fully describe the particulars of how the records are used.  At a
+   minimum, it would be unwise to use the records without some sort of
+   cryptographic authentication.  More likely than not, DNSSEC itself
+   will be used to authenticate the DLV RRs.  Depending on how a DLV RR
+   is used, failure to properly authenticate it could lead to
+   significant additional security problems including failure to detect
+   spoofed DNS data.
+
+   RFC 4034, Section 8, describes security considerations specific to
+   the DS RR.  Those considerations are equally applicable to DLV RRs.
+   Of particular note, the key tag field is used to help select DNSKEY
+   RRs efficiently, but it does not uniquely identify a single DNSKEY
+   RR.  It is possible for two distinct DNSKEY RRs to have the same
+   owner name, the same algorithm type, and the same key tag.  An
+   implementation that uses only the key tag to select a DNSKEY RR might
+   select the wrong public key in some circumstances.
+
+   For further discussion of the security implications of DNSSEC, see
+   RFC 4033, RFC 4034, and RFC 4035.
+
+4.  IANA Considerations
+
+   IANA has assigned DNS type code 32769 to the DLV resource record from
+   the Specification Required portion of the DNS Resource Record Type
+   registry, as defined in [4].
+
+   The DLV resource record reuses the same algorithm and digest type
+   registries already used for the DS resource record, currently known
+   as the "DNS Security Algorithm Numbers" and "DS RR Type Algorithm
+   Numbers" registries.
+
+
+
+
+
+Andrews & Weiler             Informational                      [Page 2]
+
+RFC 4431                  DLV Resource Record              February 2006
+
+
+5.  Normative References
+
+   [1]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+        "DNS Security Introduction and Requirements", RFC 4033,
+        March 2005.
+
+   [2]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+        "Resource Records for the DNS Security Extensions", RFC 4034,
+        March 2005.
+
+   [3]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+        "Protocol Modifications for the DNS Security Extensions",
+        RFC 4035, March 2005.
+
+   [4]  Eastlake, D., Brunner-Williams, E., and B. Manning, "Domain Name
+        System (DNS) IANA Considerations", BCP 42, RFC 2929,
+        September 2000.
+
+Authors' Addresses
+
+   Mark Andrews
+   Internet Systems Consortium
+   950 Charter St.
+   Redwood City, CA  94063
+   US
+
+   EMail: Mark_Andrews@isc.org
+
+
+   Samuel Weiler
+   SPARTA, Inc.
+   7075 Samuel Morse Drive
+   Columbia, Maryland  21046
+   US
+
+   EMail: weiler@tislabs.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Andrews & Weiler             Informational                      [Page 3]
+
+RFC 4431                  DLV Resource Record              February 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Andrews & Weiler             Informational                      [Page 4]
+
diff --git a/doc/rfc/rfc4470.txt b/doc/rfc/rfc4470.txt
new file mode 100644
index 0000000..ac12d65
--- /dev/null
+++ b/doc/rfc/rfc4470.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Network Working Group                                          S. Weiler
+Request for Comments: 4470                                  SPARTA, Inc.
+Updates: 4035, 4034                                             J. Ihren
+Category: Standards Track                                  Autonomica AB
+                                                              April 2006
+
+
+       Minimally Covering NSEC Records and DNSSEC On-line Signing
+
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   This document describes how to construct DNSSEC NSEC resource records
+   that cover a smaller range of names than called for by RFC 4034.  By
+   generating and signing these records on demand, authoritative name
+   servers can effectively stop the disclosure of zone contents
+   otherwise made possible by walking the chain of NSEC records in a
+   signed zone.
+
+Table of Contents
+
+   1. Introduction ....................................................1
+   2. Applicability of This Technique .................................2
+   3. Minimally Covering NSEC Records .................................2
+   4. Better Epsilon Functions ........................................4
+   5. Security Considerations .........................................5
+   6. Acknowledgements ................................................6
+   7. Normative References ............................................6
+
+1.  Introduction
+
+   With DNSSEC [1], an NSEC record lists the next instantiated name in
+   its zone, proving that no names exist in the "span" between the
+   NSEC's owner name and the name in the "next name" field.  In this
+   document, an NSEC record is said to "cover" the names between its
+   owner name and next name.
+
+
+
+Weiler & Ihren              Standards Track                     [Page 1]
+
+RFC 4470                      NSEC Epsilon                    April 2006
+
+
+   Through repeated queries that return NSEC records, it is possible to
+   retrieve all of the names in the zone, a process commonly called
+   "walking" the zone.  Some zone owners have policies forbidding zone
+   transfers by arbitrary clients; this side effect of the NSEC
+   architecture subverts those policies.
+
+   This document presents a way to prevent zone walking by constructing
+   NSEC records that cover fewer names.  These records can make zone
+   walking take approximately as many queries as simply asking for all
+   possible names in a zone, making zone walking impractical.  Some of
+   these records must be created and signed on demand, which requires
+   on-line private keys.  Anyone contemplating use of this technique is
+   strongly encouraged to review the discussion of the risks of on-line
+   signing in Section 5.
+
+1.2.  Keywords
+
+   The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [4].
+
+2.  Applicability of This Technique
+
+   The technique presented here may be useful to a zone owner that wants
+   to use DNSSEC, is concerned about exposure of its zone contents via
+   zone walking, and is willing to bear the costs of on-line signing.
+
+   As discussed in Section 5, on-line signing has several security
+   risks, including an increased likelihood of private keys being
+   disclosed and an increased risk of denial of service attack.  Anyone
+   contemplating use of this technique is strongly encouraged to review
+   the discussion of the risks of on-line signing in Section 5.
+
+   Furthermore, at the time this document was published, the DNSEXT
+   working group was actively working on a mechanism to prevent zone
+   walking that does not require on-line signing (tentatively called
+   NSEC3).  The new mechanism is likely to expose slightly more
+   information about the zone than this technique (e.g., the number of
+   instantiated names), but it may be preferable to this technique.
+
+3.  Minimally Covering NSEC Records
+
+   This mechanism involves changes to NSEC records for instantiated
+   names, which can still be generated and signed in advance, as well as
+   the on-demand generation and signing of new NSEC records whenever a
+   name must be proven not to exist.
+
+
+
+
+
+Weiler & Ihren              Standards Track                     [Page 2]
+
+RFC 4470                      NSEC Epsilon                    April 2006
+
+
+   In the "next name" field of instantiated names' NSEC records, rather
+   than list the next instantiated name in the zone, list any name that
+   falls lexically after the NSEC's owner name and before the next
+   instantiated name in the zone, according to the ordering function in
+   RFC 4034 [2] Section 6.1.  This relaxes the requirement in Section
+   4.1.1 of RFC 4034 that the "next name" field contains the next owner
+   name in the zone.  This change is expected to be fully compatible
+   with all existing DNSSEC validators.  These NSEC records are returned
+   whenever proving something specifically about the owner name (e.g.,
+   that no resource records of a given type appear at that name).
+
+   Whenever an NSEC record is needed to prove the non-existence of a
+   name, a new NSEC record is dynamically produced and signed.  The new
+   NSEC record has an owner name lexically before the QNAME but
+   lexically following any existing name and a "next name" lexically
+   following the QNAME but before any existing name.
+
+   The generated NSEC record's type bitmap MUST have the RRSIG and NSEC
+   bits set and SHOULD NOT have any other bits set.  This relaxes the
+   requirement in Section 2.3 of RFC4035 that NSEC RRs not appear at
+   names that did not exist before the zone was signed.
+
+   The functions to generate the lexically following and proceeding
+   names need not be perfect or consistent, but the generated NSEC
+   records must not cover any existing names.  Furthermore, this
+   technique works best when the generated NSEC records cover as few
+   names as possible.  In this document, the functions that generate the
+   nearby names are called "epsilon" functions, a reference to the
+   mathematical convention of using the greek letter epsilon to
+   represent small deviations.
+
+   An NSEC record denying the existence of a wildcard may be generated
+   in the same way.  Since the NSEC record covering a non-existent
+   wildcard is likely to be used in response to many queries,
+   authoritative name servers using the techniques described here may
+   want to pregenerate or cache that record and its corresponding RRSIG.
+
+   For example, a query for an A record at the non-instantiated name
+   example.com might produce the following two NSEC records, the first
+   denying the existence of the name example.com and the second denying
+   the existence of a wildcard:
+
+          exampld.com 3600 IN NSEC example-.com ( RRSIG NSEC )
+
+          \).com 3600 IN NSEC +.com ( RRSIG NSEC )
+
+
+
+
+
+
+Weiler & Ihren              Standards Track                     [Page 3]
+
+RFC 4470                      NSEC Epsilon                    April 2006
+
+
+   Before answering a query with these records, an authoritative server
+   must test for the existence of names between these endpoints.  If the
+   generated NSEC would cover existing names (e.g., exampldd.com or
+   *bizarre.example.com), a better epsilon function may be used or the
+   covered name closest to the QNAME could be used as the NSEC owner
+   name or next name, as appropriate.  If an existing name is used as
+   the NSEC owner name, that name's real NSEC record MUST be returned.
+   Using the same example, assuming an exampldd.com delegation exists,
+   this record might be returned from the parent:
+
+          exampldd.com 3600 IN NSEC example-.com ( NS DS RRSIG NSEC )
+
+   Like every authoritative record in the zone, each generated NSEC
+   record MUST have corresponding RRSIGs generated using each algorithm
+   (but not necessarily each DNSKEY) in the zone's DNSKEY RRset, as
+   described in RFC 4035 [3] Section 2.2.  To minimize the number of
+   signatures that must be generated, a zone may wish to limit the
+   number of algorithms in its DNSKEY RRset.
+
+4.  Better Epsilon Functions
+
+   Section 6.1 of RFC 4034 defines a strict ordering of DNS names.
+   Working backward from that definition, it should be possible to
+   define epsilon functions that generate the immediately following and
+   preceding names, respectively.  This document does not define such
+   functions.  Instead, this section presents functions that come
+   reasonably close to the perfect ones.  As described above, an
+   authoritative server should still ensure than no generated NSEC
+   covers any existing name.
+
+   To increment a name, add a leading label with a single null (zero-
+   value) octet.
+
+   To decrement a name, decrement the last character of the leftmost
+   label, then fill that label to a length of 63 octets with octets of
+   value 255.  To decrement a null (zero-value) octet, remove the octet
+   -- if an empty label is left, remove the label.  Defining this
+   function numerically: fill the leftmost label to its maximum length
+   with zeros (numeric, not ASCII zeros) and subtract one.
+
+   In response to a query for the non-existent name foo.example.com,
+   these functions produce NSEC records of the following:
+
+
+
+
+
+
+
+
+
+Weiler & Ihren              Standards Track                     [Page 4]
+
+RFC 4470                      NSEC Epsilon                    April 2006
+
+
+     fon\255\255\255\255\255\255\255\255\255\255\255\255\255\255
+     \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
+     \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
+     \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
+     \255.example.com 3600 IN NSEC \000.foo.example.com ( NSEC RRSIG )
+
+     \)\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
+     \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
+     \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
+     \255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
+     \255\255.example.com 3600 IN NSEC \000.*.example.com ( NSEC RRSIG )
+
+   The first of these NSEC RRs proves that no exact match for
+   foo.example.com exists, and the second proves that there is no
+   wildcard in example.com.
+
+   Both of these functions are imperfect: they do not take into account
+   constraints on number of labels in a name nor total length of a name.
+   As noted in the previous section, though, this technique does not
+   depend on the use of perfect epsilon functions: it is sufficient to
+   test whether any instantiated names fall into the span covered by the
+   generated NSEC and, if so, substitute those instantiated owner names
+   for the NSEC owner name or next name, as appropriate.
+
+5.  Security Considerations
+
+   This approach requires on-demand generation of RRSIG records.  This
+   creates several new vulnerabilities.
+
+   First, on-demand signing requires that a zone's authoritative servers
+   have access to its private keys.  Storing private keys on well-known
+   Internet-accessible servers may make them more vulnerable to
+   unintended disclosure.
+
+   Second, since generation of digital signatures tends to be
+   computationally demanding, the requirement for on-demand signing
+   makes authoritative servers vulnerable to a denial of service attack.
+
+   Last, if the epsilon functions are predictable, on-demand signing may
+   enable a chosen-plaintext attack on a zone's private keys.  Zones
+   using this approach should attempt to use cryptographic algorithms
+   that are resistant to chosen-plaintext attacks.  It is worth noting
+   that although DNSSEC has a "mandatory to implement" algorithm, that
+   is a requirement on resolvers and validators -- there is no
+   requirement that a zone be signed with any given algorithm.
+
+   The success of using minimally covering NSEC records to prevent zone
+   walking depends greatly on the quality of the epsilon functions
+
+
+
+Weiler & Ihren              Standards Track                     [Page 5]
+
+RFC 4470                      NSEC Epsilon                    April 2006
+
+
+   chosen.  An increment function that chooses a name obviously derived
+   from the next instantiated name may be easily reverse engineered,
+   destroying the value of this technique.  An increment function that
+   always returns a name close to the next instantiated name is likewise
+   a poor choice.  Good choices of epsilon functions are the ones that
+   produce the immediately following and preceding names, respectively,
+   though zone administrators may wish to use less perfect functions
+   that return more human-friendly names than the functions described in
+   Section 4 above.
+
+   Another obvious but misguided concern is the danger from synthesized
+   NSEC records being replayed.  It is possible for an attacker to
+   replay an old but still validly signed NSEC record after a new name
+   has been added in the span covered by that NSEC, incorrectly proving
+   that there is no record at that name.  This danger exists with DNSSEC
+   as defined in [3].  The techniques described here actually decrease
+   the danger, since the span covered by any NSEC record is smaller than
+   before.  Choosing better epsilon functions will further reduce this
+   danger.
+
+6.  Acknowledgements
+
+   Many individuals contributed to this design.  They include, in
+   addition to the authors of this document, Olaf Kolkman, Ed Lewis,
+   Peter Koch, Matt Larson, David Blacka, Suzanne Woolf, Jaap Akkerhuis,
+   Jakob Schlyter, Bill Manning, and Joao Damas.
+
+   In addition, the editors would like to thank Ed Lewis, Scott Rose,
+   and David Blacka for their careful review of the document.
+
+7.  Normative References
+
+   [1]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+        "DNS Security Introduction and Requirements", RFC 4033, March
+        2005.
+
+   [2]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+        "Resource Records for the DNS Security Extensions", RFC 4034,
+        March 2005.
+
+   [3]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+        "Protocol Modifications for the DNS Security Extensions", RFC
+        4035, March 2005.
+
+   [4]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", BCP 14, RFC 2119, March 1997.
+
+
+
+
+
+Weiler & Ihren              Standards Track                     [Page 6]
+
+RFC 4470                      NSEC Epsilon                    April 2006
+
+
+Authors' Addresses
+
+   Samuel Weiler
+   SPARTA, Inc.
+   7075 Samuel Morse Drive
+   Columbia, Maryland  21046
+   US
+
+   EMail: weiler@tislabs.com
+
+
+   Johan Ihren
+   Autonomica AB
+   Bellmansgatan 30
+   Stockholm  SE-118 47
+   Sweden
+
+   EMail: johani@autonomica.se
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Weiler & Ihren              Standards Track                     [Page 7]
+
+RFC 4470                      NSEC Epsilon                    April 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Weiler & Ihren              Standards Track                     [Page 8]
+
diff --git a/doc/rfc/rfc4634.txt b/doc/rfc/rfc4634.txt
new file mode 100644
index 0000000..b672df8
--- /dev/null
+++ b/doc/rfc/rfc4634.txt
@@ -0,0 +1,6051 @@
+
+
+
+
+
+
+Network Working Group                                    D. Eastlake 3rd
+Request for Comments: 4634                                 Motorola Labs
+Updates: 3174                                                  T. Hansen
+Category: Informational                                        AT&T Labs
+                                                               July 2006
+
+
+              US Secure Hash Algorithms (SHA and HMAC-SHA)
+
+Status of This Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   The United States of America has adopted a suite of Secure Hash
+   Algorithms (SHAs), including four beyond SHA-1, as part of a Federal
+   Information Processing Standard (FIPS), specifically SHA-224 (RFC
+   3874), SHA-256, SHA-384, and SHA-512.  The purpose of this document
+   is to make source code performing these hash functions conveniently
+   available to the Internet community.  The sample code supports input
+   strings of arbitrary bit length.  SHA-1's sample code from RFC 3174
+   has also been updated to handle input strings of arbitrary bit
+   length.  Most of the text herein was adapted by the authors from FIPS
+   180-2.
+
+   Code to perform SHA-based HMACs, with arbitrary bit length text, is
+   also included.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake 3rd & Hansen        Informational                      [Page 1]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+Table of Contents
+
+   1. Overview of Contents ............................................3
+      1.1. License ....................................................4
+   2. Notation for Bit Strings and Integers ...........................4
+   3. Operations on Words .............................................5
+   4. Message Padding and Parsing .....................................6
+      4.1. SHA-224 and SHA-256 ........................................7
+      4.2. SHA-384 and SHA-512 ........................................8
+   5. Functions and Constants Used ....................................9
+      5.1. SHA-224 and SHA-256 ........................................9
+      5.2. SHA-384 and SHA-512 .......................................10
+   6. Computing the Message Digest ...................................11
+      6.1. SHA-224 and SHA-256 Initialization ........................11
+      6.2. SHA-224 and SHA-256 Processing ............................11
+      6.3. SHA-384 and SHA-512 Initialization ........................13
+      6.4. SHA-384 and SHA-512 Processing ............................14
+   7. SHA-Based HMACs ................................................15
+   8. C Code for SHAs ................................................15
+      8.1. The .h File ...............................................18
+      8.2. The SHA Code ..............................................24
+           8.2.1. sha1.c .............................................24
+           8.2.2. sha224-256.c .......................................33
+           8.2.3. sha384-512.c .......................................45
+           8.2.4. usha.c .............................................67
+           8.2.5. sha-private.h ......................................72
+      8.3. The HMAC Code .............................................73
+      8.4. The Test Driver ...........................................78
+   9. Security Considerations .......................................106
+   10. Normative References .........................................106
+   11. Informative References .......................................106
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake 3rd & Hansen        Informational                      [Page 2]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+1.  Overview of Contents
+
+   NOTE: Much of the text below is taken from [FIPS180-2] and assertions
+   therein of the security of the algorithms described are made by the
+   US Government, the author of [FIPS180-2], and not by the authors of
+   this document.
+
+   The text below specifies Secure Hash Algorithms, SHA-224 [RFC3874],
+   SHA-256, SHA-384, and SHA-512, for computing a condensed
+   representation of a message or a data file. (SHA-1 is specified in
+   [RFC3174].)  When a message of any length < 2^64 bits (for SHA-224
+   and SHA-256) or < 2^128 bits (for SHA-384 and SHA-512) is input to
+   one of these algorithms, the result is an output called a message
+   digest.  The message digests range in length from 224 to 512 bits,
+   depending on the algorithm.  Secure hash algorithms are typically
+   used with other cryptographic algorithms, such as digital signature
+   algorithms and keyed hash authentication codes, or in the generation
+   of random numbers [RFC4086].
+
+   The four algorithms specified in this document are called secure
+   because it is computationally infeasible to (1) find a message that
+   corresponds to a given message digest, or (2) find two different
+   messages that produce the same message digest.  Any change to a
+   message in transit will, with very high probability, result in a
+   different message digest.  This will result in a verification failure
+   when the secure hash algorithm is used with a digital signature
+   algorithm or a keyed-hash message authentication algorithm.
+
+   The code provided herein supports input strings of arbitrary bit
+   length.  SHA-1's sample code from [RFC3174] has also been updated to
+   handle input strings of arbitrary bit length.  See Section 1.1 for
+   license information for this code.
+
+   Section 2 below defines the terminology and functions used as
+   building blocks to form these algorithms.  Section 3 describes the
+   fundamental operations on words from which these algorithms are
+   built.  Section 4 describes how messages are padded up to an integral
+   multiple of the required block size and then parsed into blocks.
+   Section 5 defines the constants and the composite functions used to
+   specify these algorithms.  Section 6 gives the actual specification
+   for the SHA-224, SHA-256, SHA-384, and SHA-512 functions.  Section 7
+   provides pointers to the specification of HMAC keyed message
+   authentication codes based on the SHA algorithms.  Section 8 gives
+   sample code for the SHA algorithms and Section 9 code for SHA-based
+   HMACs.  The SHA-based HMACs will accept arbitrary bit length text.
+
+
+
+
+
+
+Eastlake 3rd & Hansen        Informational                      [Page 3]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+1.1.  License
+
+   Permission is granted for all uses, commercial and non-commercial, of
+   the sample code found in Section 8.  Royalty free license to use,
+   copy, modify and distribute the software found in Section 8 is
+   granted, provided that this document is identified in all material
+   mentioning or referencing this software, and provided that
+   redistributed derivative works do not contain misleading author or
+   version information.
+
+   The authors make no representations concerning either the
+   merchantability of this software or the suitability of this software
+   for any particular purpose.  It is provided "as is" without express
+   or implied warranty of any kind.
+
+2.  Notation for Bit Strings and Integers
+
+   The following terminology related to bit strings and integers will be
+   used:
+
+    a.  A hex digit is an element of the set {0, 1, ... , 9, A, ... ,
+        F}.  A hex digit is the representation of a 4-bit string.
+        Examples: 7 = 0111, A = 1010.
+
+    b.  A word equals a 32-bit or 64-bit string, which may be
+        represented as a sequence of 8 or 16 hex digits, respectively.
+        To convert a word to hex digits, each 4-bit string is converted
+        to its hex equivalent as described in (a) above.  Example:
+
+        1010 0001 0000 0011 1111 1110 0010 0011 = A103FE23.
+
+        Throughout this document, the "big-endian" convention is used
+        when expressing both 32-bit and 64-bit words, so that within
+        each word the most significant bit is shown in the left-most bit
+        position.
+
+    c.  An integer may be represented as a word or pair of words.
+
+        An integer between 0 and 2^32 - 1 inclusive may be represented
+        as a 32-bit word.  The least significant four bits of the
+        integer are represented by the right-most hex digit of the word
+        representation.  Example: the integer 291 = 2^8+2^5+2^1+2^0 =
+        256+32+2+1 is represented by the hex word 00000123.
+
+        The same holds true for an integer between 0 and 2^64-1
+        inclusive, which may be represented as a 64-bit word.
+
+
+
+
+
+Eastlake 3rd & Hansen        Informational                      [Page 4]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+        If Z is an integer, 0 <= z < 2^64, then z = (2^32)x + y where 0
+        <= x < 2^32 and 0 <= y < 2^32.  Since x and y can be represented
+        as words X and Y, respectively, z can be represented as the pair
+        of words (X,Y).
+
+    d.  block = 512-bit or 1024-bit string.  A block (e.g., B) may be
+        represented as a sequence of 32-bit or 64-bit words.
+
+3.  Operations on Words
+
+   The following logical operators will be applied to words in all four
+   hash operations specified herein.  SHA-224 and SHA-256 operate on
+   32-bit words, while SHA-384 and SHA-512 operate on 64-bit words.
+
+   In the operations below, x<<n is obtained as follows: discard the
+   left-most n bits of x and then pad the result with n zeroed bits on
+   the right (the result will still be the same number of bits).
+
+    a.  Bitwise logical word operations
+
+        X AND Y  =  bitwise logical "and" of  X and Y.
+
+        X OR Y   =  bitwise logical "inclusive-or" of X and Y.
+
+        X XOR Y  =  bitwise logical "exclusive-or" of X and Y.
+
+        NOT X    =  bitwise logical "complement" of X.
+
+        Example:
+                 01101100101110011101001001111011
+           XOR   01100101110000010110100110110111
+                 --------------------------------
+             =   00001001011110001011101111001100
+
+    b.  The operation X + Y is defined as follows: words X and Y
+        represent w-bit integers x and y, where 0 <= x < 2^w and
+        0 <= y < 2^w.  For positive integers n and m, let
+
+             n mod m
+
+        be the remainder upon dividing n by m.  Compute
+
+             z  =  (x + y) mod 2^w.
+
+        Then 0 <= z < 2^w.  Convert z to a word, Z, and define Z = X +
+        Y.
+
+
+
+
+
+Eastlake 3rd & Hansen        Informational                      [Page 5]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+    c.  The right shift operation SHR^n(x), where x is a w-bit word and
+        n is an integer with 0 <= n < w, is defined by
+
+             SHR^n(x) = x>>n
+
+    d.  The rotate right (circular right shift) operation ROTR^n(x),
+        where x is a w-bit word and n is an integer with 0 <= n < w, is
+        defined by
+
+             ROTR^n(x) = (x>>n) OR (x<<(w-n))
+
+    e.  The rotate left (circular left shift) operation ROTL^n(x), where
+        x is a w-bit word and n is an integer with 0 <= n < w, is
+        defined by
+
+             ROTL^n(X)  =  (x<<n) OR (x>>w-n)
+
+        Note the following equivalence relationships, where w is fixed
+        in each relationship:
+
+             ROTL^n(x) = ROTR^(w-x)(x)
+
+             ROTR^n(x) = ROTL^(w-n)(x)
+
+4.  Message Padding and Parsing
+
+   The hash functions specified herein are used to compute a message
+   digest for a message or data file that is provided as input.  The
+   message or data file should be considered to be a bit string.  The
+   length of the message is the number of bits in the message (the empty
+   message has length 0).  If the number of bits in a message is a
+   multiple of 8, for compactness we can represent the message in hex.
+   The purpose of message padding is to make the total length of a
+   padded message a multiple of 512 for SHA-224 and SHA-256 or a
+   multiple of 1024 for SHA-384 and SHA-512.
+
+   The following specifies how this padding shall be performed.  As a
+   summary, a "1" followed by a number of "0"s followed by a 64-bit or
+   128-bit integer are appended to the end of the message to produce a
+   padded message of length 512*n or 1024*n.  The minimum number of "0"s
+   necessary to meet this criterion is used.  The appended integer is
+   the length of the original message.  The padded message is then
+   processed by the hash function as n 512-bit or 1024-bit blocks.
+
+
+
+
+
+
+
+
+Eastlake 3rd & Hansen        Informational                      [Page 6]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+4.1.  SHA-224 and SHA-256
+
+   Suppose a message has length L < 2^64.  Before it is input to the
+   hash function, the message is padded on the right as follows:
+
+    a.  "1" is appended.  Example: if the original message is
+        "01010000", this is padded to "010100001".
+
+    b.  K "0"s are appended where K is the smallest, non-negative
+        solution to the equation
+
+             L + 1 + K = 448 (mod 512)
+
+    c.  Then append the 64-bit block that is L in binary representation.
+        After appending this block, the length of the message will be a
+        multiple of 512 bits.
+
+        Example:  Suppose the original message is the bit string
+
+             01100001 01100010 01100011 01100100 01100101
+
+        After step (a), this gives
+
+             01100001 01100010 01100011 01100100 01100101 1
+
+        Since L = 40, the number of bits in the above is 41 and K = 407
+        "0"s are appended, making the total now 448.  This gives the
+        following in hex:
+
+             61626364 65800000 00000000 00000000
+             00000000 00000000 00000000 00000000
+             00000000 00000000 00000000 00000000
+             00000000 00000000
+
+        The 64-bit representation of L = 40 is hex 00000000 00000028.
+        Hence the final padded message is the following hex:
+
+             61626364 65800000 00000000 00000000
+             00000000 00000000 00000000 00000000
+             00000000 00000000 00000000 00000000
+             00000000 00000000 00000000 00000028
+
+
+
+
+
+
+
+
+
+
+Eastlake 3rd & Hansen        Informational                      [Page 7]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+4.2.  SHA-384 and SHA-512
+
+   Suppose a message has length L < 2^128.  Before it is input to the
+   hash function, the message is padded on the right as follows:
+
+    a.  "1" is appended.  Example: if the original message is
+        "01010000", this is padded to "010100001".
+
+    b.  K "0"s are appended where K is the smallest, non-negative
+        solution to the equation
+
+             L + 1 + K = 896 (mod 1024)
+
+    c.  Then append the 128-bit block that is L in binary
+        representation.  After appending this block, the length of the
+        message will be a multiple of 1024 bits.
+
+        Example:  Suppose the original message is the bit string
+
+             01100001 01100010 01100011 01100100 01100101
+
+        After step (a) this gives
+
+             01100001 01100010 01100011 01100100 01100101 1
+
+        Since L = 40, the number of bits in the above is 41 and K = 855
+        "0"s are appended, making the total now 896.  This gives the
+        following in hex:
+
+             61626364 65800000 00000000 00000000
+             00000000 00000000 00000000 00000000
+             00000000 00000000 00000000 00000000
+             00000000 00000000 00000000 00000000
+             00000000 00000000 00000000 00000000
+             00000000 00000000 00000000 00000000
+             00000000 00000000 00000000 00000000
+
+        The 128-bit representation of L = 40 is hex 00000000 00000000
+        00000000 00000028.  Hence the final padded message is the
+        following hex:
+
+             61626364 65800000 00000000 00000000
+             00000000 00000000 00000000 00000000
+             00000000 00000000 00000000 00000000
+             00000000 00000000 00000000 00000000
+             00000000 00000000 00000000 00000000
+
+
+
+
+
+Eastlake 3rd & Hansen        Informational                      [Page 8]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+             00000000 00000000 00000000 00000000
+             00000000 00000000 00000000 00000000
+             00000000 00000000 00000000 00000028
+
+5.  Functions and Constants Used
+
+   The following subsections give the six logical functions and the
+   table of constants used in each of the hash functions.
+
+5.1.  SHA-224 and SHA-256
+
+   SHA-224 and SHA-256 use six logical functions, where each function
+   operates on 32-bit words, which are represented as x, y, and z.  The
+   result of each function is a new 32-bit word.
+
+        CH( x, y, z) = (x AND y) XOR ( (NOT x) AND z)
+
+        MAJ( x, y, z) = (x AND y) XOR (x AND z) XOR (y AND z)
+
+        BSIG0(x) = ROTR^2(x) XOR ROTR^13(x) XOR ROTR^22(x)
+
+        BSIG1(x) = ROTR^6(x) XOR ROTR^11(x) XOR ROTR^25(x)
+
+        SSIG0(x) = ROTR^7(x) XOR ROTR^18(x) XOR SHR^3(x)
+
+        SSIG1(x) = ROTR^17(x) XOR ROTR^19(x) XOR SHR^10(x)
+
+   SHA-224 and SHA-256 use the same sequence of sixty-four constant
+   32-bit words, K0, K1, ..., K63.  These words represent the first
+   thirty-two bits of the fractional parts of the cube roots of the
+   first sixty-four prime numbers.  In hex, these constant words are as
+   follows (from left to right):
+
+        428a2f98 71374491 b5c0fbcf e9b5dba5
+        3956c25b 59f111f1 923f82a4 ab1c5ed5
+        d807aa98 12835b01 243185be 550c7dc3
+        72be5d74 80deb1fe 9bdc06a7 c19bf174
+        e49b69c1 efbe4786 0fc19dc6 240ca1cc
+        2de92c6f 4a7484aa 5cb0a9dc 76f988da
+        983e5152 a831c66d b00327c8 bf597fc7
+        c6e00bf3 d5a79147 06ca6351 14292967
+        27b70a85 2e1b2138 4d2c6dfc 53380d13
+        650a7354 766a0abb 81c2c92e 92722c85
+        a2bfe8a1 a81a664b c24b8b70 c76c51a3
+        d192e819 d6990624 f40e3585 106aa070
+        19a4c116 1e376c08 2748774c 34b0bcb5
+
+
+
+
+
+Eastlake 3rd & Hansen        Informational                      [Page 9]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+        391c0cb3 4ed8aa4a 5b9cca4f 682e6ff3
+        748f82ee 78a5636f 84c87814 8cc70208
+        90befffa a4506ceb bef9a3f7 c67178f2
+
+5.2.  SHA-384 and SHA-512
+
+   SHA-384 and SHA-512 each use six logical functions, where each
+   function operates on 64-bit words, which are represented as x, y, and
+   z.  The result of each function is a new 64-bit word.
+
+        CH( x, y, z) = (x AND y) XOR ( (NOT x) AND z)
+
+        MAJ( x, y, z) = (x AND y) XOR (x AND z) XOR (y AND z)
+
+        BSIG0(x) = ROTR^28(x) XOR ROTR^34(x) XOR ROTR^39(x)
+
+        BSIG1(x) = ROTR^14(x) XOR ROTR^18(x) XOR ROTR^41(x)
+
+        SSIG0(x) = ROTR^1(x) XOR ROTR^8(x) XOR SHR^7(x)
+
+        SSIG1(x) = ROTR^19(x) XOR ROTR^61(x) XOR SHR^6(x)
+
+   SHA-384 and SHA-512 use the same sequence of eighty constant 64-bit
+   words, K0, K1, ... K79.  These words represent the first sixty-four
+   bits of the fractional parts of the cube roots of the first eighty
+   prime numbers.  In hex, these constant words are as follows (from
+   left to right):
+
+   428a2f98d728ae22 7137449123ef65cd b5c0fbcfec4d3b2f e9b5dba58189dbbc
+   3956c25bf348b538 59f111f1b605d019 923f82a4af194f9b ab1c5ed5da6d8118
+   d807aa98a3030242 12835b0145706fbe 243185be4ee4b28c 550c7dc3d5ffb4e2
+   72be5d74f27b896f 80deb1fe3b1696b1 9bdc06a725c71235 c19bf174cf692694
+   e49b69c19ef14ad2 efbe4786384f25e3 0fc19dc68b8cd5b5 240ca1cc77ac9c65
+   2de92c6f592b0275 4a7484aa6ea6e483 5cb0a9dcbd41fbd4 76f988da831153b5
+   983e5152ee66dfab a831c66d2db43210 b00327c898fb213f bf597fc7beef0ee4
+   c6e00bf33da88fc2 d5a79147930aa725 06ca6351e003826f 142929670a0e6e70
+   27b70a8546d22ffc 2e1b21385c26c926 4d2c6dfc5ac42aed 53380d139d95b3df
+   650a73548baf63de 766a0abb3c77b2a8 81c2c92e47edaee6 92722c851482353b
+   a2bfe8a14cf10364 a81a664bbc423001 c24b8b70d0f89791 c76c51a30654be30
+   d192e819d6ef5218 d69906245565a910 f40e35855771202a 106aa07032bbd1b8
+   19a4c116b8d2d0c8 1e376c085141ab53 2748774cdf8eeb99 34b0bcb5e19b48a8
+   391c0cb3c5c95a63 4ed8aa4ae3418acb 5b9cca4f7763e373 682e6ff3d6b2b8a3
+   748f82ee5defb2fc 78a5636f43172f60 84c87814a1f0ab72 8cc702081a6439ec
+   90befffa23631e28 a4506cebde82bde9 bef9a3f7b2c67915 c67178f2e372532b
+   ca273eceea26619c d186b8c721c0c207 eada7dd6cde0eb1e f57d4f7fee6ed178
+   06f067aa72176fba 0a637dc5a2c898a6 113f9804bef90dae 1b710b35131c471b
+   28db77f523047d84 32caab7b40c72493 3c9ebe0a15c9bebc 431d67c49c100d4c
+   4cc5d4becb3e42b6 597f299cfc657e2a 5fcb6fab3ad6faec 6c44198c4a475817
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 10]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+6.  Computing the Message Digest
+
+   The output of each of the secure hash functions, after being applied
+   to a message of N blocks, is the hash quantity H(N).  For SHA-224 and
+   SHA-256, H(i) can be considered to be eight 32-bit words, H(i)0,
+   H(i)1, ... H(i)7.  For SHA-384 and SHA-512, it can be considered to
+   be eight 64-bit words, H(i)0, H(i)1, ..., H(i)7.
+
+   As described below, the hash words are initialized, modified as each
+   message block is processed, and finally concatenated after processing
+   the last block to yield the output.  For SHA-256 and SHA-512, all of
+   the H(N) variables are concatenated while the SHA-224 and SHA-384
+   hashes are produced by omitting some from the final concatenation.
+
+6.1.  SHA-224 and SHA-256 Initialization
+
+   For SHA-224, the initial hash value, H(0), consists of the following
+   32-bit words in hex:
+
+        H(0)0 = c1059ed8
+        H(0)1 = 367cd507
+        H(0)2 = 3070dd17
+        H(0)3 = f70e5939
+        H(0)4 = ffc00b31
+        H(0)5 = 68581511
+        H(0)6 = 64f98fa7
+        H(0)7 = befa4fa4
+
+   For SHA-256, the initial hash value, H(0), consists of the following
+   eight 32-bit words, in hex.  These words were obtained by taking the
+   first thirty-two bits of the fractional parts of the square roots of
+   the first eight prime numbers.
+
+        H(0)0 = 6a09e667
+        H(0)1 = bb67ae85
+        H(0)2 = 3c6ef372
+        H(0)3 = a54ff53a
+        H(0)4 = 510e527f
+        H(0)5 = 9b05688c
+        H(0)6 = 1f83d9ab
+        H(0)7 = 5be0cd19
+
+6.2.  SHA-224 and SHA-256 Processing
+
+   SHA-224 and SHA-256 perform identical processing on messages blocks
+   and differ only in how H(0) is initialized and how they produce their
+   final output.  They may be used to hash a message, M, having a length
+   of L bits, where 0 <= L < 2^64.  The algorithm uses (1) a message
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 11]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+   schedule of sixty-four 32-bit words, (2) eight working variables of
+   32 bits each, and (3) a hash value of eight 32-bit words.
+
+   The words of the message schedule are labeled W0, W1, ..., W63.  The
+   eight working variables are labeled a, b, c, d, e, f, g, and h.  The
+   words of the hash value are labeled H(i)0, H(i)1, ..., H(i)7, which
+   will hold the initial hash value, H(0), replaced by each successive
+   intermediate hash value (after each message block is processed),
+   H(i), and ending with the final hash value, H(N), after all N blocks
+   are processed.  They also use two temporary words, T1 and T2.
+
+   The input message is padded as described in Section 4.1 above then
+   parsed into 512-bit blocks, which are considered to be composed of 16
+   32-bit words M(i)0, M(i)1, ..., M(i)15.  The following computations
+   are then performed for each of the N message blocks.  All addition is
+   performed modulo 2^32.
+
+   For i = 1 to N
+
+      1. Prepare the message schedule W:
+         For t = 0 to 15
+            Wt = M(i)t
+         For t = 16 to 63
+            Wt = SSIG1(W(t-2)) + W(t-7) + SSIG0(t-15) + W(t-16)
+
+      2. Initialize the working variables:
+         a = H(i-1)0
+         b = H(i-1)1
+         c = H(i-1)2
+         d = H(i-1)3
+         e = H(i-1)4
+         f = H(i-1)5
+         g = H(i-1)6
+         h = H(i-1)7
+
+      3. Perform the main hash computation:
+         For t = 0 to 63
+            T1 = h + BSIG1(e) + CH(e,f,g) + Kt + Wt
+            T2 = BSIG0(a) + MAJ(a,b,c)
+            h = g
+            g = f
+            f = e
+            e = d + T1
+            d = c
+            c = b
+            b = a
+            a = T1 + T2
+
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 12]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+      4. Compute the intermediate hash value H(i):
+         H(i)0 = a + H(i-1)0
+         H(i)1 = b + H(i-1)1
+         H(i)2 = c + H(i-1)2
+         H(i)3 = d + H(i-1)3
+         H(i)4 = e + H(i-1)4
+         H(i)5 = f + H(i-1)5
+         H(i)6 = g + H(i-1)6
+         H(i)7 = h + H(i-1)7
+
+   After the above computations have been sequentially performed for all
+   of the blocks in the message, the final output is calculated.  For
+   SHA-256, this is the concatenation of all of H(N)0, H(N)1, through
+   H(N)7.  For SHA-224, this is the concatenation of H(N)0, H(N)1,
+   through H(N)6.
+
+6.3.  SHA-384 and SHA-512 Initialization
+
+   For SHA-384, the initial hash value, H(0), consists of the following
+   eight 64-bit words, in hex.  These words were obtained by taking the
+   first sixty-four bits of the fractional parts of the square roots of
+   the ninth through sixteenth prime numbers.
+
+        H(0)0 = cbbb9d5dc1059ed8
+        H(0)1 = 629a292a367cd507
+        H(0)2 = 9159015a3070dd17
+        H(0)3 = 152fecd8f70e5939
+        H(0)4 = 67332667ffc00b31
+        H(0)5 = 8eb44a8768581511
+        H(0)6 = db0c2e0d64f98fa7
+        H(0)7 = 47b5481dbefa4fa4
+
+   For SHA-512, the initial hash value, H(0), consists of the following
+   eight 64-bit words, in hex.  These words were obtained by taking the
+   first sixty-four bits of the fractional parts of the square roots of
+   the first eight prime numbers.
+
+        H(0)0 = 6a09e667f3bcc908
+        H(0)1 = bb67ae8584caa73b
+        H(0)2 = 3c6ef372fe94f82b
+        H(0)3 = a54ff53a5f1d36f1
+        H(0)4 = 510e527fade682d1
+        H(0)5 = 9b05688c2b3e6c1f
+        H(0)6 = 1f83d9abfb41bd6b
+        H(0)7 = 5be0cd19137e2179
+
+
+
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 13]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+6.4.  SHA-384 and SHA-512 Processing
+
+   SHA-384 and SHA-512 perform identical processing on message blocks
+   and differ only in how H(0) is initialized and how they produce their
+   final output.  They may be used to hash a message, M, having a length
+   of L bits, where 0 <= L < 2^128.  The algorithm uses (1) a message
+   schedule of eighty 64-bit words, (2) eight working variables of 64
+   bits each, and (3) a hash value of eight 64-bit words.
+
+   The words of the message schedule are labeled W0, W1, ..., W79.  The
+   eight working variables are labeled a, b, c, d, e, f, g, and h.  The
+   words of the hash value are labeled H(i)0, H(i)1, ..., H(i)7, which
+   will hold the initial hash value, H(0), replaced by each successive
+   intermediate hash value (after each message block is processed),
+   H(i), and ending with the final hash value, H(N) after all N blocks
+   are processed.
+
+   The input message is padded as described in Section 4.2 above, then
+   parsed into 1024-bit blocks, which are considered to be composed of
+   16 64-bit words M(i)0, M(i)1, ..., M(i)15.  The following
+   computations are then performed for each of the N message blocks.
+   All addition is performed modulo 2^64.
+
+   For i = 1 to N
+
+      1. Prepare the message schedule W:
+         For t = 0 to 15
+            Wt = M(i)t
+         For t = 16 to 79
+            Wt = SSIG1(W(t-2)) + W(t-7) + SSIG0(t-15) + W(t-16)
+
+      2. Initialize the working variables:
+         a = H(i-1)0
+         b = H(i-1)1
+         c = H(i-1)2
+         d = H(i-1)3
+         e = H(i-1)4
+         f = H(i-1)5
+         g = H(i-1)6
+         h = H(i-1)7
+
+      3. Perform the main hash computation:
+         For t = 0 to 79
+            T1 = h + BSIG1(e) + CH(e,f,g) + Kt + Wt
+            T2 = BSIG0(a) + MAJ(a,b,c)
+            h = g
+            g = f
+            f = e
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 14]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+            e = d + T1
+            d = c
+            c = b
+            b = a
+            a = T1 + T2
+
+      4. Compute the intermediate hash value H(i):
+         H(i)0 = a + H(i-1)0
+         H(i)1 = b + H(i-1)1
+         H(i)2 = c + H(i-1)2
+         H(i)3 = d + H(i-1)3
+         H(i)4 = e + H(i-1)4
+         H(i)5 = f + H(i-1)5
+         H(i)6 = g + H(i-1)6
+         H(i)7 = h + H(i-1)7
+
+   After the above computations have been sequentially performed for all
+   of the blocks in the message, the final output is calculated.  For
+   SHA-512, this is the concatenation of all of H(N)0, H(N)1, through
+   H(N)7.  For SHA-384, this is the concatenation of H(N)0, H(N)1,
+   through H(N)5.
+
+7.  SHA-Based HMACs
+
+   HMAC is a method for computing a keyed MAC (message authentication
+   code) using a hash function as described in [RFC2104].  It uses a key
+   to mix in with the input text to produce the final hash.
+
+   Sample code is also provided, in Section 8.3 below, to perform HMAC
+   based on any of the SHA algorithms described herein.  The sample code
+   found in [RFC2104] was written in terms of a specified text size.
+   Since SHA is defined in terms of an arbitrary number of bits, the
+   sample HMAC code has been written to allow the text input to HMAC to
+   have an arbitrary number of octets and bits.  A fixed-length
+   interface is also provided.
+
+8.  C Code for SHAs
+
+   Below is a demonstration implementation of these secure hash
+   functions in C.  Section 8.1 contains the header file sha.h, which
+   declares all constants, structures, and functions used by the sha and
+   hmac functions.  Section 8.2 contains the C code for sha1.c,
+   sha224-256.c, sha384-512.c, and usha.c along with sha-private.h,
+   which provides some declarations common to all the sha functions.
+   Section 8.3 contains the C code for the hmac functions.  Section 8.4
+   contains a test driver to exercise the code.
+
+
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 15]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+   For each of the digest length $$$, there is the following set of
+   constants, a structure, and functions:
+
+   Constants:
+      SHA$$$HashSize      number of octets in the hash
+      SHA$$$HashSizeBits  number of bits in the hash
+      SHA$$$_Message_Block_Size
+                          number of octets used in the intermediate
+                          message blocks
+      shaSuccess = 0      constant returned by each function on success
+      shaNull = 1         constant returned by each function when
+                          presented with a null pointer parameter
+      shaInputTooLong = 2  constant returned by each function when the
+                          input data is too long
+      shaStateError       constant returned by each function when
+                          SHA$$$Input is called after SHA$$$FinalBits or
+                          SHA$$$Result.
+
+   Structure:
+      typedef SHA$$$Context
+                          an opaque structure holding the complete state
+                          for producing the hash
+
+   Functions:
+                  int SHA$$$Reset(SHA$$$Context *);
+            Reset the hash context state
+      int SHA$$$Input(SHA$$$Context *, const uint8_t *octets,
+                  unsigned int bytecount);
+            Incorporate bytecount octets into the hash.
+      int SHA$$$FinalBits(SHA$$$Context *, const uint8_t octet,
+                  unsigned int bitcount);
+            Incorporate bitcount bits into the hash.  The bits are in
+            the upper portion of the octet.  SHA$$$Input() cannot be
+            called after this.
+      int SHA$$$Result(SHA$$$Context *,
+                  uint8_t Message_Digest[SHA$$$HashSize]);
+            Do the final calculations on the hash and copy the value
+            into Message_Digest.
+
+   In addition, functions with the prefix USHA are provided that take a
+   SHAversion value (SHA$$$) to select the SHA function suite.  They add
+   the following constants, structure, and functions:
+
+   Constants:
+      shaBadParam         constant returned by USHA functions when
+                          presented with a bad SHAversion (SHA$$$)
+                          parameter
+
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 16]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+      SHA$$$              SHAversion enumeration values, used by usha
+                          and hmac functions to select the SHA function
+                          suite
+
+   Structure:
+      typedef USHAContext
+                          an opaque structure holding the complete state
+                          for producing the hash
+
+   Functions:
+      int USHAReset(USHAContext *, SHAversion whichSha);
+            Reset the hash context state.
+      int USHAInput(USHAContext *,
+                  const uint8_t *bytes, unsigned int bytecount);
+            Incorporate bytecount octets into the hash.
+      int USHAFinalBits(USHAContext *,
+                  const uint8_t bits, unsigned int bitcount);
+                  Incorporate bitcount bits into the hash.
+      int USHAResult(USHAContext *,
+                  uint8_t Message_Digest[USHAMaxHashSize]);
+            Do the final calculations on the hash and copy the value
+            into Message_Digest.  Octets in Message_Digest beyond
+      USHAHashSize(whichSha) are left untouched.
+                  int USHAHashSize(enum SHAversion whichSha);
+            The number of octets in the given hash.
+      int USHAHashSizeBits(enum SHAversion whichSha);
+            The number of bits in the given hash.
+      int USHABlockSize(enum SHAversion whichSha);
+            The internal block size for the given hash.
+
+   The hmac functions follow the same pattern to allow any length of
+   text input to be used.
+
+   Structure:
+      typedef HMACContext an opaque structure holding the complete state
+                          for producing the hash
+
+   Functions:
+      int hmacReset(HMACContext *ctx, enum SHAversion whichSha,
+                  const unsigned char *key, int key_len);
+            Reset the hash context state.
+      int hmacInput(HMACContext *ctx, const unsigned char *text,
+                  int text_len);
+            Incorporate text_len octets into the hash.
+      int hmacFinalBits(HMACContext *ctx, const uint8_t bits,
+                  unsigned int bitcount);
+            Incorporate bitcount bits into the hash.
+
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 17]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+      int hmacResult(HMACContext *ctx,
+                  uint8_t Message_Digest[USHAMaxHashSize]);
+            Do the final calculations on the hash and copy the value
+            into Message_Digest.  Octets in Message_Digest beyond
+            USHAHashSize(whichSha) are left untouched.
+
+   In addition, a combined interface is provided, similar to that shown
+   in RFC 2104, that allows a fixed-length text input to be used.
+
+      int hmac(SHAversion whichSha,
+                  const unsigned char *text, int text_len,
+                  const unsigned char *key, int key_len,
+                  uint8_t Message_Digest[USHAMaxHashSize]);
+            Calculate the given digest for the given text and key, and
+            return the resulting hash.  Octets in Message_Digest beyond
+            USHAHashSize(whichSha) are left untouched.
+
+8.1.  The .h File
+
+/**************************** sha.h ****************************/
+/******************* See RFC 4634 for details ******************/
+#ifndef _SHA_H_
+#define _SHA_H_
+
+/*
+ *  Description:
+ *      This file implements the Secure Hash Signature Standard
+ *      algorithms as defined in the National Institute of Standards
+ *      and Technology Federal Information Processing Standards
+ *      Publication (FIPS PUB) 180-1 published on April 17, 1995, 180-2
+ *      published on August 1, 2002, and the FIPS PUB 180-2 Change
+ *      Notice published on February 28, 2004.
+ *
+ *      A combined document showing all algorithms is available at
+ *              http://csrc.nist.gov/publications/fips/
+ *              fips180-2/fips180-2withchangenotice.pdf
+ *
+ *      The five hashes are defined in these sizes:
+ *              SHA-1           20 byte / 160 bit
+ *              SHA-224         28 byte / 224 bit
+ *              SHA-256         32 byte / 256 bit
+ *              SHA-384         48 byte / 384 bit
+ *              SHA-512         64 byte / 512 bit
+ */
+
+#include <stdint.h>
+/*
+ * If you do not have the ISO standard stdint.h header file, then you
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 18]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+ * must typedef the following:
+ *    name              meaning
+ *  uint64_t         unsigned 64 bit integer
+ *  uint32_t         unsigned 32 bit integer
+ *  uint8_t          unsigned 8 bit integer (i.e., unsigned char)
+ *  int_least16_t    integer of >= 16 bits
+ *
+ */
+
+#ifndef _SHA_enum_
+#define _SHA_enum_
+/*
+ *  All SHA functions return one of these values.
+ */
+enum {
+    shaSuccess = 0,
+    shaNull,            /* Null pointer parameter */
+    shaInputTooLong,    /* input data too long */
+    shaStateError,      /* called Input after FinalBits or Result */
+    shaBadParam         /* passed a bad parameter */
+};
+#endif /* _SHA_enum_ */
+
+/*
+ *  These constants hold size information for each of the SHA
+ *  hashing operations
+ */
+enum {
+    SHA1_Message_Block_Size = 64, SHA224_Message_Block_Size = 64,
+    SHA256_Message_Block_Size = 64, SHA384_Message_Block_Size = 128,
+    SHA512_Message_Block_Size = 128,
+    USHA_Max_Message_Block_Size = SHA512_Message_Block_Size,
+
+    SHA1HashSize = 20, SHA224HashSize = 28, SHA256HashSize = 32,
+    SHA384HashSize = 48, SHA512HashSize = 64,
+    USHAMaxHashSize = SHA512HashSize,
+
+    SHA1HashSizeBits = 160, SHA224HashSizeBits = 224,
+    SHA256HashSizeBits = 256, SHA384HashSizeBits = 384,
+    SHA512HashSizeBits = 512, USHAMaxHashSizeBits = SHA512HashSizeBits
+};
+
+/*
+ *  These constants are used in the USHA (unified sha) functions.
+ */
+typedef enum SHAversion {
+    SHA1, SHA224, SHA256, SHA384, SHA512
+} SHAversion;
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 19]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+/*
+ *  This structure will hold context information for the SHA-1
+ *  hashing operation.
+ */
+typedef struct SHA1Context {
+    uint32_t Intermediate_Hash[SHA1HashSize/4]; /* Message Digest */
+
+    uint32_t Length_Low;                /* Message length in bits */
+    uint32_t Length_High;               /* Message length in bits */
+
+    int_least16_t Message_Block_Index;  /* Message_Block array index */
+                                        /* 512-bit message blocks */
+    uint8_t Message_Block[SHA1_Message_Block_Size];
+
+    int Computed;                       /* Is the digest computed? */
+    int Corrupted;                      /* Is the digest corrupted? */
+} SHA1Context;
+
+/*
+ *  This structure will hold context information for the SHA-256
+ *  hashing operation.
+ */
+typedef struct SHA256Context {
+    uint32_t Intermediate_Hash[SHA256HashSize/4]; /* Message Digest */
+
+    uint32_t Length_Low;                /* Message length in bits */
+    uint32_t Length_High;               /* Message length in bits */
+
+    int_least16_t Message_Block_Index;  /* Message_Block array index */
+                                        /* 512-bit message blocks */
+    uint8_t Message_Block[SHA256_Message_Block_Size];
+
+    int Computed;                       /* Is the digest computed? */
+    int Corrupted;                      /* Is the digest corrupted? */
+} SHA256Context;
+
+/*
+ *  This structure will hold context information for the SHA-512
+ *  hashing operation.
+ */
+typedef struct SHA512Context {
+#ifdef USE_32BIT_ONLY
+    uint32_t Intermediate_Hash[SHA512HashSize/4]; /* Message Digest  */
+    uint32_t Length[4];                 /* Message length in bits */
+#else /* !USE_32BIT_ONLY */
+    uint64_t Intermediate_Hash[SHA512HashSize/8]; /* Message Digest */
+    uint64_t Length_Low, Length_High;   /* Message length in bits */
+#endif /* USE_32BIT_ONLY */
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 20]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+    int_least16_t Message_Block_Index;  /* Message_Block array index */
+                                        /* 1024-bit message blocks */
+    uint8_t Message_Block[SHA512_Message_Block_Size];
+
+    int Computed;                       /* Is the digest computed?*/
+    int Corrupted;                      /* Is the digest corrupted? */
+} SHA512Context;
+
+/*
+ *  This structure will hold context information for the SHA-224
+ *  hashing operation. It uses the SHA-256 structure for computation.
+ */
+typedef struct SHA256Context SHA224Context;
+
+/*
+ *  This structure will hold context information for the SHA-384
+ *  hashing operation. It uses the SHA-512 structure for computation.
+ */
+typedef struct SHA512Context SHA384Context;
+
+/*
+ *  This structure holds context information for all SHA
+ *  hashing operations.
+ */
+typedef struct USHAContext {
+    int whichSha;               /* which SHA is being used */
+    union {
+      SHA1Context sha1Context;
+      SHA224Context sha224Context; SHA256Context sha256Context;
+      SHA384Context sha384Context; SHA512Context sha512Context;
+    } ctx;
+} USHAContext;
+
+/*
+ *  This structure will hold context information for the HMAC
+ *  keyed hashing operation.
+ */
+typedef struct HMACContext {
+    int whichSha;               /* which SHA is being used */
+    int hashSize;               /* hash size of SHA being used */
+    int blockSize;              /* block size of SHA being used */
+    USHAContext shaContext;     /* SHA context */
+    unsigned char k_opad[USHA_Max_Message_Block_Size];
+                        /* outer padding - key XORd with opad */
+} HMACContext;
+
+
+
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 21]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+/*
+ *  Function Prototypes
+ */
+
+/* SHA-1 */
+extern int SHA1Reset(SHA1Context *);
+extern int SHA1Input(SHA1Context *, const uint8_t *bytes,
+                     unsigned int bytecount);
+extern int SHA1FinalBits(SHA1Context *, const uint8_t bits,
+                         unsigned int bitcount);
+extern int SHA1Result(SHA1Context *,
+                      uint8_t Message_Digest[SHA1HashSize]);
+
+/* SHA-224 */
+extern int SHA224Reset(SHA224Context *);
+extern int SHA224Input(SHA224Context *, const uint8_t *bytes,
+                       unsigned int bytecount);
+extern int SHA224FinalBits(SHA224Context *, const uint8_t bits,
+                           unsigned int bitcount);
+extern int SHA224Result(SHA224Context *,
+                        uint8_t Message_Digest[SHA224HashSize]);
+
+/* SHA-256 */
+extern int SHA256Reset(SHA256Context *);
+extern int SHA256Input(SHA256Context *, const uint8_t *bytes,
+                       unsigned int bytecount);
+extern int SHA256FinalBits(SHA256Context *, const uint8_t bits,
+                           unsigned int bitcount);
+extern int SHA256Result(SHA256Context *,
+                        uint8_t Message_Digest[SHA256HashSize]);
+
+/* SHA-384 */
+extern int SHA384Reset(SHA384Context *);
+extern int SHA384Input(SHA384Context *, const uint8_t *bytes,
+                       unsigned int bytecount);
+extern int SHA384FinalBits(SHA384Context *, const uint8_t bits,
+                           unsigned int bitcount);
+extern int SHA384Result(SHA384Context *,
+                        uint8_t Message_Digest[SHA384HashSize]);
+
+/* SHA-512 */
+extern int SHA512Reset(SHA512Context *);
+extern int SHA512Input(SHA512Context *, const uint8_t *bytes,
+                       unsigned int bytecount);
+extern int SHA512FinalBits(SHA512Context *, const uint8_t bits,
+                           unsigned int bitcount);
+extern int SHA512Result(SHA512Context *,
+                        uint8_t Message_Digest[SHA512HashSize]);
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 22]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+/* Unified SHA functions, chosen by whichSha */
+extern int USHAReset(USHAContext *, SHAversion whichSha);
+extern int USHAInput(USHAContext *,
+                     const uint8_t *bytes, unsigned int bytecount);
+extern int USHAFinalBits(USHAContext *,
+                         const uint8_t bits, unsigned int bitcount);
+extern int USHAResult(USHAContext *,
+                      uint8_t Message_Digest[USHAMaxHashSize]);
+extern int USHABlockSize(enum SHAversion whichSha);
+extern int USHAHashSize(enum SHAversion whichSha);
+extern int USHAHashSizeBits(enum SHAversion whichSha);
+
+/*
+ * HMAC Keyed-Hashing for Message Authentication, RFC2104,
+ * for all SHAs.
+ * This interface allows a fixed-length text input to be used.
+ */
+extern int hmac(SHAversion whichSha, /* which SHA algorithm to use */
+    const unsigned char *text,     /* pointer to data stream */
+    int text_len,                  /* length of data stream */
+    const unsigned char *key,      /* pointer to authentication key */
+    int key_len,                   /* length of authentication key */
+    uint8_t digest[USHAMaxHashSize]); /* caller digest to fill in */
+
+/*
+ * HMAC Keyed-Hashing for Message Authentication, RFC2104,
+ * for all SHAs.
+ * This interface allows any length of text input to be used.
+ */
+extern int hmacReset(HMACContext *ctx, enum SHAversion whichSha,
+                     const unsigned char *key, int key_len);
+extern int hmacInput(HMACContext *ctx, const unsigned char *text,
+                     int text_len);
+
+extern int hmacFinalBits(HMACContext *ctx, const uint8_t bits,
+                         unsigned int bitcount);
+extern int hmacResult(HMACContext *ctx,
+                      uint8_t digest[USHAMaxHashSize]);
+
+#endif /* _SHA_H_ */
+
+
+
+
+
+
+
+
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 23]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+8.2.  The SHA Code
+
+   This code is primarily intended as expository and could be optimized
+   further.  For example, the assignment rotations through the variables
+   a, b, ..., h could be treated as a cycle and the loop unrolled,
+   rather than doing the explicit copying.
+
+   Note that there are alternative representations of the Ch() and Maj()
+   functions controlled by an ifdef.
+
+8.2.1.  sha1.c
+
+/**************************** sha1.c ****************************/
+/******************** See RFC 4634 for details ******************/
+/*
+ *  Description:
+ *      This file implements the Secure Hash Signature Standard
+ *      algorithms as defined in the National Institute of Standards
+ *      and Technology Federal Information Processing Standards
+ *      Publication (FIPS PUB) 180-1 published on April 17, 1995, 180-2
+ *      published on August 1, 2002, and the FIPS PUB 180-2 Change
+ *      Notice published on February 28, 2004.
+ *
+ *      A combined document showing all algorithms is available at
+ *              http://csrc.nist.gov/publications/fips/
+ *              fips180-2/fips180-2withchangenotice.pdf
+ *
+ *      The SHA-1 algorithm produces a 160-bit message digest for a
+ *      given data stream.  It should take about 2**n steps to find a
+ *      message with the same digest as a given message and
+ *      2**(n/2) to find any two messages with the same digest,
+ *      when n is the digest size in bits.  Therefore, this
+ *      algorithm can serve as a means of providing a
+ *      "fingerprint" for a message.
+ *
+ *  Portability Issues:
+ *      SHA-1 is defined in terms of 32-bit "words".  This code
+ *      uses <stdint.h> (included via "sha.h") to define 32 and 8
+ *      bit unsigned integer types.  If your C compiler does not
+ *      support 32 bit unsigned integers, this code is not
+ *      appropriate.
+ *
+ *  Caveats:
+ *      SHA-1 is designed to work with messages less than 2^64 bits
+ *      long. This implementation uses SHA1Input() to hash the bits
+ *      that are a multiple of the size of an 8-bit character, and then
+ *      uses SHA1FinalBits() to hash the final few bits of the input.
+ */
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 24]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+#include "sha.h"
+#include "sha-private.h"
+
+/*
+ *  Define the SHA1 circular left shift macro
+ */
+#define SHA1_ROTL(bits,word) \
+                (((word) << (bits)) | ((word) >> (32-(bits))))
+
+/*
+ * add "length" to the length
+ */
+static uint32_t addTemp;
+#define SHA1AddLength(context, length)                     \
+    (addTemp = (context)->Length_Low,                      \
+     (context)->Corrupted =                                \
+        (((context)->Length_Low += (length)) < addTemp) && \
+        (++(context)->Length_High == 0) ? 1 : 0)
+
+/* Local Function Prototypes */
+static void SHA1Finalize(SHA1Context *context, uint8_t Pad_Byte);
+static void SHA1PadMessage(SHA1Context *, uint8_t Pad_Byte);
+static void SHA1ProcessMessageBlock(SHA1Context *);
+
+/*
+ *  SHA1Reset
+ *
+ *  Description:
+ *      This function will initialize the SHA1Context in preparation
+ *      for computing a new SHA1 message digest.
+ *
+ *  Parameters:
+ *      context: [in/out]
+ *          The context to reset.
+ *
+ *  Returns:
+ *      sha Error Code.
+ *
+ */
+int SHA1Reset(SHA1Context *context)
+{
+    if (!context)
+        return shaNull;
+
+    context->Length_Low             = 0;
+    context->Length_High            = 0;
+    context->Message_Block_Index    = 0;
+
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 25]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+    /* Initial Hash Values: FIPS-180-2 section 5.3.1 */
+    context->Intermediate_Hash[0]   = 0x67452301;
+    context->Intermediate_Hash[1]   = 0xEFCDAB89;
+    context->Intermediate_Hash[2]   = 0x98BADCFE;
+    context->Intermediate_Hash[3]   = 0x10325476;
+    context->Intermediate_Hash[4]   = 0xC3D2E1F0;
+
+    context->Computed   = 0;
+    context->Corrupted  = 0;
+
+    return shaSuccess;
+}
+
+/*
+ *  SHA1Input
+ *
+ *  Description:
+ *      This function accepts an array of octets as the next portion
+ *      of the message.
+ *
+ *  Parameters:
+ *      context: [in/out]
+ *          The SHA context to update
+ *      message_array: [in]
+ *          An array of characters representing the next portion of
+ *          the message.
+ *      length: [in]
+ *          The length of the message in message_array
+ *
+ *  Returns:
+ *      sha Error Code.
+ *
+ */
+int SHA1Input(SHA1Context *context,
+    const uint8_t *message_array, unsigned length)
+{
+  if (!length)
+    return shaSuccess;
+
+  if (!context || !message_array)
+    return shaNull;
+
+  if (context->Computed) {
+    context->Corrupted = shaStateError;
+    return shaStateError;
+  }
+
+  if (context->Corrupted)
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 26]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+     return context->Corrupted;
+
+  while (length-- && !context->Corrupted) {
+    context->Message_Block[context->Message_Block_Index++] =
+      (*message_array & 0xFF);
+
+    if (!SHA1AddLength(context, 8) &&
+      (context->Message_Block_Index == SHA1_Message_Block_Size))
+      SHA1ProcessMessageBlock(context);
+
+    message_array++;
+  }
+
+  return shaSuccess;
+}
+
+/*
+ * SHA1FinalBits
+ *
+ * Description:
+ *   This function will add in any final bits of the message.
+ *
+ * Parameters:
+ *   context: [in/out]
+ *     The SHA context to update
+ *   message_bits: [in]
+ *     The final bits of the message, in the upper portion of the
+ *     byte. (Use 0b###00000 instead of 0b00000### to input the
+ *     three bits ###.)
+ *   length: [in]
+ *     The number of bits in message_bits, between 1 and 7.
+ *
+ * Returns:
+ *   sha Error Code.
+ */
+int SHA1FinalBits(SHA1Context *context, const uint8_t message_bits,
+    unsigned int length)
+{
+  uint8_t masks[8] = {
+      /* 0 0b00000000 */ 0x00, /* 1 0b10000000 */ 0x80,
+      /* 2 0b11000000 */ 0xC0, /* 3 0b11100000 */ 0xE0,
+      /* 4 0b11110000 */ 0xF0, /* 5 0b11111000 */ 0xF8,
+      /* 6 0b11111100 */ 0xFC, /* 7 0b11111110 */ 0xFE
+  };
+  uint8_t markbit[8] = {
+      /* 0 0b10000000 */ 0x80, /* 1 0b01000000 */ 0x40,
+      /* 2 0b00100000 */ 0x20, /* 3 0b00010000 */ 0x10,
+      /* 4 0b00001000 */ 0x08, /* 5 0b00000100 */ 0x04,
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 27]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+      /* 6 0b00000010 */ 0x02, /* 7 0b00000001 */ 0x01
+  };
+
+  if (!length)
+    return shaSuccess;
+
+  if (!context)
+    return shaNull;
+
+  if (context->Computed || (length >= 8) || (length == 0)) {
+    context->Corrupted = shaStateError;
+    return shaStateError;
+  }
+
+  if (context->Corrupted)
+     return context->Corrupted;
+
+  SHA1AddLength(context, length);
+  SHA1Finalize(context,
+    (uint8_t) ((message_bits & masks[length]) | markbit[length]));
+
+  return shaSuccess;
+}
+
+/*
+ * SHA1Result
+ *
+ * Description:
+ *   This function will return the 160-bit message digest into the
+ *   Message_Digest array provided by the caller.
+ *   NOTE: The first octet of hash is stored in the 0th element,
+ *      the last octet of hash in the 19th element.
+ *
+ * Parameters:
+ *   context: [in/out]
+ *     The context to use to calculate the SHA-1 hash.
+ *   Message_Digest: [out]
+ *     Where the digest is returned.
+ *
+ * Returns:
+ *   sha Error Code.
+ *
+ */
+int SHA1Result(SHA1Context *context,
+    uint8_t Message_Digest[SHA1HashSize])
+{
+  int i;
+
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 28]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+  if (!context || !Message_Digest)
+    return shaNull;
+
+  if (context->Corrupted)
+    return context->Corrupted;
+
+  if (!context->Computed)
+    SHA1Finalize(context, 0x80);
+
+  for (i = 0; i < SHA1HashSize; ++i)
+    Message_Digest[i] = (uint8_t) (context->Intermediate_Hash[i>>2]
+              >> 8 * ( 3 - ( i & 0x03 ) ));
+
+  return shaSuccess;
+}
+
+/*
+ * SHA1Finalize
+ *
+ * Description:
+ *   This helper function finishes off the digest calculations.
+ *
+ * Parameters:
+ *   context: [in/out]
+ *     The SHA context to update
+ *   Pad_Byte: [in]
+ *     The last byte to add to the digest before the 0-padding
+ *     and length. This will contain the last bits of the message
+ *     followed by another single bit. If the message was an
+ *     exact multiple of 8-bits long, Pad_Byte will be 0x80.
+ *
+ * Returns:
+ *   sha Error Code.
+ *
+ */
+static void SHA1Finalize(SHA1Context *context, uint8_t Pad_Byte)
+{
+  int i;
+  SHA1PadMessage(context, Pad_Byte);
+  /* message may be sensitive, clear it out */
+  for (i = 0; i < SHA1_Message_Block_Size; ++i)
+    context->Message_Block[i] = 0;
+  context->Length_Low = 0;  /* and clear length */
+  context->Length_High = 0;
+  context->Computed = 1;
+}
+
+/*
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 29]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+ * SHA1PadMessage
+ *
+ * Description:
+ *   According to the standard, the message must be padded to an
+ *   even 512 bits. The first padding bit must be a '1'. The last
+ *   64 bits represent the length of the original message. All bits
+ *   in between should be 0. This helper function will pad the
+ *   message according to those rules by filling the Message_Block
+ *   array accordingly. When it returns, it can be assumed that the
+ *   message digest has been computed.
+ *
+ * Parameters:
+ *   context: [in/out]
+ *     The context to pad
+ *   Pad_Byte: [in]
+ *     The last byte to add to the digest before the 0-padding
+ *     and length. This will contain the last bits of the message
+ *     followed by another single bit. If the message was an
+ *     exact multiple of 8-bits long, Pad_Byte will be 0x80.
+ *
+ * Returns:
+ *   Nothing.
+ */
+static void SHA1PadMessage(SHA1Context *context, uint8_t Pad_Byte)
+{
+  /*
+   * Check to see if the current message block is too small to hold
+   * the initial padding bits and length. If so, we will pad the
+   * block, process it, and then continue padding into a second
+   * block.
+   */
+  if (context->Message_Block_Index >= (SHA1_Message_Block_Size - 8)) {
+    context->Message_Block[context->Message_Block_Index++] = Pad_Byte;
+    while (context->Message_Block_Index < SHA1_Message_Block_Size)
+      context->Message_Block[context->Message_Block_Index++] = 0;
+
+    SHA1ProcessMessageBlock(context);
+  } else
+    context->Message_Block[context->Message_Block_Index++] = Pad_Byte;
+
+  while (context->Message_Block_Index < (SHA1_Message_Block_Size - 8))
+    context->Message_Block[context->Message_Block_Index++] = 0;
+
+  /*
+   * Store the message length as the last 8 octets
+   */
+  context->Message_Block[56] = (uint8_t) (context->Length_High >> 24);
+  context->Message_Block[57] = (uint8_t) (context->Length_High >> 16);
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 30]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+  context->Message_Block[58] = (uint8_t) (context->Length_High >> 8);
+  context->Message_Block[59] = (uint8_t) (context->Length_High);
+  context->Message_Block[60] = (uint8_t) (context->Length_Low >> 24);
+  context->Message_Block[61] = (uint8_t) (context->Length_Low >> 16);
+  context->Message_Block[62] = (uint8_t) (context->Length_Low >> 8);
+  context->Message_Block[63] = (uint8_t) (context->Length_Low);
+
+  SHA1ProcessMessageBlock(context);
+}
+
+/*
+ * SHA1ProcessMessageBlock
+ *
+ * Description:
+ *   This helper function will process the next 512 bits of the
+ *   message stored in the Message_Block array.
+ *
+ * Parameters:
+ *   None.
+ *
+ * Returns:
+ *   Nothing.
+ *
+ * Comments:
+ *   Many of the variable names in this code, especially the
+ *   single character names, were used because those were the
+ *   names used in the publication.
+ */
+static void SHA1ProcessMessageBlock(SHA1Context *context)
+{
+  /* Constants defined in FIPS-180-2, section 4.2.1 */
+  const uint32_t K[4] = {
+      0x5A827999, 0x6ED9EBA1, 0x8F1BBCDC, 0xCA62C1D6
+  };
+  int        t;               /* Loop counter */
+  uint32_t   temp;            /* Temporary word value */
+  uint32_t   W[80];           /* Word sequence */
+  uint32_t   A, B, C, D, E;   /* Word buffers */
+
+  /*
+   * Initialize the first 16 words in the array W
+   */
+  for (t = 0; t < 16; t++) {
+    W[t]  = ((uint32_t)context->Message_Block[t * 4]) << 24;
+    W[t] |= ((uint32_t)context->Message_Block[t * 4 + 1]) << 16;
+    W[t] |= ((uint32_t)context->Message_Block[t * 4 + 2]) << 8;
+    W[t] |= ((uint32_t)context->Message_Block[t * 4 + 3]);
+  }
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 31]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+  for (t = 16; t < 80; t++)
+    W[t] = SHA1_ROTL(1, W[t-3] ^ W[t-8] ^ W[t-14] ^ W[t-16]);
+
+  A = context->Intermediate_Hash[0];
+  B = context->Intermediate_Hash[1];
+  C = context->Intermediate_Hash[2];
+  D = context->Intermediate_Hash[3];
+  E = context->Intermediate_Hash[4];
+
+  for (t = 0; t < 20; t++) {
+    temp = SHA1_ROTL(5,A) + SHA_Ch(B, C, D) + E + W[t] + K[0];
+    E = D;
+    D = C;
+    C = SHA1_ROTL(30,B);
+    B = A;
+    A = temp;
+  }
+
+  for (t = 20; t < 40; t++) {
+    temp = SHA1_ROTL(5,A) + SHA_Parity(B, C, D) + E + W[t] + K[1];
+    E = D;
+    D = C;
+    C = SHA1_ROTL(30,B);
+    B = A;
+    A = temp;
+  }
+
+  for (t = 40; t < 60; t++) {
+    temp = SHA1_ROTL(5,A) + SHA_Maj(B, C, D) + E + W[t] + K[2];
+    E = D;
+    D = C;
+    C = SHA1_ROTL(30,B);
+    B = A;
+    A = temp;
+  }
+
+  for (t = 60; t < 80; t++) {
+    temp = SHA1_ROTL(5,A) + SHA_Parity(B, C, D) + E + W[t] + K[3];
+    E = D;
+    D = C;
+    C = SHA1_ROTL(30,B);
+    B = A;
+    A = temp;
+  }
+
+  context->Intermediate_Hash[0] += A;
+  context->Intermediate_Hash[1] += B;
+  context->Intermediate_Hash[2] += C;
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 32]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+  context->Intermediate_Hash[3] += D;
+  context->Intermediate_Hash[4] += E;
+
+  context->Message_Block_Index = 0;
+}
+
+8.2.2.  sha224-256.c
+
+/*************************** sha224-256.c ***************************/
+/********************* See RFC 4634 for details *********************/
+/*
+ * Description:
+ *   This file implements the Secure Hash Signature Standard
+ *   algorithms as defined in the National Institute of Standards
+ *   and Technology Federal Information Processing Standards
+ *   Publication (FIPS PUB) 180-1 published on April 17, 1995, 180-2
+ *   published on August 1, 2002, and the FIPS PUB 180-2 Change
+ *   Notice published on February 28, 2004.
+ *
+ *   A combined document showing all algorithms is available at
+ *       http://csrc.nist.gov/publications/fips/
+ *       fips180-2/fips180-2withchangenotice.pdf
+ *
+ *   The SHA-224 and SHA-256 algorithms produce 224-bit and 256-bit
+ *   message digests for a given data stream. It should take about
+ *   2**n steps to find a message with the same digest as a given
+ *   message and 2**(n/2) to find any two messages with the same
+ *   digest, when n is the digest size in bits. Therefore, this
+ *   algorithm can serve as a means of providing a
+ *   "fingerprint" for a message.
+ *
+ * Portability Issues:
+ *   SHA-224 and SHA-256 are defined in terms of 32-bit "words".
+ *   This code uses <stdint.h> (included via "sha.h") to define 32
+ *   and 8 bit unsigned integer types. If your C compiler does not
+ *   support 32 bit unsigned integers, this code is not
+ *   appropriate.
+ *
+ * Caveats:
+ *   SHA-224 and SHA-256 are designed to work with messages less
+ *   than 2^64 bits long. This implementation uses SHA224/256Input()
+ *   to hash the bits that are a multiple of the size of an 8-bit
+ *   character, and then uses SHA224/256FinalBits() to hash the
+ *   final few bits of the input.
+ */
+
+#include "sha.h"
+#include "sha-private.h"
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 33]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+/* Define the SHA shift, rotate left and rotate right macro */
+#define SHA256_SHR(bits,word)      ((word) >> (bits))
+#define SHA256_ROTL(bits,word)                         \
+  (((word) << (bits)) | ((word) >> (32-(bits))))
+#define SHA256_ROTR(bits,word)                         \
+  (((word) >> (bits)) | ((word) << (32-(bits))))
+
+/* Define the SHA SIGMA and sigma macros */
+#define SHA256_SIGMA0(word)   \
+  (SHA256_ROTR( 2,word) ^ SHA256_ROTR(13,word) ^ SHA256_ROTR(22,word))
+#define SHA256_SIGMA1(word)   \
+  (SHA256_ROTR( 6,word) ^ SHA256_ROTR(11,word) ^ SHA256_ROTR(25,word))
+#define SHA256_sigma0(word)   \
+  (SHA256_ROTR( 7,word) ^ SHA256_ROTR(18,word) ^ SHA256_SHR( 3,word))
+#define SHA256_sigma1(word)   \
+  (SHA256_ROTR(17,word) ^ SHA256_ROTR(19,word) ^ SHA256_SHR(10,word))
+
+/*
+ * add "length" to the length
+ */
+static uint32_t addTemp;
+#define SHA224_256AddLength(context, length)               \
+  (addTemp = (context)->Length_Low, (context)->Corrupted = \
+    (((context)->Length_Low += (length)) < addTemp) &&     \
+    (++(context)->Length_High == 0) ? 1 : 0)
+
+/* Local Function Prototypes */
+static void SHA224_256Finalize(SHA256Context *context,
+  uint8_t Pad_Byte);
+static void SHA224_256PadMessage(SHA256Context *context,
+  uint8_t Pad_Byte);
+static void SHA224_256ProcessMessageBlock(SHA256Context *context);
+static int SHA224_256Reset(SHA256Context *context, uint32_t *H0);
+static int SHA224_256ResultN(SHA256Context *context,
+  uint8_t Message_Digest[], int HashSize);
+
+/* Initial Hash Values: FIPS-180-2 Change Notice 1 */
+static uint32_t SHA224_H0[SHA256HashSize/4] = {
+    0xC1059ED8, 0x367CD507, 0x3070DD17, 0xF70E5939,
+    0xFFC00B31, 0x68581511, 0x64F98FA7, 0xBEFA4FA4
+};
+
+/* Initial Hash Values: FIPS-180-2 section 5.3.2 */
+static uint32_t SHA256_H0[SHA256HashSize/4] = {
+  0x6A09E667, 0xBB67AE85, 0x3C6EF372, 0xA54FF53A,
+  0x510E527F, 0x9B05688C, 0x1F83D9AB, 0x5BE0CD19
+};
+
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 34]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+/*
+ * SHA224Reset
+ *
+ * Description:
+ *   This function will initialize the SHA384Context in preparation
+ *   for computing a new SHA224 message digest.
+ *
+ * Parameters:
+ *   context: [in/out]
+ *     The context to reset.
+ *
+ * Returns:
+ *   sha Error Code.
+ */
+int SHA224Reset(SHA224Context *context)
+{
+  return SHA224_256Reset(context, SHA224_H0);
+}
+
+/*
+ * SHA224Input
+ *
+ * Description:
+ *   This function accepts an array of octets as the next portion
+ *   of the message.
+ *
+ * Parameters:
+ *   context: [in/out]
+ *     The SHA context to update
+ *   message_array: [in]
+ *     An array of characters representing the next portion of
+ *     the message.
+ *   length: [in]
+ *     The length of the message in message_array
+ *
+ * Returns:
+ *   sha Error Code.
+ *
+ */
+int SHA224Input(SHA224Context *context, const uint8_t *message_array,
+    unsigned int length)
+{
+  return SHA256Input(context, message_array, length);
+}
+
+/*
+ * SHA224FinalBits
+ *
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 35]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+ * Description:
+ *   This function will add in any final bits of the message.
+ *
+ * Parameters:
+ *   context: [in/out]
+ *     The SHA context to update
+ *   message_bits: [in]
+ *     The final bits of the message, in the upper portion of the
+ *     byte. (Use 0b###00000 instead of 0b00000### to input the
+ *     three bits ###.)
+ *   length: [in]
+ *     The number of bits in message_bits, between 1 and 7.
+ *
+ * Returns:
+ *   sha Error Code.
+ */
+int SHA224FinalBits( SHA224Context *context,
+    const uint8_t message_bits, unsigned int length)
+{
+  return SHA256FinalBits(context, message_bits, length);
+}
+
+/*
+ * SHA224Result
+ *
+ * Description:
+ *   This function will return the 224-bit message
+ *   digest into the Message_Digest array provided by the caller.
+ *   NOTE: The first octet of hash is stored in the 0th element,
+ *      the last octet of hash in the 28th element.
+ *
+ * Parameters:
+ *   context: [in/out]
+ *     The context to use to calculate the SHA hash.
+ *   Message_Digest: [out]
+ *     Where the digest is returned.
+ *
+ * Returns:
+ *   sha Error Code.
+ */
+int SHA224Result(SHA224Context *context,
+    uint8_t Message_Digest[SHA224HashSize])
+{
+  return SHA224_256ResultN(context, Message_Digest, SHA224HashSize);
+}
+
+/*
+ * SHA256Reset
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 36]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+ *
+ * Description:
+ *   This function will initialize the SHA256Context in preparation
+ *   for computing a new SHA256 message digest.
+ *
+ * Parameters:
+ *   context: [in/out]
+ *     The context to reset.
+ *
+ * Returns:
+ *   sha Error Code.
+ */
+int SHA256Reset(SHA256Context *context)
+{
+  return SHA224_256Reset(context, SHA256_H0);
+}
+
+/*
+ * SHA256Input
+ *
+ * Description:
+ *   This function accepts an array of octets as the next portion
+ *   of the message.
+ *
+ * Parameters:
+ *   context: [in/out]
+ *     The SHA context to update
+ *   message_array: [in]
+ *     An array of characters representing the next portion of
+ *     the message.
+ *   length: [in]
+ *     The length of the message in message_array
+ *
+ * Returns:
+ *   sha Error Code.
+ */
+int SHA256Input(SHA256Context *context, const uint8_t *message_array,
+    unsigned int length)
+{
+  if (!length)
+    return shaSuccess;
+
+  if (!context || !message_array)
+    return shaNull;
+
+  if (context->Computed) {
+    context->Corrupted = shaStateError;
+    return shaStateError;
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 37]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+  }
+
+  if (context->Corrupted)
+     return context->Corrupted;
+
+  while (length-- && !context->Corrupted) {
+    context->Message_Block[context->Message_Block_Index++] =
+            (*message_array & 0xFF);
+
+    if (!SHA224_256AddLength(context, 8) &&
+      (context->Message_Block_Index == SHA256_Message_Block_Size))
+      SHA224_256ProcessMessageBlock(context);
+
+    message_array++;
+  }
+
+  return shaSuccess;
+
+}
+
+/*
+ * SHA256FinalBits
+ *
+ * Description:
+ *   This function will add in any final bits of the message.
+ *
+ * Parameters:
+ *   context: [in/out]
+ *     The SHA context to update
+ *   message_bits: [in]
+ *     The final bits of the message, in the upper portion of the
+ *     byte. (Use 0b###00000 instead of 0b00000### to input the
+ *     three bits ###.)
+ *   length: [in]
+ *     The number of bits in message_bits, between 1 and 7.
+ *
+ * Returns:
+ *   sha Error Code.
+ */
+int SHA256FinalBits(SHA256Context *context,
+    const uint8_t message_bits, unsigned int length)
+{
+  uint8_t masks[8] = {
+      /* 0 0b00000000 */ 0x00, /* 1 0b10000000 */ 0x80,
+      /* 2 0b11000000 */ 0xC0, /* 3 0b11100000 */ 0xE0,
+      /* 4 0b11110000 */ 0xF0, /* 5 0b11111000 */ 0xF8,
+      /* 6 0b11111100 */ 0xFC, /* 7 0b11111110 */ 0xFE
+  };
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 38]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+  uint8_t markbit[8] = {
+      /* 0 0b10000000 */ 0x80, /* 1 0b01000000 */ 0x40,
+      /* 2 0b00100000 */ 0x20, /* 3 0b00010000 */ 0x10,
+      /* 4 0b00001000 */ 0x08, /* 5 0b00000100 */ 0x04,
+      /* 6 0b00000010 */ 0x02, /* 7 0b00000001 */ 0x01
+  };
+
+  if (!length)
+    return shaSuccess;
+
+  if (!context)
+    return shaNull;
+
+  if ((context->Computed) || (length >= 8) || (length == 0)) {
+    context->Corrupted = shaStateError;
+    return shaStateError;
+  }
+
+  if (context->Corrupted)
+    return context->Corrupted;
+
+  SHA224_256AddLength(context, length);
+  SHA224_256Finalize(context, (uint8_t)
+    ((message_bits & masks[length]) | markbit[length]));
+
+  return shaSuccess;
+}
+
+/*
+ * SHA256Result
+ *
+ * Description:
+ *   This function will return the 256-bit message
+ *   digest into the Message_Digest array provided by the caller.
+ *   NOTE: The first octet of hash is stored in the 0th element,
+ *      the last octet of hash in the 32nd element.
+ *
+ * Parameters:
+ *   context: [in/out]
+ *     The context to use to calculate the SHA hash.
+ *   Message_Digest: [out]
+ *     Where the digest is returned.
+ *
+ * Returns:
+ *   sha Error Code.
+ */
+int SHA256Result(SHA256Context *context, uint8_t Message_Digest[])
+{
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 39]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+  return SHA224_256ResultN(context, Message_Digest, SHA256HashSize);
+}
+
+/*
+ * SHA224_256Finalize
+ *
+ * Description:
+ *   This helper function finishes off the digest calculations.
+ *
+ * Parameters:
+ *   context: [in/out]
+ *     The SHA context to update
+ *   Pad_Byte: [in]
+ *     The last byte to add to the digest before the 0-padding
+ *     and length. This will contain the last bits of the message
+ *     followed by another single bit. If the message was an
+ *     exact multiple of 8-bits long, Pad_Byte will be 0x80.
+ *
+ * Returns:
+ *   sha Error Code.
+ */
+static void SHA224_256Finalize(SHA256Context *context,
+    uint8_t Pad_Byte)
+{
+  int i;
+  SHA224_256PadMessage(context, Pad_Byte);
+  /* message may be sensitive, so clear it out */
+  for (i = 0; i < SHA256_Message_Block_Size; ++i)
+    context->Message_Block[i] = 0;
+  context->Length_Low = 0;  /* and clear length */
+  context->Length_High = 0;
+  context->Computed = 1;
+}
+
+/*
+ * SHA224_256PadMessage
+ *
+ * Description:
+ *   According to the standard, the message must be padded to an
+ *   even 512 bits. The first padding bit must be a '1'. The
+ *   last 64 bits represent the length of the original message.
+ *   All bits in between should be 0. This helper function will pad
+ *   the message according to those rules by filling the
+ *   Message_Block array accordingly. When it returns, it can be
+ *   assumed that the message digest has been computed.
+ *
+ * Parameters:
+ *   context: [in/out]
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 40]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+ *     The context to pad
+ *   Pad_Byte: [in]
+ *     The last byte to add to the digest before the 0-padding
+ *     and length. This will contain the last bits of the message
+ *     followed by another single bit. If the message was an
+ *     exact multiple of 8-bits long, Pad_Byte will be 0x80.
+ *
+ * Returns:
+ *   Nothing.
+ */
+static void SHA224_256PadMessage(SHA256Context *context,
+    uint8_t Pad_Byte)
+{
+  /*
+   * Check to see if the current message block is too small to hold
+   * the initial padding bits and length. If so, we will pad the
+   * block, process it, and then continue padding into a second
+   * block.
+   */
+  if (context->Message_Block_Index >= (SHA256_Message_Block_Size-8)) {
+    context->Message_Block[context->Message_Block_Index++] = Pad_Byte;
+    while (context->Message_Block_Index < SHA256_Message_Block_Size)
+      context->Message_Block[context->Message_Block_Index++] = 0;
+    SHA224_256ProcessMessageBlock(context);
+  } else
+    context->Message_Block[context->Message_Block_Index++] = Pad_Byte;
+
+  while (context->Message_Block_Index < (SHA256_Message_Block_Size-8))
+    context->Message_Block[context->Message_Block_Index++] = 0;
+
+  /*
+   * Store the message length as the last 8 octets
+   */
+  context->Message_Block[56] = (uint8_t)(context->Length_High >> 24);
+  context->Message_Block[57] = (uint8_t)(context->Length_High >> 16);
+  context->Message_Block[58] = (uint8_t)(context->Length_High >> 8);
+  context->Message_Block[59] = (uint8_t)(context->Length_High);
+  context->Message_Block[60] = (uint8_t)(context->Length_Low >> 24);
+  context->Message_Block[61] = (uint8_t)(context->Length_Low >> 16);
+  context->Message_Block[62] = (uint8_t)(context->Length_Low >> 8);
+  context->Message_Block[63] = (uint8_t)(context->Length_Low);
+
+  SHA224_256ProcessMessageBlock(context);
+}
+
+/*
+ * SHA224_256ProcessMessageBlock
+ *
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 41]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+ * Description:
+ *   This function will process the next 512 bits of the message
+ *   stored in the Message_Block array.
+ *
+ * Parameters:
+ *   context: [in/out]
+ *     The SHA context to update
+ *
+ * Returns:
+ *   Nothing.
+ *
+ * Comments:
+ *   Many of the variable names in this code, especially the
+ *   single character names, were used because those were the
+ *   names used in the publication.
+ */
+static void SHA224_256ProcessMessageBlock(SHA256Context *context)
+{
+  /* Constants defined in FIPS-180-2, section 4.2.2 */
+  static const uint32_t K[64] = {
+      0x428a2f98, 0x71374491, 0xb5c0fbcf, 0xe9b5dba5, 0x3956c25b,
+      0x59f111f1, 0x923f82a4, 0xab1c5ed5, 0xd807aa98, 0x12835b01,
+      0x243185be, 0x550c7dc3, 0x72be5d74, 0x80deb1fe, 0x9bdc06a7,
+      0xc19bf174, 0xe49b69c1, 0xefbe4786, 0x0fc19dc6, 0x240ca1cc,
+      0x2de92c6f, 0x4a7484aa, 0x5cb0a9dc, 0x76f988da, 0x983e5152,
+      0xa831c66d, 0xb00327c8, 0xbf597fc7, 0xc6e00bf3, 0xd5a79147,
+      0x06ca6351, 0x14292967, 0x27b70a85, 0x2e1b2138, 0x4d2c6dfc,
+      0x53380d13, 0x650a7354, 0x766a0abb, 0x81c2c92e, 0x92722c85,
+      0xa2bfe8a1, 0xa81a664b, 0xc24b8b70, 0xc76c51a3, 0xd192e819,
+      0xd6990624, 0xf40e3585, 0x106aa070, 0x19a4c116, 0x1e376c08,
+      0x2748774c, 0x34b0bcb5, 0x391c0cb3, 0x4ed8aa4a, 0x5b9cca4f,
+      0x682e6ff3, 0x748f82ee, 0x78a5636f, 0x84c87814, 0x8cc70208,
+      0x90befffa, 0xa4506ceb, 0xbef9a3f7, 0xc67178f2
+  };
+  int        t, t4;                   /* Loop counter */
+  uint32_t   temp1, temp2;            /* Temporary word value */
+  uint32_t   W[64];                   /* Word sequence */
+  uint32_t   A, B, C, D, E, F, G, H;  /* Word buffers */
+
+  /*
+   * Initialize the first 16 words in the array W
+   */
+  for (t = t4 = 0; t < 16; t++, t4 += 4)
+    W[t] = (((uint32_t)context->Message_Block[t4]) << 24) |
+           (((uint32_t)context->Message_Block[t4 + 1]) << 16) |
+           (((uint32_t)context->Message_Block[t4 + 2]) << 8) |
+           (((uint32_t)context->Message_Block[t4 + 3]));
+
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 42]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+  for (t = 16; t < 64; t++)
+    W[t] = SHA256_sigma1(W[t-2]) + W[t-7] +
+        SHA256_sigma0(W[t-15]) + W[t-16];
+
+  A = context->Intermediate_Hash[0];
+  B = context->Intermediate_Hash[1];
+  C = context->Intermediate_Hash[2];
+  D = context->Intermediate_Hash[3];
+  E = context->Intermediate_Hash[4];
+  F = context->Intermediate_Hash[5];
+  G = context->Intermediate_Hash[6];
+  H = context->Intermediate_Hash[7];
+
+  for (t = 0; t < 64; t++) {
+    temp1 = H + SHA256_SIGMA1(E) + SHA_Ch(E,F,G) + K[t] + W[t];
+    temp2 = SHA256_SIGMA0(A) + SHA_Maj(A,B,C);
+    H = G;
+    G = F;
+    F = E;
+    E = D + temp1;
+    D = C;
+    C = B;
+    B = A;
+    A = temp1 + temp2;
+  }
+
+  context->Intermediate_Hash[0] += A;
+  context->Intermediate_Hash[1] += B;
+  context->Intermediate_Hash[2] += C;
+  context->Intermediate_Hash[3] += D;
+  context->Intermediate_Hash[4] += E;
+  context->Intermediate_Hash[5] += F;
+  context->Intermediate_Hash[6] += G;
+  context->Intermediate_Hash[7] += H;
+
+  context->Message_Block_Index = 0;
+}
+
+/*
+ * SHA224_256Reset
+ *
+ * Description:
+ *   This helper function will initialize the SHA256Context in
+ *   preparation for computing a new SHA256 message digest.
+ *
+ * Parameters:
+ *   context: [in/out]
+ *     The context to reset.
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 43]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+ *   H0
+ *     The initial hash value to use.
+ *
+ * Returns:
+ *   sha Error Code.
+ */
+static int SHA224_256Reset(SHA256Context *context, uint32_t *H0)
+{
+  if (!context)
+    return shaNull;
+
+  context->Length_Low           = 0;
+  context->Length_High          = 0;
+  context->Message_Block_Index  = 0;
+
+  context->Intermediate_Hash[0] = H0[0];
+  context->Intermediate_Hash[1] = H0[1];
+  context->Intermediate_Hash[2] = H0[2];
+  context->Intermediate_Hash[3] = H0[3];
+  context->Intermediate_Hash[4] = H0[4];
+  context->Intermediate_Hash[5] = H0[5];
+  context->Intermediate_Hash[6] = H0[6];
+  context->Intermediate_Hash[7] = H0[7];
+
+  context->Computed  = 0;
+  context->Corrupted = 0;
+
+  return shaSuccess;
+}
+
+/*
+ * SHA224_256ResultN
+ *
+ * Description:
+ *   This helper function will return the 224-bit or 256-bit message
+ *   digest into the Message_Digest array provided by the caller.
+ *   NOTE: The first octet of hash is stored in the 0th element,
+ *      the last octet of hash in the 28th/32nd element.
+ *
+ * Parameters:
+ *   context: [in/out]
+ *     The context to use to calculate the SHA hash.
+ *   Message_Digest: [out]
+ *     Where the digest is returned.
+ *   HashSize: [in]
+ *     The size of the hash, either 28 or 32.
+ *
+ * Returns:
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 44]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+ *   sha Error Code.
+ */
+static int SHA224_256ResultN(SHA256Context *context,
+    uint8_t Message_Digest[], int HashSize)
+{
+  int i;
+
+  if (!context || !Message_Digest)
+    return shaNull;
+
+  if (context->Corrupted)
+    return context->Corrupted;
+
+  if (!context->Computed)
+    SHA224_256Finalize(context, 0x80);
+
+  for (i = 0; i < HashSize; ++i)
+    Message_Digest[i] = (uint8_t)
+      (context->Intermediate_Hash[i>>2] >> 8 * ( 3 - ( i & 0x03 ) ));
+
+  return shaSuccess;
+}
+
+8.2.3.  sha384-512.c
+
+/*************************** sha384-512.c ***************************/
+/********************* See RFC 4634 for details *********************/
+/*
+ * Description:
+ *   This file implements the Secure Hash Signature Standard
+ *   algorithms as defined in the National Institute of Standards
+ *   and Technology Federal Information Processing Standards
+ *   Publication (FIPS PUB) 180-1 published on April 17, 1995, 180-2
+ *   published on August 1, 2002, and the FIPS PUB 180-2 Change
+ *   Notice published on February 28, 2004.
+ *
+ *   A combined document showing all algorithms is available at
+ *       http://csrc.nist.gov/publications/fips/
+ *       fips180-2/fips180-2withchangenotice.pdf
+ *
+ *   The SHA-384 and SHA-512 algorithms produce 384-bit and 512-bit
+ *   message digests for a given data stream. It should take about
+ *   2**n steps to find a message with the same digest as a given
+ *   message and 2**(n/2) to find any two messages with the same
+ *   digest, when n is the digest size in bits. Therefore, this
+ *   algorithm can serve as a means of providing a
+ *   "fingerprint" for a message.
+ *
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 45]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+ * Portability Issues:
+ *   SHA-384 and SHA-512 are defined in terms of 64-bit "words",
+ *   but if USE_32BIT_ONLY is #defined, this code is implemented in
+ *   terms of 32-bit "words". This code uses <stdint.h> (included
+ *   via "sha.h") to define the 64, 32 and 8 bit unsigned integer
+ *   types. If your C compiler does not support 64 bit unsigned
+ *   integers, and you do not #define USE_32BIT_ONLY, this code is
+ *   not appropriate.
+ *
+ * Caveats:
+ *   SHA-384 and SHA-512 are designed to work with messages less
+ *   than 2^128 bits long. This implementation uses
+ *   SHA384/512Input() to hash the bits that are a multiple of the
+ *   size of an 8-bit character, and then uses SHA384/256FinalBits()
+ *   to hash the final few bits of the input.
+ *
+ */
+
+#include "sha.h"
+#include "sha-private.h"
+
+#ifdef USE_32BIT_ONLY
+/*
+ * Define 64-bit arithmetic in terms of 32-bit arithmetic.
+ * Each 64-bit number is represented in a 2-word array.
+ * All macros are defined such that the result is the last parameter.
+ */
+
+/*
+ * Define shift, rotate left and rotate right functions
+ */
+#define SHA512_SHR(bits, word, ret) (                          \
+    /* (((uint64_t)((word))) >> (bits)) */                     \
+    (ret)[0] = (((bits) < 32) && ((bits) >= 0)) ?              \
+      ((word)[0] >> (bits)) : 0,                               \
+    (ret)[1] = ((bits) > 32) ? ((word)[0] >> ((bits) - 32)) :  \
+      ((bits) == 32) ? (word)[0] :                             \
+      ((bits) >= 0) ?                                          \
+        (((word)[0] << (32 - (bits))) |                        \
+        ((word)[1] >> (bits))) : 0 )
+
+#define SHA512_SHL(bits, word, ret) (                          \
+    /* (((uint64_t)(word)) << (bits)) */                       \
+    (ret)[0] = ((bits) > 32) ? ((word)[1] << ((bits) - 32)) :  \
+         ((bits) == 32) ? (word)[1] :                          \
+         ((bits) >= 0) ?                                       \
+           (((word)[0] << (bits)) |                            \
+           ((word)[1] >> (32 - (bits)))) :                     \
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 46]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+         0,                                                    \
+    (ret)[1] = (((bits) < 32) && ((bits) >= 0)) ?              \
+        ((word)[1] << (bits)) : 0 )
+
+/*
+ * Define 64-bit OR
+ */
+#define SHA512_OR(word1, word2, ret) (                         \
+    (ret)[0] = (word1)[0] | (word2)[0],                        \
+    (ret)[1] = (word1)[1] | (word2)[1] )
+
+/*
+ * Define 64-bit XOR
+ */
+#define SHA512_XOR(word1, word2, ret) (                        \
+    (ret)[0] = (word1)[0] ^ (word2)[0],                        \
+    (ret)[1] = (word1)[1] ^ (word2)[1] )
+
+/*
+ * Define 64-bit AND
+ */
+#define SHA512_AND(word1, word2, ret) (                        \
+    (ret)[0] = (word1)[0] & (word2)[0],                        \
+    (ret)[1] = (word1)[1] & (word2)[1] )
+
+/*
+ * Define 64-bit TILDA
+ */
+#define SHA512_TILDA(word, ret)                                \
+  ( (ret)[0] = ~(word)[0], (ret)[1] = ~(word)[1] )
+
+/*
+ * Define 64-bit ADD
+ */
+#define SHA512_ADD(word1, word2, ret) (                        \
+    (ret)[1] = (word1)[1], (ret)[1] += (word2)[1],             \
+    (ret)[0] = (word1)[0] + (word2)[0] + ((ret)[1] < (word1)[1]) )
+
+/*
+ * Add the 4word value in word2 to word1.
+ */
+static uint32_t ADDTO4_temp, ADDTO4_temp2;
+#define SHA512_ADDTO4(word1, word2) (                          \
+    ADDTO4_temp = (word1)[3],                                  \
+    (word1)[3] += (word2)[3],                                  \
+    ADDTO4_temp2 = (word1)[2],                                 \
+    (word1)[2] += (word2)[2] + ((word1)[3] < ADDTO4_temp),     \
+    ADDTO4_temp = (word1)[1],                                  \
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 47]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+    (word1)[1] += (word2)[1] + ((word1)[2] < ADDTO4_temp2),    \
+    (word1)[0] += (word2)[0] + ((word1)[1] < ADDTO4_temp) )
+
+/*
+ * Add the 2word value in word2 to word1.
+ */
+static uint32_t ADDTO2_temp;
+#define SHA512_ADDTO2(word1, word2) (                          \
+    ADDTO2_temp = (word1)[1],                                  \
+    (word1)[1] += (word2)[1],                                  \
+    (word1)[0] += (word2)[0] + ((word1)[1] < ADDTO2_temp) )
+
+/*
+ * SHA rotate   ((word >> bits) | (word << (64-bits)))
+ */
+static uint32_t ROTR_temp1[2], ROTR_temp2[2];
+#define SHA512_ROTR(bits, word, ret) (                         \
+    SHA512_SHR((bits), (word), ROTR_temp1),                    \
+    SHA512_SHL(64-(bits), (word), ROTR_temp2),                 \
+    SHA512_OR(ROTR_temp1, ROTR_temp2, (ret)) )
+
+/*
+ * Define the SHA SIGMA and sigma macros
+ *  SHA512_ROTR(28,word) ^ SHA512_ROTR(34,word) ^ SHA512_ROTR(39,word)
+ */
+static uint32_t SIGMA0_temp1[2], SIGMA0_temp2[2],
+  SIGMA0_temp3[2], SIGMA0_temp4[2];
+#define SHA512_SIGMA0(word, ret) (                             \
+    SHA512_ROTR(28, (word), SIGMA0_temp1),                     \
+    SHA512_ROTR(34, (word), SIGMA0_temp2),                     \
+    SHA512_ROTR(39, (word), SIGMA0_temp3),                     \
+    SHA512_XOR(SIGMA0_temp2, SIGMA0_temp3, SIGMA0_temp4),      \
+    SHA512_XOR(SIGMA0_temp1, SIGMA0_temp4, (ret)) )
+
+/*
+ * SHA512_ROTR(14,word) ^ SHA512_ROTR(18,word) ^ SHA512_ROTR(41,word)
+ */
+static uint32_t SIGMA1_temp1[2], SIGMA1_temp2[2],
+  SIGMA1_temp3[2], SIGMA1_temp4[2];
+#define SHA512_SIGMA1(word, ret) (                             \
+    SHA512_ROTR(14, (word), SIGMA1_temp1),                     \
+    SHA512_ROTR(18, (word), SIGMA1_temp2),                     \
+    SHA512_ROTR(41, (word), SIGMA1_temp3),                     \
+    SHA512_XOR(SIGMA1_temp2, SIGMA1_temp3, SIGMA1_temp4),      \
+    SHA512_XOR(SIGMA1_temp1, SIGMA1_temp4, (ret)) )
+
+/*
+ * (SHA512_ROTR( 1,word) ^ SHA512_ROTR( 8,word) ^ SHA512_SHR( 7,word))
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 48]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+ */
+static uint32_t sigma0_temp1[2], sigma0_temp2[2],
+  sigma0_temp3[2], sigma0_temp4[2];
+#define SHA512_sigma0(word, ret) (                             \
+    SHA512_ROTR( 1, (word), sigma0_temp1),                     \
+    SHA512_ROTR( 8, (word), sigma0_temp2),                     \
+    SHA512_SHR( 7, (word), sigma0_temp3),                      \
+    SHA512_XOR(sigma0_temp2, sigma0_temp3, sigma0_temp4),      \
+    SHA512_XOR(sigma0_temp1, sigma0_temp4, (ret)) )
+
+/*
+ * (SHA512_ROTR(19,word) ^ SHA512_ROTR(61,word) ^ SHA512_SHR( 6,word))
+ */
+static uint32_t sigma1_temp1[2], sigma1_temp2[2],
+  sigma1_temp3[2], sigma1_temp4[2];
+#define SHA512_sigma1(word, ret) (                             \
+    SHA512_ROTR(19, (word), sigma1_temp1),                     \
+    SHA512_ROTR(61, (word), sigma1_temp2),                     \
+    SHA512_SHR( 6, (word), sigma1_temp3),                      \
+    SHA512_XOR(sigma1_temp2, sigma1_temp3, sigma1_temp4),      \
+    SHA512_XOR(sigma1_temp1, sigma1_temp4, (ret)) )
+
+#undef SHA_Ch
+#undef SHA_Maj
+
+#ifndef USE_MODIFIED_MACROS
+/*
+ * These definitions are the ones used in FIPS-180-2, section 4.1.3
+ *  Ch(x,y,z)   ((x & y) ^ (~x & z))
+ */
+static uint32_t Ch_temp1[2], Ch_temp2[2], Ch_temp3[2];
+#define SHA_Ch(x, y, z, ret) (                                 \
+    SHA512_AND(x, y, Ch_temp1),                                \
+    SHA512_TILDA(x, Ch_temp2),                                 \
+    SHA512_AND(Ch_temp2, z, Ch_temp3),                         \
+    SHA512_XOR(Ch_temp1, Ch_temp3, (ret)) )
+/*
+ *  Maj(x,y,z)  (((x)&(y)) ^ ((x)&(z)) ^ ((y)&(z)))
+ */
+static uint32_t Maj_temp1[2], Maj_temp2[2],
+  Maj_temp3[2], Maj_temp4[2];
+#define SHA_Maj(x, y, z, ret) (                                \
+    SHA512_AND(x, y, Maj_temp1),                               \
+    SHA512_AND(x, z, Maj_temp2),                               \
+    SHA512_AND(y, z, Maj_temp3),                               \
+    SHA512_XOR(Maj_temp2, Maj_temp3, Maj_temp4),               \
+    SHA512_XOR(Maj_temp1, Maj_temp4, (ret)) )
+
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 49]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+#else /* !USE_32BIT_ONLY */
+/*
+ * These definitions are potentially faster equivalents for the ones
+ * used in FIPS-180-2, section 4.1.3.
+ *   ((x & y) ^ (~x & z)) becomes
+ *   ((x & (y ^ z)) ^ z)
+ */
+#define SHA_Ch(x, y, z, ret) (                                 \
+   (ret)[0] = (((x)[0] & ((y)[0] ^ (z)[0])) ^ (z)[0]),         \
+   (ret)[1] = (((x)[1] & ((y)[1] ^ (z)[1])) ^ (z)[1]) )
+
+/*
+ *   ((x & y) ^ (x & z) ^ (y & z)) becomes
+ *   ((x & (y | z)) | (y & z))
+ */
+#define SHA_Maj(x, y, z, ret) (                                 \
+   ret[0] = (((x)[0] & ((y)[0] | (z)[0])) | ((y)[0] & (z)[0])), \
+   ret[1] = (((x)[1] & ((y)[1] | (z)[1])) | ((y)[1] & (z)[1])) )
+#endif /* USE_MODIFIED_MACROS */
+
+/*
+ * add "length" to the length
+ */
+static uint32_t addTemp[4] = { 0, 0, 0, 0 };
+#define SHA384_512AddLength(context, length) (                        \
+    addTemp[3] = (length), SHA512_ADDTO4((context)->Length, addTemp), \
+    (context)->Corrupted = (((context)->Length[3] == 0) &&            \
+       ((context)->Length[2] == 0) && ((context)->Length[1] == 0) &&  \
+       ((context)->Length[0] < 8)) ? 1 : 0 )
+
+/* Local Function Prototypes */
+static void SHA384_512Finalize(SHA512Context *context,
+  uint8_t Pad_Byte);
+static void SHA384_512PadMessage(SHA512Context *context,
+  uint8_t Pad_Byte);
+static void SHA384_512ProcessMessageBlock(SHA512Context *context);
+static int SHA384_512Reset(SHA512Context *context, uint32_t H0[]);
+static int SHA384_512ResultN( SHA512Context *context,
+  uint8_t Message_Digest[], int HashSize);
+
+/* Initial Hash Values: FIPS-180-2 sections 5.3.3 and 5.3.4 */
+static uint32_t SHA384_H0[SHA512HashSize/4] = {
+    0xCBBB9D5D, 0xC1059ED8, 0x629A292A, 0x367CD507, 0x9159015A,
+    0x3070DD17, 0x152FECD8, 0xF70E5939, 0x67332667, 0xFFC00B31,
+    0x8EB44A87, 0x68581511, 0xDB0C2E0D, 0x64F98FA7, 0x47B5481D,
+    0xBEFA4FA4
+};
+
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 50]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+static uint32_t SHA512_H0[SHA512HashSize/4] = {
+    0x6A09E667, 0xF3BCC908, 0xBB67AE85, 0x84CAA73B, 0x3C6EF372,
+    0xFE94F82B, 0xA54FF53A, 0x5F1D36F1, 0x510E527F, 0xADE682D1,
+    0x9B05688C, 0x2B3E6C1F, 0x1F83D9AB, 0xFB41BD6B, 0x5BE0CD19,
+    0x137E2179
+};
+
+#else /* !USE_32BIT_ONLY */
+
+/* Define the SHA shift, rotate left and rotate right macro */
+#define SHA512_SHR(bits,word)  (((uint64_t)(word)) >> (bits))
+#define SHA512_ROTR(bits,word) ((((uint64_t)(word)) >> (bits)) | \
+                                (((uint64_t)(word)) << (64-(bits))))
+
+/* Define the SHA SIGMA and sigma macros */
+#define SHA512_SIGMA0(word)   \
+ (SHA512_ROTR(28,word) ^ SHA512_ROTR(34,word) ^ SHA512_ROTR(39,word))
+#define SHA512_SIGMA1(word)   \
+ (SHA512_ROTR(14,word) ^ SHA512_ROTR(18,word) ^ SHA512_ROTR(41,word))
+#define SHA512_sigma0(word)   \
+ (SHA512_ROTR( 1,word) ^ SHA512_ROTR( 8,word) ^ SHA512_SHR( 7,word))
+#define SHA512_sigma1(word)   \
+ (SHA512_ROTR(19,word) ^ SHA512_ROTR(61,word) ^ SHA512_SHR( 6,word))
+
+/*
+ * add "length" to the length
+ */
+static uint64_t addTemp;
+#define SHA384_512AddLength(context, length)                   \
+   (addTemp = context->Length_Low, context->Corrupted =        \
+    ((context->Length_Low += length) < addTemp) &&             \
+    (++context->Length_High == 0) ? 1 : 0)
+
+/* Local Function Prototypes */
+static void SHA384_512Finalize(SHA512Context *context,
+  uint8_t Pad_Byte);
+static void SHA384_512PadMessage(SHA512Context *context,
+  uint8_t Pad_Byte);
+static void SHA384_512ProcessMessageBlock(SHA512Context *context);
+static int SHA384_512Reset(SHA512Context *context, uint64_t H0[]);
+static int SHA384_512ResultN(SHA512Context *context,
+  uint8_t Message_Digest[], int HashSize);
+
+/* Initial Hash Values: FIPS-180-2 sections 5.3.3 and 5.3.4 */
+static uint64_t SHA384_H0[] = {
+    0xCBBB9D5DC1059ED8ll, 0x629A292A367CD507ll, 0x9159015A3070DD17ll,
+    0x152FECD8F70E5939ll, 0x67332667FFC00B31ll, 0x8EB44A8768581511ll,
+    0xDB0C2E0D64F98FA7ll, 0x47B5481DBEFA4FA4ll
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 51]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+};
+static uint64_t SHA512_H0[] = {
+    0x6A09E667F3BCC908ll, 0xBB67AE8584CAA73Bll, 0x3C6EF372FE94F82Bll,
+    0xA54FF53A5F1D36F1ll, 0x510E527FADE682D1ll, 0x9B05688C2B3E6C1Fll,
+    0x1F83D9ABFB41BD6Bll, 0x5BE0CD19137E2179ll
+};
+
+#endif /* USE_32BIT_ONLY */
+
+/*
+ * SHA384Reset
+ *
+ * Description:
+ *   This function will initialize the SHA384Context in preparation
+ *   for computing a new SHA384 message digest.
+ *
+ * Parameters:
+ *   context: [in/out]
+ *     The context to reset.
+ *
+ * Returns:
+ *   sha Error Code.
+ *
+ */
+int SHA384Reset(SHA384Context *context)
+{
+  return SHA384_512Reset(context, SHA384_H0);
+}
+
+/*
+ * SHA384Input
+ *
+ * Description:
+ *   This function accepts an array of octets as the next portion
+ *   of the message.
+ *
+ * Parameters:
+ *   context: [in/out]
+ *     The SHA context to update
+ *   message_array: [in]
+ *     An array of characters representing the next portion of
+ *     the message.
+ *   length: [in]
+ *     The length of the message in message_array
+ *
+ * Returns:
+ *   sha Error Code.
+ *
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 52]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+ */
+int SHA384Input(SHA384Context *context,
+    const uint8_t *message_array, unsigned int length)
+{
+  return SHA512Input(context, message_array, length);
+}
+
+/*
+ * SHA384FinalBits
+ *
+ * Description:
+ *   This function will add in any final bits of the message.
+ *
+ * Parameters:
+ *   context: [in/out]
+ *     The SHA context to update
+ *   message_bits: [in]
+ *     The final bits of the message, in the upper portion of the
+ *     byte. (Use 0b###00000 instead of 0b00000### to input the
+ *     three bits ###.)
+ *   length: [in]
+ *     The number of bits in message_bits, between 1 and 7.
+ *
+ * Returns:
+ *   sha Error Code.
+ *
+ */
+int SHA384FinalBits(SHA384Context *context,
+    const uint8_t message_bits, unsigned int length)
+{
+  return SHA512FinalBits(context, message_bits, length);
+}
+
+/*
+ * SHA384Result
+ *
+ * Description:
+ *   This function will return the 384-bit message
+ *   digest into the Message_Digest array provided by the caller.
+ *   NOTE: The first octet of hash is stored in the 0th element,
+ *      the last octet of hash in the 48th element.
+ *
+ * Parameters:
+ *   context: [in/out]
+ *     The context to use to calculate the SHA hash.
+ *   Message_Digest: [out]
+ *     Where the digest is returned.
+ *
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 53]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+ * Returns:
+ *   sha Error Code.
+ *
+ */
+int SHA384Result(SHA384Context *context,
+    uint8_t Message_Digest[SHA384HashSize])
+{
+  return SHA384_512ResultN(context, Message_Digest, SHA384HashSize);
+}
+
+/*
+ * SHA512Reset
+ *
+ * Description:
+ *   This function will initialize the SHA512Context in preparation
+ *   for computing a new SHA512 message digest.
+ *
+ * Parameters:
+ *   context: [in/out]
+ *     The context to reset.
+ *
+ * Returns:
+ *   sha Error Code.
+ *
+ */
+int SHA512Reset(SHA512Context *context)
+{
+  return SHA384_512Reset(context, SHA512_H0);
+}
+
+/*
+ * SHA512Input
+ *
+ * Description:
+ *   This function accepts an array of octets as the next portion
+ *   of the message.
+ *
+ * Parameters:
+ *   context: [in/out]
+ *     The SHA context to update
+ *   message_array: [in]
+ *     An array of characters representing the next portion of
+ *     the message.
+ *   length: [in]
+ *     The length of the message in message_array
+ *
+ * Returns:
+ *   sha Error Code.
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 54]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+ *
+ */
+int SHA512Input(SHA512Context *context,
+        const uint8_t *message_array,
+        unsigned int length)
+{
+  if (!length)
+    return shaSuccess;
+
+  if (!context || !message_array)
+    return shaNull;
+
+  if (context->Computed) {
+    context->Corrupted = shaStateError;
+    return shaStateError;
+  }
+
+  if (context->Corrupted)
+     return context->Corrupted;
+
+  while (length-- && !context->Corrupted) {
+    context->Message_Block[context->Message_Block_Index++] =
+            (*message_array & 0xFF);
+
+    if (!SHA384_512AddLength(context, 8) &&
+      (context->Message_Block_Index == SHA512_Message_Block_Size))
+      SHA384_512ProcessMessageBlock(context);
+
+    message_array++;
+  }
+
+  return shaSuccess;
+}
+
+/*
+ * SHA512FinalBits
+ *
+ * Description:
+ *   This function will add in any final bits of the message.
+ *
+ * Parameters:
+ *   context: [in/out]
+ *     The SHA context to update
+ *   message_bits: [in]
+ *     The final bits of the message, in the upper portion of the
+ *     byte. (Use 0b###00000 instead of 0b00000### to input the
+ *     three bits ###.)
+ *   length: [in]
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 55]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+ *     The number of bits in message_bits, between 1 and 7.
+ *
+ * Returns:
+ *   sha Error Code.
+ *
+ */
+int SHA512FinalBits(SHA512Context *context,
+    const uint8_t message_bits, unsigned int length)
+{
+  uint8_t masks[8] = {
+      /* 0 0b00000000 */ 0x00, /* 1 0b10000000 */ 0x80,
+      /* 2 0b11000000 */ 0xC0, /* 3 0b11100000 */ 0xE0,
+      /* 4 0b11110000 */ 0xF0, /* 5 0b11111000 */ 0xF8,
+      /* 6 0b11111100 */ 0xFC, /* 7 0b11111110 */ 0xFE
+  };
+  uint8_t markbit[8] = {
+      /* 0 0b10000000 */ 0x80, /* 1 0b01000000 */ 0x40,
+      /* 2 0b00100000 */ 0x20, /* 3 0b00010000 */ 0x10,
+      /* 4 0b00001000 */ 0x08, /* 5 0b00000100 */ 0x04,
+      /* 6 0b00000010 */ 0x02, /* 7 0b00000001 */ 0x01
+  };
+
+  if (!length)
+    return shaSuccess;
+
+  if (!context)
+    return shaNull;
+
+  if ((context->Computed) || (length >= 8) || (length == 0)) {
+    context->Corrupted = shaStateError;
+    return shaStateError;
+  }
+
+  if (context->Corrupted)
+     return context->Corrupted;
+
+  SHA384_512AddLength(context, length);
+  SHA384_512Finalize(context, (uint8_t)
+    ((message_bits & masks[length]) | markbit[length]));
+
+  return shaSuccess;
+}
+
+/*
+ * SHA384_512Finalize
+ *
+ * Description:
+ *   This helper function finishes off the digest calculations.
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 56]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+ *
+ * Parameters:
+ *   context: [in/out]
+ *     The SHA context to update
+ *   Pad_Byte: [in]
+ *     The last byte to add to the digest before the 0-padding
+ *     and length. This will contain the last bits of the message
+ *     followed by another single bit. If the message was an
+ *     exact multiple of 8-bits long, Pad_Byte will be 0x80.
+ *
+ * Returns:
+ *   sha Error Code.
+ *
+ */
+static void SHA384_512Finalize(SHA512Context *context,
+    uint8_t Pad_Byte)
+{
+  int_least16_t i;
+  SHA384_512PadMessage(context, Pad_Byte);
+  /* message may be sensitive, clear it out */
+  for (i = 0; i < SHA512_Message_Block_Size; ++i)
+    context->Message_Block[i] = 0;
+#ifdef USE_32BIT_ONLY    /* and clear length */
+  context->Length[0] = context->Length[1] = 0;
+  context->Length[2] = context->Length[3] = 0;
+#else /* !USE_32BIT_ONLY */
+  context->Length_Low = 0;
+  context->Length_High = 0;
+#endif /* USE_32BIT_ONLY */
+  context->Computed = 1;
+}
+
+/*
+ * SHA512Result
+ *
+ * Description:
+ *   This function will return the 512-bit message
+ *   digest into the Message_Digest array provided by the caller.
+ *   NOTE: The first octet of hash is stored in the 0th element,
+ *      the last octet of hash in the 64th element.
+ *
+ * Parameters:
+ *   context: [in/out]
+ *     The context to use to calculate the SHA hash.
+ *   Message_Digest: [out]
+ *     Where the digest is returned.
+ *
+ * Returns:
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 57]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+ *   sha Error Code.
+ *
+ */
+int SHA512Result(SHA512Context *context,
+    uint8_t Message_Digest[SHA512HashSize])
+{
+  return SHA384_512ResultN(context, Message_Digest, SHA512HashSize);
+}
+
+/*
+ * SHA384_512PadMessage
+ *
+ * Description:
+ *   According to the standard, the message must be padded to an
+ *   even 1024 bits. The first padding bit must be a '1'. The
+ *   last 128 bits represent the length of the original message.
+ *   All bits in between should be 0. This helper function will
+ *   pad the message according to those rules by filling the
+ *   Message_Block array accordingly. When it returns, it can be
+ *   assumed that the message digest has been computed.
+ *
+ * Parameters:
+ *   context: [in/out]
+ *     The context to pad
+ *   Pad_Byte: [in]
+ *     The last byte to add to the digest before the 0-padding
+ *     and length. This will contain the last bits of the message
+ *     followed by another single bit. If the message was an
+ *     exact multiple of 8-bits long, Pad_Byte will be 0x80.
+ *
+ * Returns:
+ *   Nothing.
+ *
+ */
+static void SHA384_512PadMessage(SHA512Context *context,
+    uint8_t Pad_Byte)
+{
+  /*
+   * Check to see if the current message block is too small to hold
+   * the initial padding bits and length. If so, we will pad the
+   * block, process it, and then continue padding into a second
+   * block.
+   */
+  if (context->Message_Block_Index >= (SHA512_Message_Block_Size-16)) {
+    context->Message_Block[context->Message_Block_Index++] = Pad_Byte;
+    while (context->Message_Block_Index < SHA512_Message_Block_Size)
+      context->Message_Block[context->Message_Block_Index++] = 0;
+
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 58]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+    SHA384_512ProcessMessageBlock(context);
+  } else
+    context->Message_Block[context->Message_Block_Index++] = Pad_Byte;
+
+  while (context->Message_Block_Index < (SHA512_Message_Block_Size-16))
+    context->Message_Block[context->Message_Block_Index++] = 0;
+
+  /*
+   * Store the message length as the last 16 octets
+   */
+#ifdef USE_32BIT_ONLY
+  context->Message_Block[112] = (uint8_t)(context->Length[0] >> 24);
+  context->Message_Block[113] = (uint8_t)(context->Length[0] >> 16);
+  context->Message_Block[114] = (uint8_t)(context->Length[0] >> 8);
+  context->Message_Block[115] = (uint8_t)(context->Length[0]);
+  context->Message_Block[116] = (uint8_t)(context->Length[1] >> 24);
+  context->Message_Block[117] = (uint8_t)(context->Length[1] >> 16);
+  context->Message_Block[118] = (uint8_t)(context->Length[1] >> 8);
+  context->Message_Block[119] = (uint8_t)(context->Length[1]);
+
+  context->Message_Block[120] = (uint8_t)(context->Length[2] >> 24);
+  context->Message_Block[121] = (uint8_t)(context->Length[2] >> 16);
+  context->Message_Block[122] = (uint8_t)(context->Length[2] >> 8);
+  context->Message_Block[123] = (uint8_t)(context->Length[2]);
+  context->Message_Block[124] = (uint8_t)(context->Length[3] >> 24);
+  context->Message_Block[125] = (uint8_t)(context->Length[3] >> 16);
+  context->Message_Block[126] = (uint8_t)(context->Length[3] >> 8);
+  context->Message_Block[127] = (uint8_t)(context->Length[3]);
+#else /* !USE_32BIT_ONLY */
+  context->Message_Block[112] = (uint8_t)(context->Length_High >> 56);
+  context->Message_Block[113] = (uint8_t)(context->Length_High >> 48);
+  context->Message_Block[114] = (uint8_t)(context->Length_High >> 40);
+  context->Message_Block[115] = (uint8_t)(context->Length_High >> 32);
+  context->Message_Block[116] = (uint8_t)(context->Length_High >> 24);
+  context->Message_Block[117] = (uint8_t)(context->Length_High >> 16);
+  context->Message_Block[118] = (uint8_t)(context->Length_High >> 8);
+  context->Message_Block[119] = (uint8_t)(context->Length_High);
+
+  context->Message_Block[120] = (uint8_t)(context->Length_Low >> 56);
+  context->Message_Block[121] = (uint8_t)(context->Length_Low >> 48);
+  context->Message_Block[122] = (uint8_t)(context->Length_Low >> 40);
+  context->Message_Block[123] = (uint8_t)(context->Length_Low >> 32);
+  context->Message_Block[124] = (uint8_t)(context->Length_Low >> 24);
+  context->Message_Block[125] = (uint8_t)(context->Length_Low >> 16);
+  context->Message_Block[126] = (uint8_t)(context->Length_Low >> 8);
+  context->Message_Block[127] = (uint8_t)(context->Length_Low);
+#endif /* USE_32BIT_ONLY */
+
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 59]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+  SHA384_512ProcessMessageBlock(context);
+}
+
+/*
+ * SHA384_512ProcessMessageBlock
+ *
+ * Description:
+ *   This helper function will process the next 1024 bits of the
+ *   message stored in the Message_Block array.
+ *
+ * Parameters:
+ *   context: [in/out]
+ *     The SHA context to update
+ *
+ * Returns:
+ *   Nothing.
+ *
+ * Comments:
+ *   Many of the variable names in this code, especially the
+ *   single character names, were used because those were the
+ *   names used in the publication.
+ *
+ *
+ */
+static void SHA384_512ProcessMessageBlock(SHA512Context *context)
+{
+  /* Constants defined in FIPS-180-2, section 4.2.3 */
+#ifdef USE_32BIT_ONLY
+  static const uint32_t K[80*2] = {
+      0x428A2F98, 0xD728AE22, 0x71374491, 0x23EF65CD, 0xB5C0FBCF,
+      0xEC4D3B2F, 0xE9B5DBA5, 0x8189DBBC, 0x3956C25B, 0xF348B538,
+      0x59F111F1, 0xB605D019, 0x923F82A4, 0xAF194F9B, 0xAB1C5ED5,
+      0xDA6D8118, 0xD807AA98, 0xA3030242, 0x12835B01, 0x45706FBE,
+      0x243185BE, 0x4EE4B28C, 0x550C7DC3, 0xD5FFB4E2, 0x72BE5D74,
+      0xF27B896F, 0x80DEB1FE, 0x3B1696B1, 0x9BDC06A7, 0x25C71235,
+      0xC19BF174, 0xCF692694, 0xE49B69C1, 0x9EF14AD2, 0xEFBE4786,
+      0x384F25E3, 0x0FC19DC6, 0x8B8CD5B5, 0x240CA1CC, 0x77AC9C65,
+      0x2DE92C6F, 0x592B0275, 0x4A7484AA, 0x6EA6E483, 0x5CB0A9DC,
+      0xBD41FBD4, 0x76F988DA, 0x831153B5, 0x983E5152, 0xEE66DFAB,
+      0xA831C66D, 0x2DB43210, 0xB00327C8, 0x98FB213F, 0xBF597FC7,
+      0xBEEF0EE4, 0xC6E00BF3, 0x3DA88FC2, 0xD5A79147, 0x930AA725,
+      0x06CA6351, 0xE003826F, 0x14292967, 0x0A0E6E70, 0x27B70A85,
+      0x46D22FFC, 0x2E1B2138, 0x5C26C926, 0x4D2C6DFC, 0x5AC42AED,
+      0x53380D13, 0x9D95B3DF, 0x650A7354, 0x8BAF63DE, 0x766A0ABB,
+      0x3C77B2A8, 0x81C2C92E, 0x47EDAEE6, 0x92722C85, 0x1482353B,
+      0xA2BFE8A1, 0x4CF10364, 0xA81A664B, 0xBC423001, 0xC24B8B70,
+      0xD0F89791, 0xC76C51A3, 0x0654BE30, 0xD192E819, 0xD6EF5218,
+      0xD6990624, 0x5565A910, 0xF40E3585, 0x5771202A, 0x106AA070,
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 60]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+      0x32BBD1B8, 0x19A4C116, 0xB8D2D0C8, 0x1E376C08, 0x5141AB53,
+      0x2748774C, 0xDF8EEB99, 0x34B0BCB5, 0xE19B48A8, 0x391C0CB3,
+      0xC5C95A63, 0x4ED8AA4A, 0xE3418ACB, 0x5B9CCA4F, 0x7763E373,
+      0x682E6FF3, 0xD6B2B8A3, 0x748F82EE, 0x5DEFB2FC, 0x78A5636F,
+      0x43172F60, 0x84C87814, 0xA1F0AB72, 0x8CC70208, 0x1A6439EC,
+      0x90BEFFFA, 0x23631E28, 0xA4506CEB, 0xDE82BDE9, 0xBEF9A3F7,
+      0xB2C67915, 0xC67178F2, 0xE372532B, 0xCA273ECE, 0xEA26619C,
+      0xD186B8C7, 0x21C0C207, 0xEADA7DD6, 0xCDE0EB1E, 0xF57D4F7F,
+      0xEE6ED178, 0x06F067AA, 0x72176FBA, 0x0A637DC5, 0xA2C898A6,
+      0x113F9804, 0xBEF90DAE, 0x1B710B35, 0x131C471B, 0x28DB77F5,
+      0x23047D84, 0x32CAAB7B, 0x40C72493, 0x3C9EBE0A, 0x15C9BEBC,
+      0x431D67C4, 0x9C100D4C, 0x4CC5D4BE, 0xCB3E42B6, 0x597F299C,
+      0xFC657E2A, 0x5FCB6FAB, 0x3AD6FAEC, 0x6C44198C, 0x4A475817
+  };
+  int     t, t2, t8;                  /* Loop counter */
+  uint32_t  temp1[2], temp2[2],       /* Temporary word values */
+        temp3[2], temp4[2], temp5[2];
+  uint32_t  W[2*80];                  /* Word sequence */
+  uint32_t  A[2], B[2], C[2], D[2],   /* Word buffers */
+        E[2], F[2], G[2], H[2];
+
+  /* Initialize the first 16 words in the array W */
+  for (t = t2 = t8 = 0; t < 16; t++, t8 += 8) {
+    W[t2++] = ((((uint32_t)context->Message_Block[t8    ])) << 24) |
+              ((((uint32_t)context->Message_Block[t8 + 1])) << 16) |
+              ((((uint32_t)context->Message_Block[t8 + 2])) << 8) |
+              ((((uint32_t)context->Message_Block[t8 + 3])));
+    W[t2++] = ((((uint32_t)context->Message_Block[t8 + 4])) << 24) |
+              ((((uint32_t)context->Message_Block[t8 + 5])) << 16) |
+              ((((uint32_t)context->Message_Block[t8 + 6])) << 8) |
+              ((((uint32_t)context->Message_Block[t8 + 7])));
+  }
+
+  for (t = 16; t < 80; t++, t2 += 2) {
+    /* W[t] = SHA512_sigma1(W[t-2]) + W[t-7] +
+      SHA512_sigma0(W[t-15]) + W[t-16]; */
+    uint32_t *Wt2 = &W[t2-2*2];
+    uint32_t *Wt7 = &W[t2-7*2];
+    uint32_t *Wt15 = &W[t2-15*2];
+    uint32_t *Wt16 = &W[t2-16*2];
+    SHA512_sigma1(Wt2, temp1);
+    SHA512_ADD(temp1, Wt7, temp2);
+    SHA512_sigma0(Wt15, temp1);
+    SHA512_ADD(temp1, Wt16, temp3);
+    SHA512_ADD(temp2, temp3, &W[t2]);
+  }
+
+  A[0] = context->Intermediate_Hash[0];
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 61]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+  A[1] = context->Intermediate_Hash[1];
+  B[0] = context->Intermediate_Hash[2];
+  B[1] = context->Intermediate_Hash[3];
+  C[0] = context->Intermediate_Hash[4];
+  C[1] = context->Intermediate_Hash[5];
+  D[0] = context->Intermediate_Hash[6];
+  D[1] = context->Intermediate_Hash[7];
+  E[0] = context->Intermediate_Hash[8];
+  E[1] = context->Intermediate_Hash[9];
+  F[0] = context->Intermediate_Hash[10];
+  F[1] = context->Intermediate_Hash[11];
+  G[0] = context->Intermediate_Hash[12];
+  G[1] = context->Intermediate_Hash[13];
+  H[0] = context->Intermediate_Hash[14];
+  H[1] = context->Intermediate_Hash[15];
+
+  for (t = t2 = 0; t < 80; t++, t2 += 2) {
+    /*
+     * temp1 = H + SHA512_SIGMA1(E) + SHA_Ch(E,F,G) + K[t] + W[t];
+     */
+    SHA512_SIGMA1(E,temp1);
+    SHA512_ADD(H, temp1, temp2);
+    SHA_Ch(E,F,G,temp3);
+    SHA512_ADD(temp2, temp3, temp4);
+    SHA512_ADD(&K[t2], &W[t2], temp5);
+    SHA512_ADD(temp4, temp5, temp1);
+    /*
+     * temp2 = SHA512_SIGMA0(A) + SHA_Maj(A,B,C);
+     */
+    SHA512_SIGMA0(A,temp3);
+    SHA_Maj(A,B,C,temp4);
+    SHA512_ADD(temp3, temp4, temp2);
+    H[0] = G[0]; H[1] = G[1];
+    G[0] = F[0]; G[1] = F[1];
+    F[0] = E[0]; F[1] = E[1];
+    SHA512_ADD(D, temp1, E);
+    D[0] = C[0]; D[1] = C[1];
+    C[0] = B[0]; C[1] = B[1];
+    B[0] = A[0]; B[1] = A[1];
+    SHA512_ADD(temp1, temp2, A);
+  }
+
+  SHA512_ADDTO2(&context->Intermediate_Hash[0], A);
+  SHA512_ADDTO2(&context->Intermediate_Hash[2], B);
+  SHA512_ADDTO2(&context->Intermediate_Hash[4], C);
+  SHA512_ADDTO2(&context->Intermediate_Hash[6], D);
+  SHA512_ADDTO2(&context->Intermediate_Hash[8], E);
+  SHA512_ADDTO2(&context->Intermediate_Hash[10], F);
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 62]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+  SHA512_ADDTO2(&context->Intermediate_Hash[12], G);
+  SHA512_ADDTO2(&context->Intermediate_Hash[14], H);
+
+#else /* !USE_32BIT_ONLY */
+  static const uint64_t K[80] = {
+      0x428A2F98D728AE22ll, 0x7137449123EF65CDll, 0xB5C0FBCFEC4D3B2Fll,
+      0xE9B5DBA58189DBBCll, 0x3956C25BF348B538ll, 0x59F111F1B605D019ll,
+      0x923F82A4AF194F9Bll, 0xAB1C5ED5DA6D8118ll, 0xD807AA98A3030242ll,
+      0x12835B0145706FBEll, 0x243185BE4EE4B28Cll, 0x550C7DC3D5FFB4E2ll,
+      0x72BE5D74F27B896Fll, 0x80DEB1FE3B1696B1ll, 0x9BDC06A725C71235ll,
+      0xC19BF174CF692694ll, 0xE49B69C19EF14AD2ll, 0xEFBE4786384F25E3ll,
+      0x0FC19DC68B8CD5B5ll, 0x240CA1CC77AC9C65ll, 0x2DE92C6F592B0275ll,
+      0x4A7484AA6EA6E483ll, 0x5CB0A9DCBD41FBD4ll, 0x76F988DA831153B5ll,
+      0x983E5152EE66DFABll, 0xA831C66D2DB43210ll, 0xB00327C898FB213Fll,
+      0xBF597FC7BEEF0EE4ll, 0xC6E00BF33DA88FC2ll, 0xD5A79147930AA725ll,
+      0x06CA6351E003826Fll, 0x142929670A0E6E70ll, 0x27B70A8546D22FFCll,
+      0x2E1B21385C26C926ll, 0x4D2C6DFC5AC42AEDll, 0x53380D139D95B3DFll,
+      0x650A73548BAF63DEll, 0x766A0ABB3C77B2A8ll, 0x81C2C92E47EDAEE6ll,
+      0x92722C851482353Bll, 0xA2BFE8A14CF10364ll, 0xA81A664BBC423001ll,
+      0xC24B8B70D0F89791ll, 0xC76C51A30654BE30ll, 0xD192E819D6EF5218ll,
+      0xD69906245565A910ll, 0xF40E35855771202All, 0x106AA07032BBD1B8ll,
+      0x19A4C116B8D2D0C8ll, 0x1E376C085141AB53ll, 0x2748774CDF8EEB99ll,
+      0x34B0BCB5E19B48A8ll, 0x391C0CB3C5C95A63ll, 0x4ED8AA4AE3418ACBll,
+      0x5B9CCA4F7763E373ll, 0x682E6FF3D6B2B8A3ll, 0x748F82EE5DEFB2FCll,
+      0x78A5636F43172F60ll, 0x84C87814A1F0AB72ll, 0x8CC702081A6439ECll,
+      0x90BEFFFA23631E28ll, 0xA4506CEBDE82BDE9ll, 0xBEF9A3F7B2C67915ll,
+      0xC67178F2E372532Bll, 0xCA273ECEEA26619Cll, 0xD186B8C721C0C207ll,
+      0xEADA7DD6CDE0EB1Ell, 0xF57D4F7FEE6ED178ll, 0x06F067AA72176FBAll,
+      0x0A637DC5A2C898A6ll, 0x113F9804BEF90DAEll, 0x1B710B35131C471Bll,
+      0x28DB77F523047D84ll, 0x32CAAB7B40C72493ll, 0x3C9EBE0A15C9BEBCll,
+      0x431D67C49C100D4Cll, 0x4CC5D4BECB3E42B6ll, 0x597F299CFC657E2All,
+      0x5FCB6FAB3AD6FAECll, 0x6C44198C4A475817ll
+  };
+  int        t, t8;                   /* Loop counter */
+  uint64_t   temp1, temp2;            /* Temporary word value */
+  uint64_t   W[80];                   /* Word sequence */
+  uint64_t   A, B, C, D, E, F, G, H;  /* Word buffers */
+
+  /*
+   * Initialize the first 16 words in the array W
+   */
+  for (t = t8 = 0; t < 16; t++, t8 += 8)
+    W[t] = ((uint64_t)(context->Message_Block[t8  ]) << 56) |
+           ((uint64_t)(context->Message_Block[t8 + 1]) << 48) |
+           ((uint64_t)(context->Message_Block[t8 + 2]) << 40) |
+           ((uint64_t)(context->Message_Block[t8 + 3]) << 32) |
+           ((uint64_t)(context->Message_Block[t8 + 4]) << 24) |
+           ((uint64_t)(context->Message_Block[t8 + 5]) << 16) |
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 63]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+           ((uint64_t)(context->Message_Block[t8 + 6]) << 8) |
+           ((uint64_t)(context->Message_Block[t8 + 7]));
+
+  for (t = 16; t < 80; t++)
+    W[t] = SHA512_sigma1(W[t-2]) + W[t-7] +
+        SHA512_sigma0(W[t-15]) + W[t-16];
+
+  A = context->Intermediate_Hash[0];
+  B = context->Intermediate_Hash[1];
+  C = context->Intermediate_Hash[2];
+  D = context->Intermediate_Hash[3];
+  E = context->Intermediate_Hash[4];
+  F = context->Intermediate_Hash[5];
+  G = context->Intermediate_Hash[6];
+  H = context->Intermediate_Hash[7];
+
+  for (t = 0; t < 80; t++) {
+    temp1 = H + SHA512_SIGMA1(E) + SHA_Ch(E,F,G) + K[t] + W[t];
+    temp2 = SHA512_SIGMA0(A) + SHA_Maj(A,B,C);
+    H = G;
+    G = F;
+    F = E;
+    E = D + temp1;
+    D = C;
+    C = B;
+    B = A;
+    A = temp1 + temp2;
+  }
+
+  context->Intermediate_Hash[0] += A;
+  context->Intermediate_Hash[1] += B;
+  context->Intermediate_Hash[2] += C;
+  context->Intermediate_Hash[3] += D;
+  context->Intermediate_Hash[4] += E;
+  context->Intermediate_Hash[5] += F;
+  context->Intermediate_Hash[6] += G;
+  context->Intermediate_Hash[7] += H;
+#endif /* USE_32BIT_ONLY */
+
+  context->Message_Block_Index = 0;
+}
+
+/*
+ * SHA384_512Reset
+ *
+ * Description:
+ *   This helper function will initialize the SHA512Context in
+ *   preparation for computing a new SHA384 or SHA512 message
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 64]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+ *   digest.
+ *
+ * Parameters:
+ *   context: [in/out]
+ *     The context to reset.
+ *   H0
+ *     The initial hash value to use.
+ *
+ * Returns:
+ *   sha Error Code.
+ *
+ */
+#ifdef USE_32BIT_ONLY
+static int SHA384_512Reset(SHA512Context *context, uint32_t H0[])
+#else /* !USE_32BIT_ONLY */
+static int SHA384_512Reset(SHA512Context *context, uint64_t H0[])
+#endif /* USE_32BIT_ONLY */
+{
+  int i;
+  if (!context)
+    return shaNull;
+
+  context->Message_Block_Index = 0;
+
+#ifdef USE_32BIT_ONLY
+  context->Length[0] = context->Length[1] = 0;
+  context->Length[2] = context->Length[3] = 0;
+
+  for (i = 0; i < SHA512HashSize/4; i++)
+    context->Intermediate_Hash[i] = H0[i];
+#else /* !USE_32BIT_ONLY */
+  context->Length_High = context->Length_Low = 0;
+
+  for (i = 0; i < SHA512HashSize/8; i++)
+    context->Intermediate_Hash[i] = H0[i];
+#endif /* USE_32BIT_ONLY */
+
+  context->Computed = 0;
+  context->Corrupted = 0;
+
+  return shaSuccess;
+}
+
+/*
+ * SHA384_512ResultN
+ *
+ * Description:
+ *   This helper function will return the 384-bit or 512-bit message
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 65]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+ *   digest into the Message_Digest array provided by the caller.
+ *   NOTE: The first octet of hash is stored in the 0th element,
+ *      the last octet of hash in the 48th/64th element.
+ *
+ * Parameters:
+ *   context: [in/out]
+ *     The context to use to calculate the SHA hash.
+ *   Message_Digest: [out]
+ *     Where the digest is returned.
+ *   HashSize: [in]
+ *     The size of the hash, either 48 or 64.
+ *
+ * Returns:
+ *   sha Error Code.
+ *
+ */
+static int SHA384_512ResultN(SHA512Context *context,
+    uint8_t Message_Digest[], int HashSize)
+{
+  int i;
+
+#ifdef USE_32BIT_ONLY
+  int i2;
+#endif /* USE_32BIT_ONLY */
+
+  if (!context || !Message_Digest)
+    return shaNull;
+
+  if (context->Corrupted)
+    return context->Corrupted;
+
+  if (!context->Computed)
+    SHA384_512Finalize(context, 0x80);
+
+#ifdef USE_32BIT_ONLY
+  for (i = i2 = 0; i < HashSize; ) {
+    Message_Digest[i++]=(uint8_t)(context->Intermediate_Hash[i2]>>24);
+    Message_Digest[i++]=(uint8_t)(context->Intermediate_Hash[i2]>>16);
+    Message_Digest[i++]=(uint8_t)(context->Intermediate_Hash[i2]>>8);
+    Message_Digest[i++]=(uint8_t)(context->Intermediate_Hash[i2++]);
+    Message_Digest[i++]=(uint8_t)(context->Intermediate_Hash[i2]>>24);
+    Message_Digest[i++]=(uint8_t)(context->Intermediate_Hash[i2]>>16);
+    Message_Digest[i++]=(uint8_t)(context->Intermediate_Hash[i2]>>8);
+    Message_Digest[i++]=(uint8_t)(context->Intermediate_Hash[i2++]);
+  }
+#else /* !USE_32BIT_ONLY */
+  for (i = 0; i < HashSize; ++i)
+    Message_Digest[i] = (uint8_t)
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 66]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+      (context->Intermediate_Hash[i>>3] >> 8 * ( 7 - ( i % 8 ) ));
+#endif /* USE_32BIT_ONLY */
+
+  return shaSuccess;
+}
+
+8.2.4.  usha.c
+
+/**************************** usha.c ****************************/
+/******************** See RFC 4634 for details ******************/
+/*
+ *  Description:
+ *     This file implements a unified interface to the SHA algorithms.
+ */
+
+#include "sha.h"
+
+/*
+ *  USHAReset
+ *
+ *  Description:
+ *      This function will initialize the SHA Context in preparation
+ *      for computing a new SHA message digest.
+ *
+ *  Parameters:
+ *      context: [in/out]
+ *          The context to reset.
+ *      whichSha: [in]
+ *          Selects which SHA reset to call
+ *
+ *  Returns:
+ *      sha Error Code.
+ *
+ */
+int USHAReset(USHAContext *ctx, enum SHAversion whichSha)
+{
+  if (ctx) {
+    ctx->whichSha = whichSha;
+    switch (whichSha) {
+      case SHA1:   return SHA1Reset((SHA1Context*)&ctx->ctx);
+      case SHA224: return SHA224Reset((SHA224Context*)&ctx->ctx);
+      case SHA256: return SHA256Reset((SHA256Context*)&ctx->ctx);
+      case SHA384: return SHA384Reset((SHA384Context*)&ctx->ctx);
+      case SHA512: return SHA512Reset((SHA512Context*)&ctx->ctx);
+      default: return shaBadParam;
+    }
+  } else {
+    return shaNull;
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 67]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+  }
+}
+
+/*
+ *  USHAInput
+ *
+ *  Description:
+ *      This function accepts an array of octets as the next portion
+ *      of the message.
+ *
+ *  Parameters:
+ *      context: [in/out]
+ *          The SHA context to update
+ *      message_array: [in]
+ *          An array of characters representing the next portion of
+ *          the message.
+ *      length: [in]
+ *          The length of the message in message_array
+ *
+ *  Returns:
+ *      sha Error Code.
+ *
+ */
+int USHAInput(USHAContext *ctx,
+              const uint8_t *bytes, unsigned int bytecount)
+{
+  if (ctx) {
+    switch (ctx->whichSha) {
+      case SHA1:
+        return SHA1Input((SHA1Context*)&ctx->ctx, bytes, bytecount);
+      case SHA224:
+        return SHA224Input((SHA224Context*)&ctx->ctx, bytes,
+            bytecount);
+      case SHA256:
+        return SHA256Input((SHA256Context*)&ctx->ctx, bytes,
+            bytecount);
+      case SHA384:
+        return SHA384Input((SHA384Context*)&ctx->ctx, bytes,
+            bytecount);
+      case SHA512:
+        return SHA512Input((SHA512Context*)&ctx->ctx, bytes,
+            bytecount);
+      default: return shaBadParam;
+    }
+  } else {
+    return shaNull;
+  }
+}
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 68]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+/*
+ * USHAFinalBits
+ *
+ * Description:
+ *   This function will add in any final bits of the message.
+ *
+ * Parameters:
+ *   context: [in/out]
+ *     The SHA context to update
+ *   message_bits: [in]
+ *     The final bits of the message, in the upper portion of the
+ *     byte. (Use 0b###00000 instead of 0b00000### to input the
+ *     three bits ###.)
+ *   length: [in]
+ *     The number of bits in message_bits, between 1 and 7.
+ *
+ * Returns:
+ *   sha Error Code.
+ */
+int USHAFinalBits(USHAContext *ctx,
+                  const uint8_t bits, unsigned int bitcount)
+{
+  if (ctx) {
+    switch (ctx->whichSha) {
+      case SHA1:
+        return SHA1FinalBits((SHA1Context*)&ctx->ctx, bits, bitcount);
+      case SHA224:
+        return SHA224FinalBits((SHA224Context*)&ctx->ctx, bits,
+            bitcount);
+      case SHA256:
+        return SHA256FinalBits((SHA256Context*)&ctx->ctx, bits,
+            bitcount);
+      case SHA384:
+        return SHA384FinalBits((SHA384Context*)&ctx->ctx, bits,
+            bitcount);
+      case SHA512:
+        return SHA512FinalBits((SHA512Context*)&ctx->ctx, bits,
+            bitcount);
+      default: return shaBadParam;
+    }
+  } else {
+    return shaNull;
+  }
+}
+
+/*
+ * USHAResult
+ *
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 69]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+ * Description:
+ *   This function will return the 160-bit message digest into the
+ *   Message_Digest array provided by the caller.
+ *   NOTE: The first octet of hash is stored in the 0th element,
+ *      the last octet of hash in the 19th element.
+ *
+ * Parameters:
+ *   context: [in/out]
+ *     The context to use to calculate the SHA-1 hash.
+ *   Message_Digest: [out]
+ *     Where the digest is returned.
+ *
+ * Returns:
+ *   sha Error Code.
+ *
+ */
+int USHAResult(USHAContext *ctx,
+               uint8_t Message_Digest[USHAMaxHashSize])
+{
+  if (ctx) {
+    switch (ctx->whichSha) {
+      case SHA1:
+        return SHA1Result((SHA1Context*)&ctx->ctx, Message_Digest);
+      case SHA224:
+        return SHA224Result((SHA224Context*)&ctx->ctx, Message_Digest);
+      case SHA256:
+        return SHA256Result((SHA256Context*)&ctx->ctx, Message_Digest);
+      case SHA384:
+        return SHA384Result((SHA384Context*)&ctx->ctx, Message_Digest);
+      case SHA512:
+        return SHA512Result((SHA512Context*)&ctx->ctx, Message_Digest);
+      default: return shaBadParam;
+    }
+  } else {
+    return shaNull;
+  }
+}
+
+/*
+ * USHABlockSize
+ *
+ * Description:
+ *   This function will return the blocksize for the given SHA
+ *   algorithm.
+ *
+ * Parameters:
+ *   whichSha:
+ *     which SHA algorithm to query
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 70]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+ *
+ * Returns:
+ *   block size
+ *
+ */
+int USHABlockSize(enum SHAversion whichSha)
+{
+  switch (whichSha) {
+    case SHA1:   return SHA1_Message_Block_Size;
+    case SHA224: return SHA224_Message_Block_Size;
+    case SHA256: return SHA256_Message_Block_Size;
+    case SHA384: return SHA384_Message_Block_Size;
+    default:
+    case SHA512: return SHA512_Message_Block_Size;
+  }
+}
+
+/*
+ * USHAHashSize
+ *
+ * Description:
+ *   This function will return the hashsize for the given SHA
+ *   algorithm.
+ *
+ * Parameters:
+ *   whichSha:
+ *     which SHA algorithm to query
+ *
+ * Returns:
+ *   hash size
+ *
+ */
+int USHAHashSize(enum SHAversion whichSha)
+{
+  switch (whichSha) {
+    case SHA1:   return SHA1HashSize;
+    case SHA224: return SHA224HashSize;
+    case SHA256: return SHA256HashSize;
+    case SHA384: return SHA384HashSize;
+    default:
+    case SHA512: return SHA512HashSize;
+  }
+}
+
+/*
+ * USHAHashSizeBits
+ *
+ * Description:
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 71]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+ *   This function will return the hashsize for the given SHA
+ *   algorithm, expressed in bits.
+ *
+ * Parameters:
+ *   whichSha:
+ *     which SHA algorithm to query
+ *
+ * Returns:
+ *   hash size in bits
+ *
+ */
+int USHAHashSizeBits(enum SHAversion whichSha)
+{
+  switch (whichSha) {
+    case SHA1:   return SHA1HashSizeBits;
+    case SHA224: return SHA224HashSizeBits;
+    case SHA256: return SHA256HashSizeBits;
+    case SHA384: return SHA384HashSizeBits;
+    default:
+    case SHA512: return SHA512HashSizeBits;
+  }
+}
+
+8.2.5.  sha-private.h
+
+/*************************** sha-private.h ***************************/
+/********************** See RFC 4634 for details *********************/
+#ifndef _SHA_PRIVATE__H
+#define _SHA_PRIVATE__H
+/*
+ * These definitions are defined in FIPS-180-2, section 4.1.
+ * Ch() and Maj() are defined identically in sections 4.1.1,
+ * 4.1.2 and 4.1.3.
+ *
+ * The definitions used in FIPS-180-2 are as follows:
+ */
+
+#ifndef USE_MODIFIED_MACROS
+#define SHA_Ch(x,y,z)        (((x) & (y)) ^ ((~(x)) & (z)))
+#define SHA_Maj(x,y,z)       (((x) & (y)) ^ ((x) & (z)) ^ ((y) & (z)))
+
+#else /* USE_MODIFIED_MACROS */
+/*
+ * The following definitions are equivalent and potentially faster.
+ */
+
+#define SHA_Ch(x, y, z)      (((x) & ((y) ^ (z))) ^ (z))
+#define SHA_Maj(x, y, z)     (((x) & ((y) | (z))) | ((y) & (z)))
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 72]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+#endif /* USE_MODIFIED_MACROS */
+
+#define SHA_Parity(x, y, z)  ((x) ^ (y) ^ (z))
+
+#endif /* _SHA_PRIVATE__H */
+
+8.3 The HMAC Code
+
+/**************************** hmac.c ****************************/
+/******************** See RFC 4634 for details ******************/
+/*
+ *  Description:
+ *      This file implements the HMAC algorithm (Keyed-Hashing for
+ *      Message Authentication, RFC2104), expressed in terms of the
+ *      various SHA algorithms.
+ */
+
+#include "sha.h"
+
+/*
+ *  hmac
+ *
+ *  Description:
+ *      This function will compute an HMAC message digest.
+ *
+ *  Parameters:
+ *      whichSha: [in]
+ *          One of SHA1, SHA224, SHA256, SHA384, SHA512
+ *      key: [in]
+ *          The secret shared key.
+ *      key_len: [in]
+ *          The length of the secret shared key.
+ *      message_array: [in]
+ *          An array of characters representing the message.
+ *      length: [in]
+ *          The length of the message in message_array
+ *      digest: [out]
+ *          Where the digest is returned.
+ *          NOTE: The length of the digest is determined by
+ *              the value of whichSha.
+ *
+ *  Returns:
+ *      sha Error Code.
+ *
+ */
+int hmac(SHAversion whichSha, const unsigned char *text, int text_len,
+    const unsigned char *key, int key_len,
+    uint8_t digest[USHAMaxHashSize])
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 73]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+{
+  HMACContext ctx;
+  return hmacReset(&ctx, whichSha, key, key_len) ||
+         hmacInput(&ctx, text, text_len) ||
+         hmacResult(&ctx, digest);
+}
+
+/*
+ *  hmacReset
+ *
+ *  Description:
+ *      This function will initialize the hmacContext in preparation
+ *      for computing a new HMAC message digest.
+ *
+ *  Parameters:
+ *      context: [in/out]
+ *          The context to reset.
+ *      whichSha: [in]
+ *          One of SHA1, SHA224, SHA256, SHA384, SHA512
+ *      key: [in]
+ *          The secret shared key.
+ *      key_len: [in]
+ *          The length of the secret shared key.
+ *
+ *  Returns:
+ *      sha Error Code.
+ *
+ */
+int hmacReset(HMACContext *ctx, enum SHAversion whichSha,
+    const unsigned char *key, int key_len)
+{
+  int i, blocksize, hashsize;
+
+  /* inner padding - key XORd with ipad */
+  unsigned char k_ipad[USHA_Max_Message_Block_Size];
+
+  /* temporary buffer when keylen > blocksize */
+  unsigned char tempkey[USHAMaxHashSize];
+
+  if (!ctx) return shaNull;
+
+  blocksize = ctx->blockSize = USHABlockSize(whichSha);
+  hashsize = ctx->hashSize = USHAHashSize(whichSha);
+
+  ctx->whichSha = whichSha;
+
+  /*
+   * If key is longer than the hash blocksize,
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 74]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+   * reset it to key = HASH(key).
+   */
+  if (key_len > blocksize) {
+    USHAContext tctx;
+    int err = USHAReset(&tctx, whichSha) ||
+              USHAInput(&tctx, key, key_len) ||
+              USHAResult(&tctx, tempkey);
+    if (err != shaSuccess) return err;
+
+    key = tempkey;
+    key_len = hashsize;
+  }
+
+  /*
+   * The HMAC transform looks like:
+   *
+   * SHA(K XOR opad, SHA(K XOR ipad, text))
+   *
+   * where K is an n byte key.
+   * ipad is the byte 0x36 repeated blocksize times
+   * opad is the byte 0x5c repeated blocksize times
+   * and text is the data being protected.
+   */
+
+  /* store key into the pads, XOR'd with ipad and opad values */
+  for (i = 0; i < key_len; i++) {
+    k_ipad[i] = key[i] ^ 0x36;
+    ctx->k_opad[i] = key[i] ^ 0x5c;
+  }
+  /* remaining pad bytes are '\0' XOR'd with ipad and opad values */
+  for ( ; i < blocksize; i++) {
+    k_ipad[i] = 0x36;
+    ctx->k_opad[i] = 0x5c;
+  }
+
+  /* perform inner hash */
+  /* init context for 1st pass */
+  return USHAReset(&ctx->shaContext, whichSha) ||
+         /* and start with inner pad */
+         USHAInput(&ctx->shaContext, k_ipad, blocksize);
+}
+
+/*
+ *  hmacInput
+ *
+ *  Description:
+ *      This function accepts an array of octets as the next portion
+ *      of the message.
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 75]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+ *
+ *  Parameters:
+ *      context: [in/out]
+ *          The HMAC context to update
+ *      message_array: [in]
+ *          An array of characters representing the next portion of
+ *          the message.
+ *      length: [in]
+ *          The length of the message in message_array
+ *
+ *  Returns:
+ *      sha Error Code.
+ *
+ */
+int hmacInput(HMACContext *ctx, const unsigned char *text,
+    int text_len)
+{
+  if (!ctx) return shaNull;
+  /* then text of datagram */
+  return USHAInput(&ctx->shaContext, text, text_len);
+}
+
+/*
+ * HMACFinalBits
+ *
+ * Description:
+ *   This function will add in any final bits of the message.
+ *
+ * Parameters:
+ *   context: [in/out]
+ *     The HMAC context to update
+ *   message_bits: [in]
+ *     The final bits of the message, in the upper portion of the
+ *     byte. (Use 0b###00000 instead of 0b00000### to input the
+ *     three bits ###.)
+ *   length: [in]
+ *     The number of bits in message_bits, between 1 and 7.
+ *
+ * Returns:
+ *   sha Error Code.
+ */
+int hmacFinalBits(HMACContext *ctx,
+    const uint8_t bits,
+    unsigned int bitcount)
+{
+  if (!ctx) return shaNull;
+  /* then final bits of datagram */
+  return USHAFinalBits(&ctx->shaContext, bits, bitcount);
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 76]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+}
+
+/*
+ * HMACResult
+ *
+ * Description:
+ *   This function will return the N-byte message digest into the
+ *   Message_Digest array provided by the caller.
+ *   NOTE: The first octet of hash is stored in the 0th element,
+ *      the last octet of hash in the Nth element.
+ *
+ * Parameters:
+ *   context: [in/out]
+ *     The context to use to calculate the HMAC hash.
+ *   digest: [out]
+ *     Where the digest is returned.
+ *   NOTE 2: The length of the hash is determined by the value of
+ *      whichSha that was passed to hmacReset().
+ *
+ * Returns:
+ *   sha Error Code.
+ *
+ */
+int hmacResult(HMACContext *ctx, uint8_t *digest)
+{
+  if (!ctx) return shaNull;
+
+  /* finish up 1st pass */
+  /* (Use digest here as a temporary buffer.) */
+  return USHAResult(&ctx->shaContext, digest) ||
+
+         /* perform outer SHA */
+         /* init context for 2nd pass */
+         USHAReset(&ctx->shaContext, ctx->whichSha) ||
+
+         /* start with outer pad */
+         USHAInput(&ctx->shaContext, ctx->k_opad, ctx->blockSize) ||
+
+         /* then results of 1st hash */
+         USHAInput(&ctx->shaContext, digest, ctx->hashSize) ||
+
+         /* finish up 2nd pass */
+         USHAResult(&ctx->shaContext, digest);
+}
+
+
+
+
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 77]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+8.4.  The Test Driver
+
+   The following code is a main program test driver to exercise the code
+   in sha1.c, sha224-256.c, and sha384-512.c.  The test driver can also
+   be used as a stand-alone program for generating the hashes.
+
+   See also [RFC2202], [RFC4231], and [SHAVS].
+
+/**************************** shatest.c ****************************/
+/********************* See RFC 4634 for details ********************/
+/*
+ *  Description:
+ *    This file will exercise the SHA code performing
+ *      the three tests documented in FIPS PUB 180-2
+ *        (http://csrc.nist.gov/publications/fips/
+ *         fips180-2/fips180-2withchangenotice.pdf)
+ *      one that calls SHAInput with an exact multiple of 512 bits
+ *      the seven tests documented for each algorithm in
+ *        "The Secure Hash Algorithm Validation System (SHAVS)",
+ *        three of which are bit-level tests
+ *        (http://csrc.nist.gov/cryptval/shs/SHAVS.pdf)
+ *
+ *    This file will exercise the HMAC SHA1 code performing
+ *      the seven tests documented in RFCs 2202 and 4231.
+ *
+ *    To run the tests and just see PASSED/FAILED, use the -p option.
+ *
+ *    Other options exercise:
+ *      hashing an arbitrary string
+ *      hashing a file's contents
+ *      a few error test checks
+ *      printing the results in raw format
+ *
+ *  Portability Issues:
+ *    None.
+ *
+ */
+
+#include <stdint.h>
+#include <stdio.h>
+#include <stdlib.h>
+#include <string.h>
+#include <ctype.h>
+#include "sha.h"
+
+static int xgetopt(int argc, char **argv, const char *optstring);
+extern char *xoptarg;
+static int scasecmp(const char *s1, const char *s2);
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 78]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+/*
+ *  Define patterns for testing
+ */
+#define TEST1    "abc"
+#define TEST2_1  \
+        "abcdbcdecdefdefgefghfghighijhijkijkljklmklmnlmnomnopnopq"
+#define TEST2_2a \
+        "abcdefghbcdefghicdefghijdefghijkefghijklfghijklmghijklmn"
+#define TEST2_2b \
+        "hijklmnoijklmnopjklmnopqklmnopqrlmnopqrsmnopqrstnopqrstu"
+#define TEST2_2  TEST2_2a TEST2_2b
+#define TEST3    "a"                            /* times 1000000 */
+#define TEST4a   "01234567012345670123456701234567"
+#define TEST4b   "01234567012345670123456701234567"
+    /* an exact multiple of 512 bits */
+#define TEST4   TEST4a TEST4b                   /* times 10 */
+
+#define TEST7_1 \
+  "\x49\xb2\xae\xc2\x59\x4b\xbe\x3a\x3b\x11\x75\x42\xd9\x4a\xc8"
+#define TEST8_1 \
+  "\x9a\x7d\xfd\xf1\xec\xea\xd0\x6e\xd6\x46\xaa\x55\xfe\x75\x71\x46"
+#define TEST9_1 \
+  "\x65\xf9\x32\x99\x5b\xa4\xce\x2c\xb1\xb4\xa2\xe7\x1a\xe7\x02\x20" \
+  "\xaa\xce\xc8\x96\x2d\xd4\x49\x9c\xbd\x7c\x88\x7a\x94\xea\xaa\x10" \
+  "\x1e\xa5\xaa\xbc\x52\x9b\x4e\x7e\x43\x66\x5a\x5a\xf2\xcd\x03\xfe" \
+  "\x67\x8e\xa6\xa5\x00\x5b\xba\x3b\x08\x22\x04\xc2\x8b\x91\x09\xf4" \
+  "\x69\xda\xc9\x2a\xaa\xb3\xaa\x7c\x11\xa1\xb3\x2a"
+#define TEST10_1 \
+  "\xf7\x8f\x92\x14\x1b\xcd\x17\x0a\xe8\x9b\x4f\xba\x15\xa1\xd5\x9f" \
+  "\x3f\xd8\x4d\x22\x3c\x92\x51\xbd\xac\xbb\xae\x61\xd0\x5e\xd1\x15" \
+  "\xa0\x6a\x7c\xe1\x17\xb7\xbe\xea\xd2\x44\x21\xde\xd9\xc3\x25\x92" \
+  "\xbd\x57\xed\xea\xe3\x9c\x39\xfa\x1f\xe8\x94\x6a\x84\xd0\xcf\x1f" \
+  "\x7b\xee\xad\x17\x13\xe2\xe0\x95\x98\x97\x34\x7f\x67\xc8\x0b\x04" \
+  "\x00\xc2\x09\x81\x5d\x6b\x10\xa6\x83\x83\x6f\xd5\x56\x2a\x56\xca" \
+  "\xb1\xa2\x8e\x81\xb6\x57\x66\x54\x63\x1c\xf1\x65\x66\xb8\x6e\x3b" \
+  "\x33\xa1\x08\xb0\x53\x07\xc0\x0a\xff\x14\xa7\x68\xed\x73\x50\x60" \
+  "\x6a\x0f\x85\xe6\xa9\x1d\x39\x6f\x5b\x5c\xbe\x57\x7f\x9b\x38\x80" \
+  "\x7c\x7d\x52\x3d\x6d\x79\x2f\x6e\xbc\x24\xa4\xec\xf2\xb3\xa4\x27" \
+  "\xcd\xbb\xfb"
+#define TEST7_224 \
+  "\xf0\x70\x06\xf2\x5a\x0b\xea\x68\xcd\x76\xa2\x95\x87\xc2\x8d"
+#define TEST8_224 \
+  "\x18\x80\x40\x05\xdd\x4f\xbd\x15\x56\x29\x9d\x6f\x9d\x93\xdf\x62"
+#define TEST9_224 \
+  "\xa2\xbe\x6e\x46\x32\x81\x09\x02\x94\xd9\xce\x94\x82\x65\x69\x42" \
+  "\x3a\x3a\x30\x5e\xd5\xe2\x11\x6c\xd4\xa4\xc9\x87\xfc\x06\x57\x00" \
+  "\x64\x91\xb1\x49\xcc\xd4\xb5\x11\x30\xac\x62\xb1\x9d\xc2\x48\xc7" \
+  "\x44\x54\x3d\x20\xcd\x39\x52\xdc\xed\x1f\x06\xcc\x3b\x18\xb9\x1f" \
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 79]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+  "\x3f\x55\x63\x3e\xcc\x30\x85\xf4\x90\x70\x60\xd2"
+#define TEST10_224 \
+  "\x55\xb2\x10\x07\x9c\x61\xb5\x3a\xdd\x52\x06\x22\xd1\xac\x97\xd5" \
+  "\xcd\xbe\x8c\xb3\x3a\xa0\xae\x34\x45\x17\xbe\xe4\xd7\xba\x09\xab" \
+  "\xc8\x53\x3c\x52\x50\x88\x7a\x43\xbe\xbb\xac\x90\x6c\x2e\x18\x37" \
+  "\xf2\x6b\x36\xa5\x9a\xe3\xbe\x78\x14\xd5\x06\x89\x6b\x71\x8b\x2a" \
+  "\x38\x3e\xcd\xac\x16\xb9\x61\x25\x55\x3f\x41\x6f\xf3\x2c\x66\x74" \
+  "\xc7\x45\x99\xa9\x00\x53\x86\xd9\xce\x11\x12\x24\x5f\x48\xee\x47" \
+  "\x0d\x39\x6c\x1e\xd6\x3b\x92\x67\x0c\xa5\x6e\xc8\x4d\xee\xa8\x14" \
+  "\xb6\x13\x5e\xca\x54\x39\x2b\xde\xdb\x94\x89\xbc\x9b\x87\x5a\x8b" \
+  "\xaf\x0d\xc1\xae\x78\x57\x36\x91\x4a\xb7\xda\xa2\x64\xbc\x07\x9d" \
+  "\x26\x9f\x2c\x0d\x7e\xdd\xd8\x10\xa4\x26\x14\x5a\x07\x76\xf6\x7c" \
+  "\x87\x82\x73"
+#define TEST7_256 \
+  "\xbe\x27\x46\xc6\xdb\x52\x76\x5f\xdb\x2f\x88\x70\x0f\x9a\x73"
+#define TEST8_256 \
+  "\xe3\xd7\x25\x70\xdc\xdd\x78\x7c\xe3\x88\x7a\xb2\xcd\x68\x46\x52"
+#define TEST9_256 \
+  "\x3e\x74\x03\x71\xc8\x10\xc2\xb9\x9f\xc0\x4e\x80\x49\x07\xef\x7c" \
+  "\xf2\x6b\xe2\x8b\x57\xcb\x58\xa3\xe2\xf3\xc0\x07\x16\x6e\x49\xc1" \
+  "\x2e\x9b\xa3\x4c\x01\x04\x06\x91\x29\xea\x76\x15\x64\x25\x45\x70" \
+  "\x3a\x2b\xd9\x01\xe1\x6e\xb0\xe0\x5d\xeb\xa0\x14\xeb\xff\x64\x06" \
+  "\xa0\x7d\x54\x36\x4e\xff\x74\x2d\xa7\x79\xb0\xb3"
+#define TEST10_256 \
+  "\x83\x26\x75\x4e\x22\x77\x37\x2f\x4f\xc1\x2b\x20\x52\x7a\xfe\xf0" \
+  "\x4d\x8a\x05\x69\x71\xb1\x1a\xd5\x71\x23\xa7\xc1\x37\x76\x00\x00" \
+  "\xd7\xbe\xf6\xf3\xc1\xf7\xa9\x08\x3a\xa3\x9d\x81\x0d\xb3\x10\x77" \
+  "\x7d\xab\x8b\x1e\x7f\x02\xb8\x4a\x26\xc7\x73\x32\x5f\x8b\x23\x74" \
+  "\xde\x7a\x4b\x5a\x58\xcb\x5c\x5c\xf3\x5b\xce\xe6\xfb\x94\x6e\x5b" \
+  "\xd6\x94\xfa\x59\x3a\x8b\xeb\x3f\x9d\x65\x92\xec\xed\xaa\x66\xca" \
+  "\x82\xa2\x9d\x0c\x51\xbc\xf9\x33\x62\x30\xe5\xd7\x84\xe4\xc0\xa4" \
+  "\x3f\x8d\x79\xa3\x0a\x16\x5c\xba\xbe\x45\x2b\x77\x4b\x9c\x71\x09" \
+  "\xa9\x7d\x13\x8f\x12\x92\x28\x96\x6f\x6c\x0a\xdc\x10\x6a\xad\x5a" \
+  "\x9f\xdd\x30\x82\x57\x69\xb2\xc6\x71\xaf\x67\x59\xdf\x28\xeb\x39" \
+  "\x3d\x54\xd6"
+#define TEST7_384 \
+  "\x8b\xc5\x00\xc7\x7c\xee\xd9\x87\x9d\xa9\x89\x10\x7c\xe0\xaa"
+#define TEST8_384 \
+  "\xa4\x1c\x49\x77\x79\xc0\x37\x5f\xf1\x0a\x7f\x4e\x08\x59\x17\x39"
+#define TEST9_384 \
+  "\x68\xf5\x01\x79\x2d\xea\x97\x96\x76\x70\x22\xd9\x3d\xa7\x16\x79" \
+  "\x30\x99\x20\xfa\x10\x12\xae\xa3\x57\xb2\xb1\x33\x1d\x40\xa1\xd0" \
+  "\x3c\x41\xc2\x40\xb3\xc9\xa7\x5b\x48\x92\xf4\xc0\x72\x4b\x68\xc8" \
+  "\x75\x32\x1a\xb8\xcf\xe5\x02\x3b\xd3\x75\xbc\x0f\x94\xbd\x89\xfe" \
+  "\x04\xf2\x97\x10\x5d\x7b\x82\xff\xc0\x02\x1a\xeb\x1c\xcb\x67\x4f" \
+  "\x52\x44\xea\x34\x97\xde\x26\xa4\x19\x1c\x5f\x62\xe5\xe9\xa2\xd8" \
+  "\x08\x2f\x05\x51\xf4\xa5\x30\x68\x26\xe9\x1c\xc0\x06\xce\x1b\xf6" \
+  "\x0f\xf7\x19\xd4\x2f\xa5\x21\xc8\x71\xcd\x23\x94\xd9\x6e\xf4\x46" \
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 80]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+  "\x8f\x21\x96\x6b\x41\xf2\xba\x80\xc2\x6e\x83\xa9"
+#define TEST10_384 \
+  "\x39\x96\x69\xe2\x8f\x6b\x9c\x6d\xbc\xbb\x69\x12\xec\x10\xff\xcf" \
+  "\x74\x79\x03\x49\xb7\xdc\x8f\xbe\x4a\x8e\x7b\x3b\x56\x21\xdb\x0f" \
+  "\x3e\x7d\xc8\x7f\x82\x32\x64\xbb\xe4\x0d\x18\x11\xc9\xea\x20\x61" \
+  "\xe1\xc8\x4a\xd1\x0a\x23\xfa\xc1\x72\x7e\x72\x02\xfc\x3f\x50\x42" \
+  "\xe6\xbf\x58\xcb\xa8\xa2\x74\x6e\x1f\x64\xf9\xb9\xea\x35\x2c\x71" \
+  "\x15\x07\x05\x3c\xf4\xe5\x33\x9d\x52\x86\x5f\x25\xcc\x22\xb5\xe8" \
+  "\x77\x84\xa1\x2f\xc9\x61\xd6\x6c\xb6\xe8\x95\x73\x19\x9a\x2c\xe6" \
+  "\x56\x5c\xbd\xf1\x3d\xca\x40\x38\x32\xcf\xcb\x0e\x8b\x72\x11\xe8" \
+  "\x3a\xf3\x2a\x11\xac\x17\x92\x9f\xf1\xc0\x73\xa5\x1c\xc0\x27\xaa" \
+  "\xed\xef\xf8\x5a\xad\x7c\x2b\x7c\x5a\x80\x3e\x24\x04\xd9\x6d\x2a" \
+  "\x77\x35\x7b\xda\x1a\x6d\xae\xed\x17\x15\x1c\xb9\xbc\x51\x25\xa4" \
+  "\x22\xe9\x41\xde\x0c\xa0\xfc\x50\x11\xc2\x3e\xcf\xfe\xfd\xd0\x96" \
+  "\x76\x71\x1c\xf3\xdb\x0a\x34\x40\x72\x0e\x16\x15\xc1\xf2\x2f\xbc" \
+  "\x3c\x72\x1d\xe5\x21\xe1\xb9\x9b\xa1\xbd\x55\x77\x40\x86\x42\x14" \
+  "\x7e\xd0\x96"
+#define TEST7_512 \
+  "\x08\xec\xb5\x2e\xba\xe1\xf7\x42\x2d\xb6\x2b\xcd\x54\x26\x70"
+#define TEST8_512 \
+  "\x8d\x4e\x3c\x0e\x38\x89\x19\x14\x91\x81\x6e\x9d\x98\xbf\xf0\xa0"
+#define TEST9_512 \
+  "\x3a\xdd\xec\x85\x59\x32\x16\xd1\x61\x9a\xa0\x2d\x97\x56\x97\x0b" \
+  "\xfc\x70\xac\xe2\x74\x4f\x7c\x6b\x27\x88\x15\x10\x28\xf7\xb6\xa2" \
+  "\x55\x0f\xd7\x4a\x7e\x6e\x69\xc2\xc9\xb4\x5f\xc4\x54\x96\x6d\xc3" \
+  "\x1d\x2e\x10\xda\x1f\x95\xce\x02\xbe\xb4\xbf\x87\x65\x57\x4c\xbd" \
+  "\x6e\x83\x37\xef\x42\x0a\xdc\x98\xc1\x5c\xb6\xd5\xe4\xa0\x24\x1b" \
+  "\xa0\x04\x6d\x25\x0e\x51\x02\x31\xca\xc2\x04\x6c\x99\x16\x06\xab" \
+  "\x4e\xe4\x14\x5b\xee\x2f\xf4\xbb\x12\x3a\xab\x49\x8d\x9d\x44\x79" \
+  "\x4f\x99\xcc\xad\x89\xa9\xa1\x62\x12\x59\xed\xa7\x0a\x5b\x6d\xd4" \
+  "\xbd\xd8\x77\x78\xc9\x04\x3b\x93\x84\xf5\x49\x06"
+#define TEST10_512 \
+  "\xa5\x5f\x20\xc4\x11\xaa\xd1\x32\x80\x7a\x50\x2d\x65\x82\x4e\x31" \
+  "\xa2\x30\x54\x32\xaa\x3d\x06\xd3\xe2\x82\xa8\xd8\x4e\x0d\xe1\xde" \
+  "\x69\x74\xbf\x49\x54\x69\xfc\x7f\x33\x8f\x80\x54\xd5\x8c\x26\xc4" \
+  "\x93\x60\xc3\xe8\x7a\xf5\x65\x23\xac\xf6\xd8\x9d\x03\xe5\x6f\xf2" \
+  "\xf8\x68\x00\x2b\xc3\xe4\x31\xed\xc4\x4d\xf2\xf0\x22\x3d\x4b\xb3" \
+  "\xb2\x43\x58\x6e\x1a\x7d\x92\x49\x36\x69\x4f\xcb\xba\xf8\x8d\x95" \
+  "\x19\xe4\xeb\x50\xa6\x44\xf8\xe4\xf9\x5e\xb0\xea\x95\xbc\x44\x65" \
+  "\xc8\x82\x1a\xac\xd2\xfe\x15\xab\x49\x81\x16\x4b\xbb\x6d\xc3\x2f" \
+  "\x96\x90\x87\xa1\x45\xb0\xd9\xcc\x9c\x67\xc2\x2b\x76\x32\x99\x41" \
+  "\x9c\xc4\x12\x8b\xe9\xa0\x77\xb3\xac\xe6\x34\x06\x4e\x6d\x99\x28" \
+  "\x35\x13\xdc\x06\xe7\x51\x5d\x0d\x73\x13\x2e\x9a\x0d\xc6\xd3\xb1" \
+  "\xf8\xb2\x46\xf1\xa9\x8a\x3f\xc7\x29\x41\xb1\xe3\xbb\x20\x98\xe8" \
+  "\xbf\x16\xf2\x68\xd6\x4f\x0b\x0f\x47\x07\xfe\x1e\xa1\xa1\x79\x1b" \
+  "\xa2\xf3\xc0\xc7\x58\xe5\xf5\x51\x86\x3a\x96\xc9\x49\xad\x47\xd7" \
+  "\xfb\x40\xd2"
+#define SHA1_SEED "\xd0\x56\x9c\xb3\x66\x5a\x8a\x43\xeb\x6e\xa2\x3d" \
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 81]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+  "\x75\xa3\xc4\xd2\x05\x4a\x0d\x7d"
+#define SHA224_SEED "\xd0\x56\x9c\xb3\x66\x5a\x8a\x43\xeb\x6e\xa2" \
+  "\x3d\x75\xa3\xc4\xd2\x05\x4a\x0d\x7d\x66\xa9\xca\x99\xc9\xce\xb0" \
+  "\x27"
+#define SHA256_SEED "\xf4\x1e\xce\x26\x13\xe4\x57\x39\x15\x69\x6b" \
+  "\x5a\xdc\xd5\x1c\xa3\x28\xbe\x3b\xf5\x66\xa9\xca\x99\xc9\xce\xb0" \
+  "\x27\x9c\x1c\xb0\xa7"
+#define SHA384_SEED "\x82\x40\xbc\x51\xe4\xec\x7e\xf7\x6d\x18\xe3" \
+  "\x52\x04\xa1\x9f\x51\xa5\x21\x3a\x73\xa8\x1d\x6f\x94\x46\x80\xd3" \
+  "\x07\x59\x48\xb7\xe4\x63\x80\x4e\xa3\xd2\x6e\x13\xea\x82\x0d\x65" \
+  "\xa4\x84\xbe\x74\x53"
+#define SHA512_SEED "\x47\x3f\xf1\xb9\xb3\xff\xdf\xa1\x26\x69\x9a" \
+  "\xc7\xef\x9e\x8e\x78\x77\x73\x09\x58\x24\xc6\x42\x55\x7c\x13\x99" \
+  "\xd9\x8e\x42\x20\x44\x8d\xc3\x5b\x99\xbf\xdd\x44\x77\x95\x43\x92" \
+  "\x4c\x1c\xe9\x3b\xc5\x94\x15\x38\x89\x5d\xb9\x88\x26\x1b\x00\x77" \
+  "\x4b\x12\x27\x20\x39"
+
+#define TESTCOUNT 10
+#define HASHCOUNT 5
+#define RANDOMCOUNT 4
+#define HMACTESTCOUNT 7
+
+#define PRINTNONE 0
+#define PRINTTEXT 1
+#define PRINTRAW 2
+#define PRINTHEX 3
+#define PRINTBASE64 4
+
+#define PRINTPASSFAIL 1
+#define PRINTFAIL 2
+
+#define length(x) (sizeof(x)-1)
+
+/* Test arrays for hashes. */
+struct hash {
+    const char *name;
+    SHAversion whichSha;
+    int hashsize;
+    struct {
+        const char *testarray;
+        int length;
+        long repeatcount;
+        int extrabits;
+        int numberExtrabits;
+        const char *resultarray;
+    } tests[TESTCOUNT];
+    const char *randomtest;
+    const char *randomresults[RANDOMCOUNT];
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 82]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+} hashes[HASHCOUNT] = {
+  { "SHA1", SHA1, SHA1HashSize,
+    {
+      /* 1 */ { TEST1, length(TEST1), 1, 0, 0,
+        "A9993E364706816ABA3E25717850C26C9CD0D89D" },
+      /* 2 */ { TEST2_1, length(TEST2_1), 1, 0, 0,
+        "84983E441C3BD26EBAAE4AA1F95129E5E54670F1" },
+      /* 3 */ { TEST3, length(TEST3), 1000000, 0, 0,
+        "34AA973CD4C4DAA4F61EEB2BDBAD27316534016F" },
+      /* 4 */ { TEST4, length(TEST4), 10, 0, 0,
+        "DEA356A2CDDD90C7A7ECEDC5EBB563934F460452" },
+      /* 5 */ { "", 0, 0, 0x98, 5,
+        "29826B003B906E660EFF4027CE98AF3531AC75BA" },
+      /* 6 */ { "\x5e", 1, 1, 0, 0,
+        "5E6F80A34A9798CAFC6A5DB96CC57BA4C4DB59C2" },
+      /* 7 */ { TEST7_1, length(TEST7_1), 1, 0x80, 3,
+        "6239781E03729919C01955B3FFA8ACB60B988340" },
+      /* 8 */ { TEST8_1, length(TEST8_1), 1, 0, 0,
+        "82ABFF6605DBE1C17DEF12A394FA22A82B544A35" },
+      /* 9 */ { TEST9_1, length(TEST9_1), 1, 0xE0, 3,
+        "8C5B2A5DDAE5A97FC7F9D85661C672ADBF7933D4" },
+      /* 10 */ { TEST10_1, length(TEST10_1), 1, 0, 0,
+        "CB0082C8F197D260991BA6A460E76E202BAD27B3" }
+    }, SHA1_SEED, { "E216836819477C7F78E0D843FE4FF1B6D6C14CD4",
+        "A2DBC7A5B1C6C0A8BCB7AAA41252A6A7D0690DBC",
+        "DB1F9050BB863DFEF4CE37186044E2EEB17EE013",
+        "127FDEDF43D372A51D5747C48FBFFE38EF6CDF7B"
+     } },
+  { "SHA224", SHA224, SHA224HashSize,
+    {
+      /* 1 */ { TEST1, length(TEST1), 1, 0, 0,
+        "23097D223405D8228642A477BDA255B32AADBCE4BDA0B3F7E36C9DA7" },
+      /* 2 */ { TEST2_1, length(TEST2_1), 1, 0, 0,
+        "75388B16512776CC5DBA5DA1FD890150B0C6455CB4F58B1952522525" },
+      /* 3 */ { TEST3, length(TEST3), 1000000, 0, 0,
+        "20794655980C91D8BBB4C1EA97618A4BF03F42581948B2EE4EE7AD67" },
+      /* 4 */ { TEST4, length(TEST4), 10, 0, 0,
+        "567F69F168CD7844E65259CE658FE7AADFA25216E68ECA0EB7AB8262" },
+      /* 5 */ { "", 0, 0, 0x68, 5,
+        "E3B048552C3C387BCAB37F6EB06BB79B96A4AEE5FF27F51531A9551C" },
+      /* 6 */ { "\x07", 1, 1, 0, 0,
+        "00ECD5F138422B8AD74C9799FD826C531BAD2FCABC7450BEE2AA8C2A" },
+      /* 7 */ { TEST7_224, length(TEST7_224), 1, 0xA0, 3,
+        "1B01DB6CB4A9E43DED1516BEB3DB0B87B6D1EA43187462C608137150" },
+      /* 8 */ { TEST8_224, length(TEST8_224), 1, 0, 0,
+        "DF90D78AA78821C99B40BA4C966921ACCD8FFB1E98AC388E56191DB1" },
+      /* 9 */ { TEST9_224, length(TEST9_224), 1, 0xE0, 3,
+        "54BEA6EAB8195A2EB0A7906A4B4A876666300EEFBD1F3B8474F9CD57" },
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 83]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+      /* 10 */ { TEST10_224, length(TEST10_224), 1, 0, 0,
+        "0B31894EC8937AD9B91BDFBCBA294D9ADEFAA18E09305E9F20D5C3A4" }
+    }, SHA224_SEED, { "100966A5B4FDE0B42E2A6C5953D4D7F41BA7CF79FD"
+        "2DF431416734BE", "1DCA396B0C417715DEFAAE9641E10A2E99D55A"
+        "BCB8A00061EB3BE8BD", "1864E627BDB2319973CD5ED7D68DA71D8B"
+        "F0F983D8D9AB32C34ADB34", "A2406481FC1BCAF24DD08E6752E844"
+        "709563FB916227FED598EB621F"
+     } },
+  { "SHA256", SHA256, SHA256HashSize,
+  {
+      /* 1 */ { TEST1, length(TEST1), 1, 0, 0, "BA7816BF8F01CFEA4141"
+        "40DE5DAE2223B00361A396177A9CB410FF61F20015AD" },
+      /* 2 */ { TEST2_1, length(TEST2_1), 1, 0, 0, "248D6A61D20638B8"
+        "E5C026930C3E6039A33CE45964FF2167F6ECEDD419DB06C1" },
+      /* 3 */ { TEST3, length(TEST3), 1000000, 0, 0, "CDC76E5C9914FB92"
+        "81A1C7E284D73E67F1809A48A497200E046D39CCC7112CD0" },
+      /* 4 */ { TEST4, length(TEST4), 10, 0, 0, "594847328451BDFA"
+        "85056225462CC1D867D877FB388DF0CE35F25AB5562BFBB5" },
+      /* 5 */ { "", 0, 0, 0x68, 5, "D6D3E02A31A84A8CAA9718ED6C2057BE"
+        "09DB45E7823EB5079CE7A573A3760F95" },
+      /* 6 */ { "\x19", 1, 1, 0, 0, "68AA2E2EE5DFF96E3355E6C7EE373E3D"
+        "6A4E17F75F9518D843709C0C9BC3E3D4" },
+      /* 7 */ { TEST7_256, length(TEST7_256), 1, 0x60, 3, "77EC1DC8"
+        "9C821FF2A1279089FA091B35B8CD960BCAF7DE01C6A7680756BEB972" },
+      /* 8 */ { TEST8_256, length(TEST8_256), 1, 0, 0, "175EE69B02BA"
+        "9B58E2B0A5FD13819CEA573F3940A94F825128CF4209BEABB4E8" },
+      /* 9 */ { TEST9_256, length(TEST9_256), 1, 0xA0, 3, "3E9AD646"
+        "8BBBAD2AC3C2CDC292E018BA5FD70B960CF1679777FCE708FDB066E9" },
+      /* 10 */ { TEST10_256, length(TEST10_256), 1, 0, 0, "97DBCA7D"
+        "F46D62C8A422C941DD7E835B8AD3361763F7E9B2D95F4F0DA6E1CCBC" },
+    }, SHA256_SEED, { "83D28614D49C3ADC1D6FC05DB5F48037C056F8D2A4CE44"
+        "EC6457DEA5DD797CD1", "99DBE3127EF2E93DD9322D6A07909EB33B6399"
+        "5E529B3F954B8581621BB74D39", "8D4BE295BB64661CA3C7EFD129A2F7"
+        "25B33072DBDDE32385B9A87B9AF88EA76F", "40AF5D3F9716B040DF9408"
+        "E31536B70FF906EC51B00447CA97D7DD97C12411F4"
+    } },
+  { "SHA384", SHA384, SHA384HashSize,
+    {
+      /* 1 */ { TEST1, length(TEST1), 1, 0, 0,
+        "CB00753F45A35E8BB5A03D699AC65007272C32AB0EDED163"
+        "1A8B605A43FF5BED8086072BA1E7CC2358BAECA134C825A7" },
+      /* 2 */ { TEST2_2, length(TEST2_2), 1, 0, 0,
+        "09330C33F71147E83D192FC782CD1B4753111B173B3B05D2"
+        "2FA08086E3B0F712FCC7C71A557E2DB966C3E9FA91746039" },
+      /* 3 */ { TEST3, length(TEST3), 1000000, 0, 0,
+        "9D0E1809716474CB086E834E310A4A1CED149E9C00F24852"
+        "7972CEC5704C2A5B07B8B3DC38ECC4EBAE97DDD87F3D8985" },
+      /* 4 */ { TEST4, length(TEST4), 10, 0, 0,
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 84]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+        "2FC64A4F500DDB6828F6A3430B8DD72A368EB7F3A8322A70"
+        "BC84275B9C0B3AB00D27A5CC3C2D224AA6B61A0D79FB4596" },
+      /* 5 */ { "", 0, 0, 0x10, 5,
+        "8D17BE79E32B6718E07D8A603EB84BA0478F7FCFD1BB9399"
+        "5F7D1149E09143AC1FFCFC56820E469F3878D957A15A3FE4" },
+      /* 6 */ { "\xb9", 1, 1, 0, 0,
+        "BC8089A19007C0B14195F4ECC74094FEC64F01F90929282C"
+        "2FB392881578208AD466828B1C6C283D2722CF0AD1AB6938" },
+      /* 7 */ { TEST7_384, length(TEST7_384), 1, 0xA0, 3,
+        "D8C43B38E12E7C42A7C9B810299FD6A770BEF30920F17532"
+        "A898DE62C7A07E4293449C0B5FA70109F0783211CFC4BCE3" },
+      /* 8 */ { TEST8_384, length(TEST8_384), 1, 0, 0,
+        "C9A68443A005812256B8EC76B00516F0DBB74FAB26D66591"
+        "3F194B6FFB0E91EA9967566B58109CBC675CC208E4C823F7" },
+      /* 9 */ { TEST9_384, length(TEST9_384), 1, 0xE0, 3,
+        "5860E8DE91C21578BB4174D227898A98E0B45C4C760F0095"
+        "49495614DAEDC0775D92D11D9F8CE9B064EEAC8DAFC3A297" },
+      /* 10 */ { TEST10_384, length(TEST10_384), 1, 0, 0,
+        "4F440DB1E6EDD2899FA335F09515AA025EE177A79F4B4AAF"
+        "38E42B5C4DE660F5DE8FB2A5B2FBD2A3CBFFD20CFF1288C0" }
+    }, SHA384_SEED, { "CE44D7D63AE0C91482998CF662A51EC80BF6FC68661A3C"
+        "57F87566112BD635A743EA904DEB7D7A42AC808CABE697F38F", "F9C6D2"
+        "61881FEE41ACD39E67AA8D0BAD507C7363EB67E2B81F45759F9C0FD7B503"
+        "DF1A0B9E80BDE7BC333D75B804197D", "D96512D8C9F4A7A4967A366C01"
+        "C6FD97384225B58343A88264847C18E4EF8AB7AEE4765FFBC3E30BD485D3"
+        "638A01418F", "0CA76BD0813AF1509E170907A96005938BC985628290B2"
+        "5FEF73CF6FAD68DDBA0AC8920C94E0541607B0915A7B4457F7"
+    } },
+  { "SHA512", SHA512, SHA512HashSize,
+    {
+      /* 1 */ { TEST1, length(TEST1), 1, 0, 0,
+        "DDAF35A193617ABACC417349AE20413112E6FA4E89A97EA2"
+        "0A9EEEE64B55D39A2192992A274FC1A836BA3C23A3FEEBBD"
+        "454D4423643CE80E2A9AC94FA54CA49F" },
+      /* 2 */ { TEST2_2, length(TEST2_2), 1, 0, 0,
+        "8E959B75DAE313DA8CF4F72814FC143F8F7779C6EB9F7FA1"
+        "7299AEADB6889018501D289E4900F7E4331B99DEC4B5433A"
+        "C7D329EEB6DD26545E96E55B874BE909" },
+       /* 3 */ { TEST3, length(TEST3), 1000000, 0, 0,
+        "E718483D0CE769644E2E42C7BC15B4638E1F98B13B204428"
+        "5632A803AFA973EBDE0FF244877EA60A4CB0432CE577C31B"
+        "EB009C5C2C49AA2E4EADB217AD8CC09B" },
+      /* 4 */ { TEST4, length(TEST4), 10, 0, 0,
+        "89D05BA632C699C31231DED4FFC127D5A894DAD412C0E024"
+        "DB872D1ABD2BA8141A0F85072A9BE1E2AA04CF33C765CB51"
+        "0813A39CD5A84C4ACAA64D3F3FB7BAE9" },
+      /* 5 */ { "", 0, 0, 0xB0, 5,
+        "D4EE29A9E90985446B913CF1D1376C836F4BE2C1CF3CADA0"
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 85]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+        "720A6BF4857D886A7ECB3C4E4C0FA8C7F95214E41DC1B0D2"
+        "1B22A84CC03BF8CE4845F34DD5BDBAD4" },
+      /* 6 */ { "\xD0", 1, 1, 0, 0,
+        "9992202938E882E73E20F6B69E68A0A7149090423D93C81B"
+        "AB3F21678D4ACEEEE50E4E8CAFADA4C85A54EA8306826C4A"
+        "D6E74CECE9631BFA8A549B4AB3FBBA15" },
+      /* 7 */ { TEST7_512, length(TEST7_512), 1, 0x80, 3,
+        "ED8DC78E8B01B69750053DBB7A0A9EDA0FB9E9D292B1ED71"
+        "5E80A7FE290A4E16664FD913E85854400C5AF05E6DAD316B"
+        "7359B43E64F8BEC3C1F237119986BBB6" },
+      /* 8 */ { TEST8_512, length(TEST8_512), 1, 0, 0,
+        "CB0B67A4B8712CD73C9AABC0B199E9269B20844AFB75ACBD"
+        "D1C153C9828924C3DDEDAAFE669C5FDD0BC66F630F677398"
+        "8213EB1B16F517AD0DE4B2F0C95C90F8" },
+      /* 9 */ { TEST9_512, length(TEST9_512), 1, 0x80, 3,
+        "32BA76FC30EAA0208AEB50FFB5AF1864FDBF17902A4DC0A6"
+        "82C61FCEA6D92B783267B21080301837F59DE79C6B337DB2"
+        "526F8A0A510E5E53CAFED4355FE7C2F1" },
+      /* 10 */ { TEST10_512, length(TEST10_512), 1, 0, 0,
+        "C665BEFB36DA189D78822D10528CBF3B12B3EEF726039909"
+        "C1A16A270D48719377966B957A878E720584779A62825C18"
+        "DA26415E49A7176A894E7510FD1451F5" }
+    }, SHA512_SEED, { "2FBB1E7E00F746BA514FBC8C421F36792EC0E11FF5EFC3"
+        "78E1AB0C079AA5F0F66A1E3EDBAEB4F9984BE14437123038A452004A5576"
+        "8C1FD8EED49E4A21BEDCD0", "25CBE5A4F2C7B1D7EF07011705D50C62C5"
+        "000594243EAFD1241FC9F3D22B58184AE2FEE38E171CF8129E29459C9BC2"
+        "EF461AF5708887315F15419D8D17FE7949", "5B8B1F2687555CE2D7182B"
+        "92E5C3F6C36547DA1C13DBB9EA4F73EA4CBBAF89411527906D35B1B06C1B"
+        "6A8007D05EC66DF0A406066829EAB618BDE3976515AAFC", "46E36B007D"
+        "19876CDB0B29AD074FE3C08CDD174D42169D6ABE5A1414B6E79707DF5877"
+        "6A98091CF431854147BB6D3C66D43BFBC108FD715BDE6AA127C2B0E79F"
+    }
+  }
+};
+
+/* Test arrays for HMAC. */
+struct hmachash {
+    const char *keyarray[5];
+    int keylength[5];
+    const char *dataarray[5];
+    int datalength[5];
+    const char *resultarray[5];
+    int resultlength[5];
+} hmachashes[HMACTESTCOUNT] = {
+  { /* 1 */ {
+      "\x0b\x0b\x0b\x0b\x0b\x0b\x0b\x0b\x0b\x0b\x0b\x0b\x0b\x0b\x0b"
+      "\x0b\x0b\x0b\x0b\x0b"
+    }, { 20 }, {
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 86]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+      "\x48\x69\x20\x54\x68\x65\x72\x65" /* "Hi There" */
+    }, { 8 }, {
+      /* HMAC-SHA-1 */
+      "B617318655057264E28BC0B6FB378C8EF146BE00",
+      /* HMAC-SHA-224 */
+      "896FB1128ABBDF196832107CD49DF33F47B4B1169912BA4F53684B22",
+      /* HMAC-SHA-256 */
+      "B0344C61D8DB38535CA8AFCEAF0BF12B881DC200C9833DA726E9376C2E32"
+      "CFF7",
+      /* HMAC-SHA-384 */
+      "AFD03944D84895626B0825F4AB46907F15F9DADBE4101EC682AA034C7CEB"
+      "C59CFAEA9EA9076EDE7F4AF152E8B2FA9CB6",
+      /* HMAC-SHA-512 */
+      "87AA7CDEA5EF619D4FF0B4241A1D6CB02379F4E2CE4EC2787AD0B30545E1"
+      "7CDEDAA833B7D6B8A702038B274EAEA3F4E4BE9D914EEB61F1702E696C20"
+      "3A126854"
+    }, { SHA1HashSize, SHA224HashSize, SHA256HashSize,
+      SHA384HashSize, SHA512HashSize }
+  },
+  { /* 2 */ {
+      "\x4a\x65\x66\x65" /* "Jefe" */
+    }, { 4 }, {
+      "\x77\x68\x61\x74\x20\x64\x6f\x20\x79\x61\x20\x77\x61\x6e\x74"
+      "\x20\x66\x6f\x72\x20\x6e\x6f\x74\x68\x69\x6e\x67\x3f"
+      /* "what do ya want for nothing?" */
+    }, { 28 }, {
+      /* HMAC-SHA-1 */
+      "EFFCDF6AE5EB2FA2D27416D5F184DF9C259A7C79",
+      /* HMAC-SHA-224 */
+      "A30E01098BC6DBBF45690F3A7E9E6D0F8BBEA2A39E6148008FD05E44",
+      /* HMAC-SHA-256 */
+      "5BDCC146BF60754E6A042426089575C75A003F089D2739839DEC58B964EC"
+      "3843",
+      /* HMAC-SHA-384 */
+      "AF45D2E376484031617F78D2B58A6B1B9C7EF464F5A01B47E42EC3736322"
+      "445E8E2240CA5E69E2C78B3239ECFAB21649",
+      /* HMAC-SHA-512 */
+      "164B7A7BFCF819E2E395FBE73B56E0A387BD64222E831FD610270CD7EA25"
+      "05549758BF75C05A994A6D034F65F8F0E6FDCAEAB1A34D4A6B4B636E070A"
+      "38BCE737"
+    }, { SHA1HashSize, SHA224HashSize, SHA256HashSize,
+      SHA384HashSize, SHA512HashSize }
+  },
+  { /* 3 */
+    {
+      "\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa"
+      "\xaa\xaa\xaa\xaa\xaa"
+    }, { 20 }, {
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 87]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+      "\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd"
+      "\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd"
+      "\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd\xdd"
+      "\xdd\xdd\xdd\xdd\xdd"
+    }, { 50 }, {
+      /* HMAC-SHA-1 */
+      "125D7342B9AC11CD91A39AF48AA17B4F63F175D3",
+      /* HMAC-SHA-224 */
+      "7FB3CB3588C6C1F6FFA9694D7D6AD2649365B0C1F65D69D1EC8333EA",
+      /* HMAC-SHA-256 */
+      "773EA91E36800E46854DB8EBD09181A72959098B3EF8C122D9635514CED5"
+      "65FE",
+      /* HMAC-SHA-384 */
+      "88062608D3E6AD8A0AA2ACE014C8A86F0AA635D947AC9FEBE83EF4E55966"
+      "144B2A5AB39DC13814B94E3AB6E101A34F27",
+      /* HMAC-SHA-512 */
+      "FA73B0089D56A284EFB0F0756C890BE9B1B5DBDD8EE81A3655F83E33B227"
+      "9D39BF3E848279A722C806B485A47E67C807B946A337BEE8942674278859"
+      "E13292FB"
+    }, { SHA1HashSize, SHA224HashSize, SHA256HashSize,
+      SHA384HashSize, SHA512HashSize }
+  },
+  { /* 4 */ {
+      "\x01\x02\x03\x04\x05\x06\x07\x08\x09\x0a\x0b\x0c\x0d\x0e\x0f"
+      "\x10\x11\x12\x13\x14\x15\x16\x17\x18\x19"
+    }, { 25 }, {
+      "\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd"
+      "\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd"
+      "\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd\xcd"
+      "\xcd\xcd\xcd\xcd\xcd"
+    }, { 50 }, {
+      /* HMAC-SHA-1 */
+      "4C9007F4026250C6BC8414F9BF50C86C2D7235DA",
+      /* HMAC-SHA-224 */
+      "6C11506874013CAC6A2ABC1BB382627CEC6A90D86EFC012DE7AFEC5A",
+      /* HMAC-SHA-256 */
+      "82558A389A443C0EA4CC819899F2083A85F0FAA3E578F8077A2E3FF46729"
+      "665B",
+      /* HMAC-SHA-384 */
+      "3E8A69B7783C25851933AB6290AF6CA77A9981480850009CC5577C6E1F57"
+      "3B4E6801DD23C4A7D679CCF8A386C674CFFB",
+      /* HMAC-SHA-512 */
+      "B0BA465637458C6990E5A8C5F61D4AF7E576D97FF94B872DE76F8050361E"
+      "E3DBA91CA5C11AA25EB4D679275CC5788063A5F19741120C4F2DE2ADEBEB"
+      "10A298DD"
+    }, { SHA1HashSize, SHA224HashSize, SHA256HashSize,
+      SHA384HashSize, SHA512HashSize }
+  },
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 88]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+  { /* 5 */ {
+      "\x0c\x0c\x0c\x0c\x0c\x0c\x0c\x0c\x0c\x0c\x0c\x0c\x0c\x0c\x0c"
+      "\x0c\x0c\x0c\x0c\x0c"
+    }, { 20 }, {
+      "Test With Truncation"
+    }, { 20 }, {
+      /* HMAC-SHA-1 */
+      "4C1A03424B55E07FE7F27BE1",
+      /* HMAC-SHA-224 */
+      "0E2AEA68A90C8D37C988BCDB9FCA6FA8",
+      /* HMAC-SHA-256 */
+      "A3B6167473100EE06E0C796C2955552B",
+      /* HMAC-SHA-384 */
+      "3ABF34C3503B2A23A46EFC619BAEF897",
+      /* HMAC-SHA-512 */
+      "415FAD6271580A531D4179BC891D87A6"
+    }, { 12, 16, 16, 16, 16 }
+  },
+  { /* 6 */ {
+      "\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa"
+      "\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa"
+      "\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa"
+      "\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa"
+      "\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa"
+      "\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa"
+      "\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa"
+      "\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa"
+      "\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa"
+    }, { 80, 131 }, {
+      "Test Using Larger Than Block-Size Key - Hash Key First"
+    }, { 54 }, {
+      /* HMAC-SHA-1 */
+      "AA4AE5E15272D00E95705637CE8A3B55ED402112",
+      /* HMAC-SHA-224 */
+      "95E9A0DB962095ADAEBE9B2D6F0DBCE2D499F112F2D2B7273FA6870E",
+      /* HMAC-SHA-256 */
+      "60E431591EE0B67F0D8A26AACBF5B77F8E0BC6213728C5140546040F0EE3"
+      "7F54",
+      /* HMAC-SHA-384 */
+      "4ECE084485813E9088D2C63A041BC5B44F9EF1012A2B588F3CD11F05033A"
+      "C4C60C2EF6AB4030FE8296248DF163F44952",
+      /* HMAC-SHA-512 */
+      "80B24263C7C1A3EBB71493C1DD7BE8B49B46D1F41B4AEEC1121B013783F8"
+      "F3526B56D037E05F2598BD0FD2215D6A1E5295E64F73F63F0AEC8B915A98"
+      "5D786598"
+    }, { SHA1HashSize, SHA224HashSize, SHA256HashSize,
+      SHA384HashSize, SHA512HashSize }
+  },
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 89]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+  { /* 7 */ {
+      "\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa"
+      "\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa"
+      "\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa"
+      "\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa"
+      "\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa"
+      "\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa"
+      "\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa"
+      "\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa"
+      "\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa\xaa"
+    }, { 80, 131 }, {
+      "Test Using Larger Than Block-Size Key and "
+      "Larger Than One Block-Size Data",
+      "\x54\x68\x69\x73\x20\x69\x73\x20\x61\x20\x74\x65\x73\x74\x20"
+      "\x75\x73\x69\x6e\x67\x20\x61\x20\x6c\x61\x72\x67\x65\x72\x20"
+      "\x74\x68\x61\x6e\x20\x62\x6c\x6f\x63\x6b\x2d\x73\x69\x7a\x65"
+      "\x20\x6b\x65\x79\x20\x61\x6e\x64\x20\x61\x20\x6c\x61\x72\x67"
+      "\x65\x72\x20\x74\x68\x61\x6e\x20\x62\x6c\x6f\x63\x6b\x2d\x73"
+      "\x69\x7a\x65\x20\x64\x61\x74\x61\x2e\x20\x54\x68\x65\x20\x6b"
+      "\x65\x79\x20\x6e\x65\x65\x64\x73\x20\x74\x6f\x20\x62\x65\x20"
+      "\x68\x61\x73\x68\x65\x64\x20\x62\x65\x66\x6f\x72\x65\x20\x62"
+      "\x65\x69\x6e\x67\x20\x75\x73\x65\x64\x20\x62\x79\x20\x74\x68"
+      "\x65\x20\x48\x4d\x41\x43\x20\x61\x6c\x67\x6f\x72\x69\x74\x68"
+      "\x6d\x2e"
+      /* "This is a test using a larger than block-size key and a "
+          "larger than block-size data. The key needs to be hashed "
+          "before being used by the HMAC algorithm." */
+    }, { 73, 152 }, {
+      /* HMAC-SHA-1 */
+      "E8E99D0F45237D786D6BBAA7965C7808BBFF1A91",
+      /* HMAC-SHA-224 */
+      "3A854166AC5D9F023F54D517D0B39DBD946770DB9C2B95C9F6F565D1",
+      /* HMAC-SHA-256 */
+      "9B09FFA71B942FCB27635FBCD5B0E944BFDC63644F0713938A7F51535C3A"
+      "35E2",
+      /* HMAC-SHA-384 */
+      "6617178E941F020D351E2F254E8FD32C602420FEB0B8FB9ADCCEBB82461E"
+      "99C5A678CC31E799176D3860E6110C46523E",
+      /* HMAC-SHA-512 */
+      "E37B6A775DC87DBAA4DFA9F96E5E3FFDDEBD71F8867289865DF5A32D20CD"
+      "C944B6022CAC3C4982B10D5EEB55C3E4DE15134676FB6DE0446065C97440"
+      "FA8C6A58"
+    }, { SHA1HashSize, SHA224HashSize, SHA256HashSize,
+      SHA384HashSize, SHA512HashSize }
+  }
+};
+
+/*
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 90]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+ * Check the hash value against the expected string, expressed in hex
+ */
+static const char hexdigits[] = "0123456789ABCDEF";
+int checkmatch(const unsigned char *hashvalue,
+  const char *hexstr, int hashsize)
+{
+  int i;
+  for (i = 0; i < hashsize; ++i) {
+    if (*hexstr++ != hexdigits[(hashvalue[i] >> 4) & 0xF])
+      return 0;
+    if (*hexstr++ != hexdigits[hashvalue[i] & 0xF]) return 0;
+  }
+  return 1;
+}
+
+/*
+ * Print the string, converting non-printable characters to "."
+ */
+void printstr(const char *str, int len)
+{
+  for ( ; len-- > 0; str++)
+    putchar(isprint((unsigned char)*str) ? *str : '.');
+}
+
+/*
+ * Print the string, converting non-printable characters to hex "## ".
+ */
+void printxstr(const char *str, int len)
+{
+  for ( ; len-- > 0; str++)
+    printf("%c%c ", hexdigits[(*str >> 4) & 0xF],
+      hexdigits[*str & 0xF]);
+}
+
+/*
+ * Print a usage message.
+ */
+void usage(const char *argv0)
+{
+  fprintf(stderr,
+    "Usage:\n"
+    "Common options: [-h hash] [-w|-x] [-H]\n"
+    "Standard tests:\n"
+      "\t%s [-m] [-l loopcount] [-t test#] [-e]\n"
+      "\t\t[-r randomseed] [-R randomloop-count] "
+        "[-p] [-P|-X]\n"
+    "Hash a string:\n"
+      "\t%s [-S expectedresult] -s hashstr [-k key]\n"
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 91]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+    "Hash a file:\n"
+      "\t%s [-S expectedresult] -f file [-k key]\n"
+    "Hash a file, ignoring whitespace:\n"
+      "\t%s [-S expectedresult] -F file [-k key]\n"
+    "Additional bits to add in: [-B bitcount -b bits]\n"
+    "-h\thash to test: "
+      "0|SHA1, 1|SHA224, 2|SHA256, 3|SHA384, 4|SHA512\n"
+    "-m\tperform hmac test\n"
+    "-k\tkey for hmac test\n"
+    "-t\ttest case to run, 1-10\n"
+    "-l\thow many times to run the test\n"
+    "-e\ttest error returns\n"
+    "-p\tdo not print results\n"
+    "-P\tdo not print PASSED/FAILED\n"
+    "-X\tprint FAILED, but not PASSED\n"
+    "-r\tseed for random test\n"
+    "-R\thow many times to run random test\n"
+    "-s\tstring to hash\n"
+    "-S\texpected result of hashed string, in hex\n"
+    "-w\toutput hash in raw format\n"
+    "-x\toutput hash in hex format\n"
+    "-B\t# extra bits to add in after string or file input\n"
+    "-b\textra bits to add (high order bits of #, 0# or 0x#)\n"
+    "-H\tinput hashstr or randomseed is in hex\n"
+    , argv0, argv0, argv0, argv0);
+  exit(1);
+}
+
+/*
+ * Print the results and PASS/FAIL.
+ */
+void printResult(uint8_t *Message_Digest, int hashsize,
+    const char *hashname, const char *testtype, const char *testname,
+    const char *resultarray, int printResults, int printPassFail)
+{
+  int i, k;
+  if (printResults == PRINTTEXT) {
+    putchar('\t');
+    for (i = 0; i < hashsize ; ++i) {
+      putchar(hexdigits[(Message_Digest[i] >> 4) & 0xF]);
+      putchar(hexdigits[Message_Digest[i] & 0xF]);
+      putchar(' ');
+    }
+    putchar('\n');
+  } else if (printResults == PRINTRAW) {
+    fwrite(Message_Digest, 1, hashsize, stdout);
+  } else if (printResults == PRINTHEX) {
+    for (i = 0; i < hashsize ; ++i) {
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 92]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+      putchar(hexdigits[(Message_Digest[i] >> 4) & 0xF]);
+      putchar(hexdigits[Message_Digest[i] & 0xF]);
+    }
+    putchar('\n');
+  }
+
+  if (printResults && resultarray) {
+    printf("    Should match:\n\t");
+    for (i = 0, k = 0; i < hashsize; i++, k += 2) {
+      putchar(resultarray[k]);
+      putchar(resultarray[k+1]);
+      putchar(' ');
+    }
+    putchar('\n');
+  }
+
+  if (printPassFail && resultarray) {
+    int ret = checkmatch(Message_Digest, resultarray, hashsize);
+    if ((printPassFail == PRINTPASSFAIL) || !ret)
+      printf("%s %s %s: %s\n", hashname, testtype, testname,
+        ret ? "PASSED" : "FAILED");
+  }
+}
+
+/*
+ * Exercise a hash series of functions. The input is the testarray,
+ * repeated repeatcount times, followed by the extrabits. If the
+ * result is known, it is in resultarray in uppercase hex.
+ */
+int hash(int testno, int loopno, int hashno,
+  const char *testarray, int length, long repeatcount,
+  int numberExtrabits, int extrabits, const unsigned char *keyarray,
+  int keylen, const char *resultarray, int hashsize, int printResults,
+  int printPassFail)
+{
+  USHAContext sha;
+  HMACContext hmac;
+  int err, i;
+  uint8_t Message_Digest[USHAMaxHashSize];
+  char buf[20];
+
+  if (printResults == PRINTTEXT) {
+    printf("\nTest %d: Iteration %d, Repeat %ld\n\t'", testno+1,
+      loopno, repeatcount);
+    printstr(testarray, length);
+    printf("'\n\t'");
+    printxstr(testarray, length);
+    printf("'\n");
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 93]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+    printf("    Length=%d bytes (%d bits), ", length, length * 8);
+    printf("ExtraBits %d: %2.2x\n", numberExtrabits, extrabits);
+  }
+
+  memset(&sha, '\343', sizeof(sha)); /* force bad data into struct */
+  memset(&hmac, '\343', sizeof(hmac));
+  err = keyarray ? hmacReset(&hmac, hashes[hashno].whichSha,
+                             keyarray, keylen) :
+                   USHAReset(&sha, hashes[hashno].whichSha);
+  if (err != shaSuccess) {
+    fprintf(stderr, "hash(): %sReset Error %d.\n",
+            keyarray ? "hmac" : "sha", err);
+    return err;
+  }
+
+  for (i = 0; i < repeatcount; ++i) {
+    err = keyarray ? hmacInput(&hmac, (const uint8_t *) testarray,
+                               length) :
+                     USHAInput(&sha, (const uint8_t *) testarray,
+                               length);
+    if (err != shaSuccess) {
+      fprintf(stderr, "hash(): %sInput Error %d.\n",
+              keyarray ? "hmac" : "sha", err);
+      return err;
+    }
+  }
+
+  if (numberExtrabits > 0) {
+    err = keyarray ? hmacFinalBits(&hmac, (uint8_t) extrabits,
+                                   numberExtrabits) :
+                     USHAFinalBits(&sha, (uint8_t) extrabits,
+                                   numberExtrabits);
+    if (err != shaSuccess) {
+      fprintf(stderr, "hash(): %sFinalBits Error %d.\n",
+              keyarray ? "hmac" : "sha", err);
+      return err;
+    }
+  }
+
+  err = keyarray ? hmacResult(&hmac, Message_Digest) :
+                   USHAResult(&sha, Message_Digest);
+  if (err != shaSuccess) {
+    fprintf(stderr, "hash(): %s Result Error %d, could not "
+      "compute message digest.\n", keyarray ? "hmac" : "sha", err);
+    return err;
+  }
+
+  sprintf(buf, "%d", testno+1);
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 94]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+  printResult(Message_Digest, hashsize, hashes[hashno].name,
+    keyarray ? "hmac standard test" : "sha standard test", buf,
+    resultarray, printResults, printPassFail);
+
+  return err;
+}
+
+/*
+ * Exercise a hash series of functions. The input is a filename.
+ * If the result is known, it is in resultarray in uppercase hex.
+ */
+int hashfile(int hashno, const char *hashfilename, int bits,
+  int bitcount, int skipSpaces, const unsigned char *keyarray,
+  int keylen, const char *resultarray, int hashsize,
+  int printResults, int printPassFail)
+{
+  USHAContext sha;
+  HMACContext hmac;
+  int err, nread, c;
+  unsigned char buf[4096];
+  uint8_t Message_Digest[USHAMaxHashSize];
+  unsigned char cc;
+  FILE *hashfp = (strcmp(hashfilename, "-") == 0) ? stdin :
+    fopen(hashfilename, "r");
+
+  if (!hashfp) {
+    fprintf(stderr, "cannot open file '%s'\n", hashfilename);
+    return shaStateError;
+  }
+
+  memset(&sha, '\343', sizeof(sha)); /* force bad data into struct */
+  memset(&hmac, '\343', sizeof(hmac));
+  err = keyarray ? hmacReset(&hmac, hashes[hashno].whichSha,
+                             keyarray, keylen) :
+                   USHAReset(&sha, hashes[hashno].whichSha);
+
+  if (err != shaSuccess) {
+    fprintf(stderr, "hashfile(): %sReset Error %d.\n",
+            keyarray ? "hmac" : "sha", err);
+    return err;
+  }
+
+  if (skipSpaces)
+    while ((c = getc(hashfp)) != EOF) {
+      if (!isspace(c)) {
+        cc = (unsigned char)c;
+        err = keyarray ? hmacInput(&hmac, &cc, 1) :
+                         USHAInput(&sha, &cc, 1);
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 95]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+        if (err != shaSuccess) {
+          fprintf(stderr, "hashfile(): %sInput Error %d.\n",
+                  keyarray ? "hmac" : "sha", err);
+          if (hashfp != stdin) fclose(hashfp);
+          return err;
+        }
+      }
+    }
+  else
+    while ((nread = fread(buf, 1, sizeof(buf), hashfp)) > 0) {
+      err = keyarray ? hmacInput(&hmac, buf, nread) :
+                       USHAInput(&sha, buf, nread);
+      if (err != shaSuccess) {
+        fprintf(stderr, "hashfile(): %s Error %d.\n",
+                keyarray ? "hmacInput" : "shaInput", err);
+        if (hashfp != stdin) fclose(hashfp);
+        return err;
+      }
+    }
+
+  if (bitcount > 0)
+    err = keyarray ? hmacFinalBits(&hmac, bits, bitcount) :
+                   USHAFinalBits(&sha, bits, bitcount);
+  if (err != shaSuccess) {
+    fprintf(stderr, "hashfile(): %s Error %d.\n",
+            keyarray ? "hmacResult" : "shaResult", err);
+    if (hashfp != stdin) fclose(hashfp);
+    return err;
+  }
+
+  err = keyarray ? hmacResult(&hmac, Message_Digest) :
+                   USHAResult(&sha, Message_Digest);
+  if (err != shaSuccess) {
+    fprintf(stderr, "hashfile(): %s Error %d.\n",
+            keyarray ? "hmacResult" : "shaResult", err);
+    if (hashfp != stdin) fclose(hashfp);
+    return err;
+  }
+
+  printResult(Message_Digest, hashsize, hashes[hashno].name, "file",
+    hashfilename, resultarray, printResults, printPassFail);
+
+  if (hashfp != stdin) fclose(hashfp);
+  return err;
+}
+
+/*
+ * Exercise a hash series of functions through multiple permutations.
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 96]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+ * The input is an initial seed. That seed is replicated 3 times.
+ * For 1000 rounds, the previous three results are used as the input.
+ * This result is then checked, and used to seed the next cycle.
+ * If the result is known, it is in resultarrays in uppercase hex.
+ */
+void randomtest(int hashno, const char *seed, int hashsize,
+    const char **resultarrays, int randomcount,
+    int printResults, int printPassFail)
+{
+  int i, j; char buf[20];
+  unsigned char SEED[USHAMaxHashSize], MD[1003][USHAMaxHashSize];
+
+  /* INPUT: Seed - A random seed n bits long */
+  memcpy(SEED, seed, hashsize);
+  if (printResults == PRINTTEXT) {
+    printf("%s random test seed= '", hashes[hashno].name);
+    printxstr(seed, hashsize);
+    printf("'\n");
+  }
+
+  for (j = 0; j < randomcount; j++) {
+    /* MD0 = MD1 = MD2 = Seed; */
+    memcpy(MD[0], SEED, hashsize);
+    memcpy(MD[1], SEED, hashsize);
+    memcpy(MD[2], SEED, hashsize);
+    for (i=3; i<1003; i++) {
+      /* Mi = MDi-3 || MDi-2 || MDi-1; */
+      USHAContext Mi;
+      memset(&Mi, '\343', sizeof(Mi)); /* force bad data into struct */
+      USHAReset(&Mi, hashes[hashno].whichSha);
+      USHAInput(&Mi, MD[i-3], hashsize);
+      USHAInput(&Mi, MD[i-2], hashsize);
+      USHAInput(&Mi, MD[i-1], hashsize);
+      /* MDi = SHA(Mi); */
+      USHAResult(&Mi, MD[i]);
+    }
+
+    /* MDj = Seed = MDi; */
+    memcpy(SEED, MD[i-1], hashsize);
+
+    /* OUTPUT: MDj */
+    sprintf(buf, "%d", j);
+    printResult(SEED, hashsize, hashes[hashno].name, "random test",
+      buf, resultarrays ? resultarrays[j] : 0, printResults,
+      (j < RANDOMCOUNT) ? printPassFail : 0);
+  }
+}
+
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 97]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+/*
+ * Look up a hash name.
+ */
+int findhash(const char *argv0, const char *opt)
+{
+  int i;
+  const char *names[HASHCOUNT][2] = {
+    { "0", "sha1" }, { "1", "sha224" }, { "2", "sha256" },
+    { "3", "sha384" }, { "4", "sha512" }
+  };
+
+  for (i = 0; i < HASHCOUNT; i++)
+    if ((strcmp(opt, names[i][0]) == 0) ||
+        (scasecmp(opt, names[i][1]) == 0))
+      return i;
+
+  fprintf(stderr, "%s: Unknown hash name: '%s'\n", argv0, opt);
+  usage(argv0);
+  return 0;
+}
+
+/*
+ * Run some tests that should invoke errors.
+ */
+void testErrors(int hashnolow, int hashnohigh, int printResults,
+    int printPassFail)
+{
+  USHAContext usha;
+  uint8_t Message_Digest[USHAMaxHashSize];
+  int hashno, err;
+
+  for (hashno = hashnolow; hashno <= hashnohigh; hashno++) {
+    memset(&usha, '\343', sizeof(usha)); /* force bad data */
+    USHAReset(&usha, hashno);
+    USHAResult(&usha, Message_Digest);
+    err = USHAInput(&usha, (const unsigned char *)"foo", 3);
+    if (printResults == PRINTTEXT)
+      printf ("\nError %d. Should be %d.\n", err, shaStateError);
+    if ((printPassFail == PRINTPASSFAIL) ||
+        ((printPassFail == PRINTFAIL) && (err != shaStateError)))
+      printf("%s se: %s\n", hashes[hashno].name,
+        (err == shaStateError) ? "PASSED" : "FAILED");
+
+    err = USHAFinalBits(&usha, 0x80, 3);
+    if (printResults == PRINTTEXT)
+      printf ("\nError %d. Should be %d.\n", err, shaStateError);
+    if ((printPassFail == PRINTPASSFAIL) ||
+        ((printPassFail == PRINTFAIL) && (err != shaStateError)))
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 98]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+      printf("%s se: %s\n", hashes[hashno].name,
+        (err == shaStateError) ? "PASSED" : "FAILED");
+
+    err = USHAReset(0, hashes[hashno].whichSha);
+    if (printResults == PRINTTEXT)
+       printf("\nError %d. Should be %d.\n", err, shaNull);
+    if ((printPassFail == PRINTPASSFAIL) ||
+        ((printPassFail == PRINTFAIL) && (err != shaNull)))
+       printf("%s usha null: %s\n", hashes[hashno].name,
+        (err == shaNull) ? "PASSED" : "FAILED");
+
+    switch (hashno) {
+      case SHA1: err = SHA1Reset(0); break;
+      case SHA224: err = SHA224Reset(0); break;
+      case SHA256: err = SHA256Reset(0); break;
+      case SHA384: err = SHA384Reset(0); break;
+      case SHA512: err = SHA512Reset(0); break;
+    }
+    if (printResults == PRINTTEXT)
+       printf("\nError %d. Should be %d.\n", err, shaNull);
+    if ((printPassFail == PRINTPASSFAIL) ||
+        ((printPassFail == PRINTFAIL) && (err != shaNull)))
+       printf("%s sha null: %s\n", hashes[hashno].name,
+        (err == shaNull) ? "PASSED" : "FAILED");
+  }
+}
+
+/* replace a hex string in place with its value */
+int unhexStr(char *hexstr)
+{
+  char *o = hexstr;
+  int len = 0, nibble1 = 0, nibble2 = 0;
+  if (!hexstr) return 0;
+  for ( ; *hexstr; hexstr++) {
+    if (isalpha((int)(unsigned char)(*hexstr))) {
+      nibble1 = tolower(*hexstr) - 'a' + 10;
+    } else if (isdigit((int)(unsigned char)(*hexstr))) {
+      nibble1 = *hexstr - '0';
+    } else {
+      printf("\nError: bad hex character '%c'\n", *hexstr);
+    }
+    if (!*++hexstr) break;
+    if (isalpha((int)(unsigned char)(*hexstr))) {
+      nibble2 = tolower(*hexstr) - 'a' + 10;
+    } else if (isdigit((int)(unsigned char)(*hexstr))) {
+      nibble2 = *hexstr - '0';
+    } else {
+      printf("\nError: bad hex character '%c'\n", *hexstr);
+
+
+
+Eastlake 3rd & Hansen        Informational                     [Page 99]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+    }
+    *o++ = (char)((nibble1 << 4) | nibble2);
+    len++;
+  }
+  return len;
+}
+
+int main(int argc, char **argv)
+{
+  int i, err;
+  int loopno, loopnohigh = 1;
+  int hashno, hashnolow = 0, hashnohigh = HASHCOUNT - 1;
+  int testno, testnolow = 0, testnohigh;
+  int ntestnohigh = 0;
+  int printResults = PRINTTEXT;
+  int printPassFail = 1;
+  int checkErrors = 0;
+  char *hashstr = 0;
+  int hashlen = 0;
+  const char *resultstr = 0;
+  char *randomseedstr = 0;
+  int runHmacTests = 0;
+  char *hmacKey = 0;
+  int hmaclen = 0;
+  int randomcount = RANDOMCOUNT;
+  const char *hashfilename = 0;
+  const char *hashFilename = 0;
+  int extrabits = 0, numberExtrabits = 0;
+  int strIsHex = 0;
+
+  while ((i = xgetopt(argc, argv, "b:B:ef:F:h:Hk:l:mpPr:R:s:S:t:wxX"))
+         != -1)
+    switch (i) {
+      case 'b': extrabits = strtol(xoptarg, 0, 0); break;
+      case 'B': numberExtrabits = atoi(xoptarg); break;
+      case 'e': checkErrors = 1; break;
+      case 'f': hashfilename = xoptarg; break;
+      case 'F': hashFilename = xoptarg; break;
+      case 'h': hashnolow = hashnohigh = findhash(argv[0], xoptarg);
+        break;
+      case 'H': strIsHex = 1; break;
+      case 'k': hmacKey = xoptarg; hmaclen = strlen(xoptarg); break;
+      case 'l': loopnohigh = atoi(xoptarg); break;
+      case 'm': runHmacTests = 1; break;
+      case 'P': printPassFail = 0; break;
+      case 'p': printResults = PRINTNONE; break;
+      case 'R': randomcount = atoi(xoptarg); break;
+      case 'r': randomseedstr = xoptarg; break;
+
+
+
+Eastlake 3rd & Hansen        Informational                    [Page 100]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+      case 's': hashstr = xoptarg; hashlen = strlen(hashstr); break;
+      case 'S': resultstr = xoptarg; break;
+      case 't': testnolow = ntestnohigh = atoi(xoptarg) - 1; break;
+      case 'w': printResults = PRINTRAW; break;
+      case 'x': printResults = PRINTHEX; break;
+      case 'X': printPassFail = 2; break;
+      default: usage(argv[0]);
+      }
+
+  if (strIsHex) {
+    hashlen = unhexStr(hashstr);
+    unhexStr(randomseedstr);
+    hmaclen = unhexStr(hmacKey);
+  }
+  testnohigh = (ntestnohigh != 0) ? ntestnohigh:
+               runHmacTests ? (HMACTESTCOUNT-1) : (TESTCOUNT-1);
+  if ((testnolow < 0) ||
+      (testnohigh >= (runHmacTests ? HMACTESTCOUNT : TESTCOUNT)) ||
+      (hashnolow < 0) || (hashnohigh >= HASHCOUNT) ||
+      (hashstr && (testnolow == testnohigh)) ||
+      (randomcount < 0) ||
+      (resultstr && (!hashstr && !hashfilename && !hashFilename)) ||
+      ((runHmacTests || hmacKey) && randomseedstr) ||
+      (hashfilename && hashFilename))
+    usage(argv[0]);
+
+  /*
+   *  Perform SHA/HMAC tests
+   */
+  for (hashno = hashnolow; hashno <= hashnohigh; ++hashno) {
+    if (printResults == PRINTTEXT)
+      printf("Hash %s\n", hashes[hashno].name);
+    err = shaSuccess;
+
+    for (loopno = 1; (loopno <= loopnohigh) && (err == shaSuccess);
+         ++loopno) {
+      if (hashstr)
+        err = hash(0, loopno, hashno, hashstr, hashlen, 1,
+          numberExtrabits, extrabits, (const unsigned char *)hmacKey,
+          hmaclen, resultstr, hashes[hashno].hashsize, printResults,
+          printPassFail);
+
+      else if (randomseedstr)
+        randomtest(hashno, randomseedstr, hashes[hashno].hashsize, 0,
+          randomcount, printResults, printPassFail);
+
+      else if (hashfilename)
+        err = hashfile(hashno, hashfilename, extrabits,
+
+
+
+Eastlake 3rd & Hansen        Informational                    [Page 101]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+                       numberExtrabits, 0,
+                       (const unsigned char *)hmacKey, hmaclen,
+                       resultstr, hashes[hashno].hashsize,
+                       printResults, printPassFail);
+
+      else if (hashFilename)
+        err = hashfile(hashno, hashFilename, extrabits,
+                       numberExtrabits, 1,
+                       (const unsigned char *)hmacKey, hmaclen,
+                       resultstr, hashes[hashno].hashsize,
+                       printResults, printPassFail);
+
+      else /* standard tests */ {
+        for (testno = testnolow;
+             (testno <= testnohigh) && (err == shaSuccess); ++testno) {
+          if (runHmacTests) {
+            err = hash(testno, loopno, hashno,
+                       hmachashes[testno].dataarray[hashno] ?
+                       hmachashes[testno].dataarray[hashno] :
+                       hmachashes[testno].dataarray[1] ?
+                       hmachashes[testno].dataarray[1] :
+                       hmachashes[testno].dataarray[0],
+                       hmachashes[testno].datalength[hashno] ?
+                       hmachashes[testno].datalength[hashno] :
+                       hmachashes[testno].datalength[1] ?
+                       hmachashes[testno].datalength[1] :
+                       hmachashes[testno].datalength[0],
+                       1, 0, 0,
+                       (const unsigned char *)(
+                        hmachashes[testno].keyarray[hashno] ?
+                        hmachashes[testno].keyarray[hashno] :
+                        hmachashes[testno].keyarray[1] ?
+                        hmachashes[testno].keyarray[1] :
+                        hmachashes[testno].keyarray[0]),
+                       hmachashes[testno].keylength[hashno] ?
+                       hmachashes[testno].keylength[hashno] :
+                       hmachashes[testno].keylength[1] ?
+                       hmachashes[testno].keylength[1] :
+                       hmachashes[testno].keylength[0],
+                       hmachashes[testno].resultarray[hashno],
+                       hmachashes[testno].resultlength[hashno],
+                       printResults, printPassFail);
+          } else {
+            err = hash(testno, loopno, hashno,
+                       hashes[hashno].tests[testno].testarray,
+                       hashes[hashno].tests[testno].length,
+                       hashes[hashno].tests[testno].repeatcount,
+                       hashes[hashno].tests[testno].numberExtrabits,
+
+
+
+Eastlake 3rd & Hansen        Informational                    [Page 102]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+                       hashes[hashno].tests[testno].extrabits, 0, 0,
+                       hashes[hashno].tests[testno].resultarray,
+                       hashes[hashno].hashsize,
+                       printResults, printPassFail);
+          }
+        }
+
+        if (!runHmacTests) {
+          randomtest(hashno, hashes[hashno].randomtest,
+            hashes[hashno].hashsize, hashes[hashno].randomresults,
+            RANDOMCOUNT, printResults, printPassFail);
+        }
+      }
+    }
+  }
+
+  /* Test some error returns */
+  if (checkErrors) {
+    testErrors(hashnolow, hashnohigh, printResults, printPassFail);
+  }
+
+  return 0;
+}
+
+/*
+ * Compare two strings, case independently.
+ * Equivalent to strcasecmp() found on some systems.
+ */
+int scasecmp(const char *s1, const char *s2)
+{
+  for (;;) {
+    char u1 = tolower(*s1++);
+    char u2 = tolower(*s2++);
+    if (u1 != u2)
+      return u1 - u2;
+    if (u1 == '\0')
+      return 0;
+   }
+}
+
+/*
+ * This is a copy of getopt provided for those systems that do not
+ * have it. The name was changed to xgetopt to not conflict on those
+ * systems that do have it. Similarly, optarg, optind and opterr
+ * were renamed to xoptarg, xoptind and xopterr.
+ *
+ * Copyright 1990, 1991, 1992 by the Massachusetts Institute of
+ * Technology and UniSoft Group Limited.
+
+
+
+Eastlake 3rd & Hansen        Informational                    [Page 103]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+ *
+ * Permission to use, copy, modify, distribute, and sell this software
+ * and its documentation for any purpose is hereby granted without fee,
+ * provided that the above copyright notice appear in all copies and
+ * that both that copyright notice and this permission notice appear in
+ * supporting documentation, and that the names of MIT and UniSoft not
+ * be used in advertising or publicity pertaining to distribution of
+ * the software without specific, written prior permission.  MIT and
+ * UniSoft make no representations about the suitability of this
+ * software for any purpose.  It is provided "as is" without express
+ * or implied warranty.
+ *
+ * $XConsortium: getopt.c,v 1.2 92/07/01 11:59:04 rws Exp $
+ * NB: Reformatted to match above style.
+ */
+
+char    *xoptarg;
+int     xoptind = 1;
+int     xopterr = 1;
+
+static int xgetopt(int argc, char **argv, const char *optstring)
+{
+  static int avplace;
+  char    *ap;
+  char    *cp;
+  int     c;
+
+  if (xoptind >= argc)
+    return EOF;
+
+  ap = argv[xoptind] + avplace;
+
+  /* At beginning of arg but not an option */
+  if (avplace == 0) {
+    if (ap[0] != '-')
+      return EOF;
+    else if (ap[1] == '-') {
+      /* Special end of options option */
+      xoptind++;
+      return EOF;
+    } else if (ap[1] == '\0')
+      return EOF;  /* single '-' is not allowed */
+  }
+
+  /* Get next letter */
+  avplace++;
+  c = *++ap;
+
+
+
+
+Eastlake 3rd & Hansen        Informational                    [Page 104]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+  cp = strchr(optstring, c);
+  if (cp == NULL || c == ':') {
+    if (xopterr)
+      fprintf(stderr, "Unrecognised option -- %c\n", c);
+    return '?';
+  }
+
+  if (cp[1] == ':') {
+    /* There should be an option arg */
+    avplace = 0;
+    if (ap[1] == '\0') {
+      /* It is a separate arg */
+      if (++xoptind >= argc) {
+        if (xopterr)
+          fprintf(stderr, "Option requires an argument\n");
+        return '?';
+      }
+      xoptarg = argv[xoptind++];
+    } else {
+      /* is attached to option letter */
+      xoptarg = ap + 1;
+      ++xoptind;
+    }
+  } else {
+    /* If we are out of letters then go to next arg */
+    if (ap[1] == '\0') {
+      ++xoptind;
+      avplace = 0;
+    }
+
+    xoptarg = NULL;
+  }
+  return c;
+}
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake 3rd & Hansen        Informational                    [Page 105]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+9.  Security Considerations
+
+   This document is intended to provides the Internet community
+   convenient access to source code that implements the United States of
+   America Federal Information Processing Standard Secure Hash
+   Algorithms (SHAs) [FIPS180-2] and HMACs based upon these one-way hash
+   functions.  See license in Section 1.1.  No independent assertion of
+   the security of this hash function by the authors for any particular
+   use is intended.
+
+10.  Normative References
+
+   [FIPS180-2] "Secure Hash Standard", United States of America,
+               National Institute of Standards and Technology, Federal
+               Information Processing Standard (FIPS) 180-2,
+               http://csrc.nist.gov/publications/fips/fips180-2/
+               fips180-2withchangenotice.pdf.
+
+   [RFC2104]   Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
+               Hashing for Message Authentication", RFC 2104, February
+               1997.
+
+11.  Informative References
+
+   [RFC2202]   Cheng, P. and R. Glenn, "Test Cases for HMAC-MD5 and
+               HMAC-SHA-1", RFC 2202, September 1997.
+
+   [RFC3174]   Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm
+               1 (SHA1)", RFC 3174, September 2001.
+
+   [RFC3874]   Housley, R., "A 224-bit One-way Hash Function: SHA-224",
+               RFC 3874, September 2004.
+
+   [RFC4086]   Eastlake, D., 3rd, Schiller, J., and S. Crocker,
+               "Randomness Requirements for Security", BCP 106, RFC
+               4086, June 2005.
+
+   [RFC4231]   Nystrom, M., "Identifiers and Test Vectors for HMAC-SHA-
+               224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512", RFC
+               4231, December 2005.
+
+   [SHAVS]     "The Secure Hash Algorithm Validation System (SHAVS)",
+               http://csrc.nist.gov/cryptval/shs/SHAVS.pdf.
+
+
+
+
+
+
+
+
+Eastlake 3rd & Hansen        Informational                    [Page 106]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+Authors' Addresses
+
+   Donald E. Eastlake, 3rd
+   Motorola Laboratories
+   155 Beaver Street
+   Milford, MA 01757 USA
+
+   Phone: +1-508-786-7554 (w)
+   EMail: donald.eastlake@motorola.com
+
+
+   Tony Hansen
+   AT&T Laboratories
+   200 Laurel Ave.
+   Middletown, NJ 07748 USA
+
+   Phone: +1-732-420-8934 (w)
+   EMail: tony+shs@maillennium.att.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Eastlake 3rd & Hansen        Informational                    [Page 107]
+
+RFC 4634                   SHAs and HMAC-SHAs                  July 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Eastlake 3rd & Hansen        Informational                    [Page 108]
+
diff --git a/doc/rfc/rfc4641.txt b/doc/rfc/rfc4641.txt
new file mode 100644
index 0000000..0a013bc
--- /dev/null
+++ b/doc/rfc/rfc4641.txt
@@ -0,0 +1,1963 @@
+
+
+
+
+
+
+Network Working Group                                         O. Kolkman
+Request for Comments: 4641                                     R. Gieben
+Obsoletes: 2541                                               NLnet Labs
+Category: Informational                                   September 2006
+
+
+                      DNSSEC Operational Practices
+
+Status of This Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   This document describes a set of practices for operating the DNS with
+   security extensions (DNSSEC).  The target audience is zone
+   administrators deploying DNSSEC.
+
+   The document discusses operational aspects of using keys and
+   signatures in the DNS.  It discusses issues of key generation, key
+   storage, signature generation, key rollover, and related policies.
+
+   This document obsoletes RFC 2541, as it covers more operational
+   ground and gives more up-to-date requirements with respect to key
+   sizes and the new DNSSEC specification.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kolkman & Gieben             Informational                      [Page 1]
+
+RFC 4641              DNSSEC Operational Practices        September 2006
+
+
+Table of Contents
+
+   1. Introduction ....................................................3
+      1.1. The Use of the Term 'key' ..................................4
+      1.2. Time Definitions ...........................................4
+   2. Keeping the Chain of Trust Intact ...............................5
+   3. Keys Generation and Storage .....................................6
+      3.1. Zone and Key Signing Keys ..................................6
+           3.1.1. Motivations for the KSK and ZSK Separation ..........6
+           3.1.2. KSKs for High-Level Zones ...........................7
+      3.2. Key Generation .............................................8
+      3.3. Key Effectivity Period .....................................8
+      3.4. Key Algorithm ..............................................9
+      3.5. Key Sizes ..................................................9
+      3.6. Private Key Storage .......................................11
+   4. Signature Generation, Key Rollover, and Related Policies .......12
+      4.1. Time in DNSSEC ............................................12
+           4.1.1. Time Considerations ................................12
+      4.2. Key Rollovers .............................................14
+           4.2.1. Zone Signing Key Rollovers .........................14
+                  4.2.1.1. Pre-Publish Key Rollover ..................15
+                  4.2.1.2. Double Signature Zone Signing Key
+                           Rollover ..................................17
+                  4.2.1.3. Pros and Cons of the Schemes ..............18
+           4.2.2. Key Signing Key Rollovers ..........................18
+           4.2.3. Difference Between ZSK and KSK Rollovers ...........20
+           4.2.4. Automated Key Rollovers ............................21
+      4.3. Planning for Emergency Key Rollover .......................21
+           4.3.1. KSK Compromise .....................................22
+                  4.3.1.1. Keeping the Chain of Trust Intact .........22
+                  4.3.1.2. Breaking the Chain of Trust ...............23
+           4.3.2. ZSK Compromise .....................................23
+           4.3.3. Compromises of Keys Anchored in Resolvers ..........24
+      4.4. Parental Policies .........................................24
+           4.4.1. Initial Key Exchanges and Parental Policies
+                  Considerations .....................................24
+           4.4.2. Storing Keys or Hashes? ............................25
+           4.4.3. Security Lameness ..................................25
+           4.4.4. DS Signature Validity Period .......................26
+   5. Security Considerations ........................................26
+   6. Acknowledgments ................................................26
+   7. References .....................................................27
+      7.1. Normative References ......................................27
+      7.2. Informative References ....................................28
+   Appendix A. Terminology ...........................................30
+   Appendix B. Zone Signing Key Rollover How-To ......................31
+   Appendix C. Typographic Conventions ...............................32
+
+
+
+
+Kolkman & Gieben             Informational                      [Page 2]
+
+RFC 4641              DNSSEC Operational Practices        September 2006
+
+
+1.  Introduction
+
+   This document describes how to run a DNS Security (DNSSEC)-enabled
+   environment.  It is intended for operators who have knowledge of the
+   DNS (see RFC 1034 [1] and RFC 1035 [2]) and want to deploy DNSSEC.
+   See RFC 4033 [4] for an introduction to DNSSEC, RFC 4034 [5] for the
+   newly introduced Resource Records (RRs), and RFC 4035 [6] for the
+   protocol changes.
+
+   During workshops and early operational deployment tests, operators
+   and system administrators have gained experience about operating the
+   DNS with security extensions (DNSSEC).  This document translates
+   these experiences into a set of practices for zone administrators.
+   At the time of writing, there exists very little experience with
+   DNSSEC in production environments; this document should therefore
+   explicitly not be seen as representing 'Best Current Practices'.
+
+   The procedures herein are focused on the maintenance of signed zones
+   (i.e., signing and publishing zones on authoritative servers).  It is
+   intended that maintenance of zones such as re-signing or key
+   rollovers be transparent to any verifying clients on the Internet.
+
+   The structure of this document is as follows.  In Section 2, we
+   discuss the importance of keeping the "chain of trust" intact.
+   Aspects of key generation and storage of private keys are discussed
+   in Section 3; the focus in this section is mainly on the private part
+   of the key(s).  Section 4 describes considerations concerning the
+   public part of the keys.  Since these public keys appear in the DNS
+   one has to take into account all kinds of timing issues, which are
+   discussed in Section 4.1.  Section 4.2 and Section 4.3 deal with the
+   rollover, or supercession, of keys.  Finally, Section 4.4 discusses
+   considerations on how parents deal with their children's public keys
+   in order to maintain chains of trust.
+
+   The typographic conventions used in this document are explained in
+   Appendix C.
+
+   Since this is a document with operational suggestions and there are
+   no protocol specifications, the RFC 2119 [7] language does not apply.
+
+   This document obsoletes RFC 2541 [12] to reflect the evolution of the
+   underlying DNSSEC protocol since then.  Changes in the choice of
+   cryptographic algorithms, DNS record types and type names, and the
+   parent-child key and signature exchange demanded a major rewrite and
+   additional information and explanation.
+
+
+
+
+
+
+Kolkman & Gieben             Informational                      [Page 3]
+
+RFC 4641              DNSSEC Operational Practices        September 2006
+
+
+1.1.  The Use of the Term 'key'
+
+   It is assumed that the reader is familiar with the concept of
+   asymmetric keys on which DNSSEC is based (public key cryptography
+   [17]).  Therefore, this document will use the term 'key' rather
+   loosely.  Where it is written that 'a key is used to sign data' it is
+   assumed that the reader understands that it is the private part of
+   the key pair that is used for signing.  It is also assumed that the
+   reader understands that the public part of the key pair is published
+   in the DNSKEY Resource Record and that it is the public part that is
+   used in key exchanges.
+
+1.2.  Time Definitions
+
+   In this document, we will be using a number of time-related terms.
+   The following definitions apply:
+
+   o  "Signature validity period" The period that a signature is valid.
+      It starts at the time specified in the signature inception field
+      of the RRSIG RR and ends at the time specified in the expiration
+      field of the RRSIG RR.
+
+   o  "Signature publication period" Time after which a signature (made
+      with a specific key) is replaced with a new signature (made with
+      the same key).  This replacement takes place by publishing the
+      relevant RRSIG in the master zone file.  After one stops
+      publishing an RRSIG in a zone, it may take a while before the
+      RRSIG has expired from caches and has actually been removed from
+      the DNS.
+
+   o  "Key effectivity period" The period during which a key pair is
+      expected to be effective.  This period is defined as the time
+      between the first inception time stamp and the last expiration
+      date of any signature made with this key, regardless of any
+      discontinuity in the use of the key.  The key effectivity period
+      can span multiple signature validity periods.
+
+   o  "Maximum/Minimum Zone Time to Live (TTL)" The maximum or minimum
+      value of the TTLs from the complete set of RRs in a zone.  Note
+      that the minimum TTL is not the same as the MINIMUM field in the
+      SOA RR.  See [11] for more information.
+
+
+
+
+
+
+
+
+
+
+Kolkman & Gieben             Informational                      [Page 4]
+
+RFC 4641              DNSSEC Operational Practices        September 2006
+
+
+2.  Keeping the Chain of Trust Intact
+
+   Maintaining a valid chain of trust is important because broken chains
+   of trust will result in data being marked as Bogus (as defined in [4]
+   Section 5), which may cause entire (sub)domains to become invisible
+   to verifying clients.  The administrators of secured zones have to
+   realize that their zone is, to verifying clients, part of a chain of
+   trust.
+
+   As mentioned in the introduction, the procedures herein are intended
+   to ensure that maintenance of zones, such as re-signing or key
+   rollovers, will be transparent to the verifying clients on the
+   Internet.
+
+   Administrators of secured zones will have to keep in mind that data
+   published on an authoritative primary server will not be immediately
+   seen by verifying clients; it may take some time for the data to be
+   transferred to other secondary authoritative nameservers and clients
+   may be fetching data from caching non-authoritative servers.  In this
+   light, note that the time for a zone transfer from master to slave is
+   negligible when using NOTIFY [9] and incremental transfer (IXFR) [8].
+   It increases when full zone transfers (AXFR) are used in combination
+   with NOTIFY.  It increases even more if you rely on full zone
+   transfers based on only the SOA timing parameters for refresh.
+
+   For the verifying clients, it is important that data from secured
+   zones can be used to build chains of trust regardless of whether the
+   data came directly from an authoritative server, a caching
+   nameserver, or some middle box.  Only by carefully using the
+   available timing parameters can a zone administrator ensure that the
+   data necessary for verification can be obtained.
+
+   The responsibility for maintaining the chain of trust is shared by
+   administrators of secured zones in the chain of trust.  This is most
+   obvious in the case of a 'key compromise' when a trade-off between
+   maintaining a valid chain of trust and replacing the compromised keys
+   as soon as possible must be made.  Then zone administrators will have
+   to make a trade-off, between keeping the chain of trust intact --
+   thereby allowing for attacks with the compromised key -- or
+   deliberately breaking the chain of trust and making secured
+   subdomains invisible to security-aware resolvers.  Also see Section
+   4.3.
+
+
+
+
+
+
+
+
+
+Kolkman & Gieben             Informational                      [Page 5]
+
+RFC 4641              DNSSEC Operational Practices        September 2006
+
+
+3.  Keys Generation and Storage
+
+   This section describes a number of considerations with respect to the
+   security of keys.  It deals with the generation, effectivity period,
+   size, and storage of private keys.
+
+3.1.  Zone and Key Signing Keys
+
+   The DNSSEC validation protocol does not distinguish between different
+   types of DNSKEYs.  All DNSKEYs can be used during the validation.  In
+   practice, operators use Key Signing and Zone Signing Keys and use the
+   so-called Secure Entry Point (SEP) [3] flag to distinguish between
+   them during operations.  The dynamics and considerations are
+   discussed below.
+
+   To make zone re-signing and key rollover procedures easier to
+   implement, it is possible to use one or more keys as Key Signing Keys
+   (KSKs).  These keys will only sign the apex DNSKEY RRSet in a zone.
+   Other keys can be used to sign all the RRSets in a zone and are
+   referred to as Zone Signing Keys (ZSKs).  In this document, we assume
+   that KSKs are the subset of keys that are used for key exchanges with
+   the parent and potentially for configuration as trusted anchors --
+   the SEP keys.  In this document, we assume a one-to-one mapping
+   between KSK and SEP keys and we assume the SEP flag to be set on all
+   KSKs.
+
+3.1.1.  Motivations for the KSK and ZSK Separation
+
+   Differentiating between the KSK and ZSK functions has several
+   advantages:
+
+   o  No parent/child interaction is required when ZSKs are updated.
+
+   o  The KSK can be made stronger (i.e., using more bits in the key
+      material).  This has little operational impact since it is only
+      used to sign a small fraction of the zone data.  Also, the KSK is
+      only used to verify the zone's key set, not for other RRSets in
+      the zone.
+
+   o  As the KSK is only used to sign a key set, which is most probably
+      updated less frequently than other data in the zone, it can be
+      stored separately from and in a safer location than the ZSK.
+
+   o  A KSK can have a longer key effectivity period.
+
+   For almost any method of key management and zone signing, the KSK is
+   used less frequently than the ZSK.  Once a key set is signed with the
+   KSK, all the keys in the key set can be used as ZSKs.  If a ZSK is
+
+
+
+Kolkman & Gieben             Informational                      [Page 6]
+
+RFC 4641              DNSSEC Operational Practices        September 2006
+
+
+   compromised, it can be simply dropped from the key set.  The new key
+   set is then re-signed with the KSK.
+
+   Given the assumption that for KSKs the SEP flag is set, the KSK can
+   be distinguished from a ZSK by examining the flag field in the DNSKEY
+   RR.  If the flag field is an odd number it is a KSK.  If it is an
+   even number it is a ZSK.
+
+   The Zone Signing Key can be used to sign all the data in a zone on a
+   regular basis.  When a Zone Signing Key is to be rolled, no
+   interaction with the parent is needed.  This allows for signature
+   validity periods on the order of days.
+
+   The Key Signing Key is only to be used to sign the DNSKEY RRs in a
+   zone.  If a Key Signing Key is to be rolled over, there will be
+   interactions with parties other than the zone administrator.  These
+   can include the registry of the parent zone or administrators of
+   verifying resolvers that have the particular key configured as secure
+   entry points.  Hence, the key effectivity period of these keys can
+   and should be made much longer.  Although, given a long enough key,
+   the key effectivity period can be on the order of years, we suggest
+   planning for a key effectivity on the order of a few months so that a
+   key rollover remains an operational routine.
+
+3.1.2.  KSKs for High-Level Zones
+
+   Higher-level zones are generally more sensitive than lower-level
+   zones.  Anyone controlling or breaking the security of a zone thereby
+   obtains authority over all of its subdomains (except in the case of
+   resolvers that have locally configured the public key of a subdomain,
+   in which case this, and only this, subdomain wouldn't be affected by
+   the compromise of the parent zone).  Therefore, extra care should be
+   taken with high-level zones, and strong keys should be used.
+
+   The root zone is the most critical of all zones.  Someone controlling
+   or compromising the security of the root zone would control the
+   entire DNS namespace of all resolvers using that root zone (except in
+   the case of resolvers that have locally configured the public key of
+   a subdomain).  Therefore, the utmost care must be taken in the
+   securing of the root zone.  The strongest and most carefully handled
+   keys should be used.  The root zone private key should always be kept
+   off-line.
+
+   Many resolvers will start at a root server for their access to and
+   authentication of DNS data.  Securely updating the trust anchors in
+   an enormous population of resolvers around the world will be
+   extremely difficult.
+
+
+
+
+Kolkman & Gieben             Informational                      [Page 7]
+
+RFC 4641              DNSSEC Operational Practices        September 2006
+
+
+3.2.  Key Generation
+
+   Careful generation of all keys is a sometimes overlooked but
+   absolutely essential element in any cryptographically secure system.
+   The strongest algorithms used with the longest keys are still of no
+   use if an adversary can guess enough to lower the size of the likely
+   key space so that it can be exhaustively searched.  Technical
+   suggestions for the generation of random keys will be found in RFC
+   4086 [14].  One should carefully assess if the random number
+   generator used during key generation adheres to these suggestions.
+
+   Keys with a long effectivity period are particularly sensitive as
+   they will represent a more valuable target and be subject to attack
+   for a longer time than short-period keys.  It is strongly recommended
+   that long-term key generation occur off-line in a manner isolated
+   from the network via an air gap or, at a minimum, high-level secure
+   hardware.
+
+3.3.  Key Effectivity Period
+
+   For various reasons, keys in DNSSEC need to be changed once in a
+   while.  The longer a key is in use, the greater the probability that
+   it will have been compromised through carelessness, accident,
+   espionage, or cryptanalysis.  Furthermore, when key rollovers are too
+   rare an event, they will not become part of the operational habit and
+   there is risk that nobody on-site will remember the procedure for
+   rollover when the need is there.
+
+   From a purely operational perspective, a reasonable key effectivity
+   period for Key Signing Keys is 13 months, with the intent to replace
+   them after 12 months.  An intended key effectivity period of a month
+   is reasonable for Zone Signing Keys.
+
+   For key sizes that match these effectivity periods, see Section 3.5.
+
+   As argued in Section 3.1.2, securely updating trust anchors will be
+   extremely difficult.  On the other hand, the "operational habit"
+   argument does also apply to trust anchor reconfiguration.  If a short
+   key effectivity period is used and the trust anchor configuration has
+   to be revisited on a regular basis, the odds that the configuration
+   tends to be forgotten is smaller.  The trade-off is against a system
+   that is so dynamic that administrators of the validating clients will
+   not be able to follow the modifications.
+
+   Key effectivity periods can be made very short, as in a few minutes.
+   But when replacing keys one has to take the considerations from
+   Section 4.1 and Section 4.2 into account.
+
+
+
+
+Kolkman & Gieben             Informational                      [Page 8]
+
+RFC 4641              DNSSEC Operational Practices        September 2006
+
+
+3.4.  Key Algorithm
+
+   There are currently three different types of algorithms that can be
+   used in DNSSEC: RSA, DSA, and elliptic curve cryptography.  The
+   latter is fairly new and has yet to be standardized for usage in
+   DNSSEC.
+
+   RSA has been developed in an open and transparent manner.  As the
+   patent on RSA expired in 2000, its use is now also free.
+
+   DSA has been developed by the National Institute of Standards and
+   Technology (NIST).  The creation of signatures takes roughly the same
+   time as with RSA, but is 10 to 40 times as slow for verification
+   [17].
+
+   We suggest the use of RSA/SHA-1 as the preferred algorithm for the
+   key.  The current known attacks on RSA can be defeated by making your
+   key longer.  As the MD5 hashing algorithm is showing cracks, we
+   recommend the usage of SHA-1.
+
+   At the time of publication, it is known that the SHA-1 hash has
+   cryptanalysis issues.  There is work in progress on addressing these
+   issues.  We recommend the use of public key algorithms based on
+   hashes stronger than SHA-1 (e.g., SHA-256), as soon as these
+   algorithms are available in protocol specifications (see [19] and
+   [20]) and implementations.
+
+3.5.  Key Sizes
+
+   When choosing key sizes, zone administrators will need to take into
+   account how long a key will be used, how much data will be signed
+   during the key publication period (see Section 8.10 of [17]), and,
+   optionally, how large the key size of the parent is.  As the chain of
+   trust really is "a chain", there is not much sense in making one of
+   the keys in the chain several times larger then the others.  As
+   always, it's the weakest link that defines the strength of the entire
+   chain.  Also see Section 3.1.1 for a discussion of how keys serving
+   different roles (ZSK vs. KSK) may need different key sizes.
+
+   Generating a key of the correct size is a difficult problem; RFC 3766
+   [13] tries to deal with that problem.  The first part of the
+   selection procedure in Section 1 of the RFC states:
+
+      1. Determine the attack resistance necessary to satisfy the
+         security requirements of the application.  Do this by
+         estimating the minimum number of computer operations that the
+         attacker will be forced to do in order to compromise the
+
+
+
+
+Kolkman & Gieben             Informational                      [Page 9]
+
+RFC 4641              DNSSEC Operational Practices        September 2006
+
+
+         security of the system and then take the logarithm base two of
+         that number.  Call that logarithm value "n".
+
+         A 1996 report recommended 90 bits as a good all-around choice
+         for system security.  The 90 bit number should be increased by
+         about 2/3 bit/year, or about 96 bits in 2005.
+
+   [13] goes on to explain how this number "n" can be used to calculate
+   the key sizes in public key cryptography.  This culminated in the
+   table given below (slightly modified for our purpose):
+
+      +-------------+-----------+--------------+
+      | System      |           |              |
+      | requirement | Symmetric | RSA or DSA   |
+      | for attack  | key size  | modulus size |
+      | resistance  | (bits)    | (bits)       |
+      | (bits)      |           |              |
+      +-------------+-----------+--------------+
+      |     70      |     70    |      947     |
+      |     80      |     80    |     1228     |
+      |     90      |     90    |     1553     |
+      |    100      |    100    |     1926     |
+      |    150      |    150    |     4575     |
+      |    200      |    200    |     8719     |
+      |    250      |    250    |    14596     |
+      +-------------+-----------+--------------+
+
+   The key sizes given are rather large.  This is because these keys are
+   resilient against a trillionaire attacker.  Assuming this rich
+   attacker will not attack your key and that the key is rolled over
+   once a year, we come to the following recommendations about KSK
+   sizes: 1024 bits for low-value domains, 1300 bits for medium-value
+   domains, and 2048 bits for high-value domains.
+
+   Whether a domain is of low, medium, or high value depends solely on
+   the views of the zone owner.  One could, for instance, view leaf
+   nodes in the DNS as of low value, and top-level domains (TLDs) or the
+   root zone of high value.  The suggested key sizes should be safe for
+   the next 5 years.
+
+   As ZSKs can be rolled over more easily (and thus more often), the key
+   sizes can be made smaller.  But as said in the introduction of this
+   paragraph, making the ZSKs' key sizes too small (in relation to the
+   KSKs' sizes) doesn't make much sense.  Try to limit the difference in
+   size to about 100 bits.
+
+
+
+
+
+
+Kolkman & Gieben             Informational                     [Page 10]
+
+RFC 4641              DNSSEC Operational Practices        September 2006
+
+
+   Note that nobody can see into the future and that these key sizes are
+   only provided here as a guide.  Further information can be found in
+   [16] and Section 7.5 of [17].  It should be noted though that [16] is
+   already considered overly optimistic about what key sizes are
+   considered safe.
+
+   One final note concerning key sizes.  Larger keys will increase the
+   sizes of the RRSIG and DNSKEY records and will therefore increase the
+   chance of DNS UDP packet overflow.  Also, the time it takes to
+   validate and create RRSIGs increases with larger keys, so don't
+   needlessly double your key sizes.
+
+3.6.  Private Key Storage
+
+   It is recommended that, where possible, zone private keys and the
+   zone file master copy that is to be signed be kept and used in off-
+   line, non-network-connected, physically secure machines only.
+   Periodically, an application can be run to add authentication to a
+   zone by adding RRSIG and NSEC RRs.  Then the augmented file can be
+   transferred.
+
+   When relying on dynamic update to manage a signed zone [10], be aware
+   that at least one private key of the zone will have to reside on the
+   master server.  This key is only as secure as the amount of exposure
+   the server receives to unknown clients and the security of the host.
+   Although not mandatory, one could administer the DNS in the following
+   way.  The master that processes the dynamic updates is unavailable
+   from generic hosts on the Internet, it is not listed in the NS RR
+   set, although its name appears in the SOA RRs MNAME field.  The
+   nameservers in the NS RRSet are able to receive zone updates through
+   NOTIFY, IXFR, AXFR, or an out-of-band distribution mechanism.  This
+   approach is known as the "hidden master" setup.
+
+   The ideal situation is to have a one-way information flow to the
+   network to avoid the possibility of tampering from the network.
+   Keeping the zone master file on-line on the network and simply
+   cycling it through an off-line signer does not do this.  The on-line
+   version could still be tampered with if the host it resides on is
+   compromised.  For maximum security, the master copy of the zone file
+   should be off-net and should not be updated based on an unsecured
+   network mediated communication.
+
+   In general, keeping a zone file off-line will not be practical and
+   the machines on which zone files are maintained will be connected to
+   a network.  Operators are advised to take security measures to shield
+   unauthorized access to the master copy.
+
+
+
+
+
+Kolkman & Gieben             Informational                     [Page 11]
+
+RFC 4641              DNSSEC Operational Practices        September 2006
+
+
+   For dynamically updated secured zones [10], both the master copy and
+   the private key that is used to update signatures on updated RRs will
+   need to be on-line.
+
+4.  Signature Generation, Key Rollover, and Related Policies
+
+4.1.  Time in DNSSEC
+
+   Without DNSSEC, all times in the DNS are relative.  The SOA fields
+   REFRESH, RETRY, and EXPIRATION are timers used to determine the time
+   elapsed after a slave server synchronized with a master server.  The
+   Time to Live (TTL) value and the SOA RR minimum TTL parameter [11]
+   are used to determine how long a forwarder should cache data after it
+   has been fetched from an authoritative server.  By using a signature
+   validity period, DNSSEC introduces the notion of an absolute time in
+   the DNS.  Signatures in DNSSEC have an expiration date after which
+   the signature is marked as invalid and the signed data is to be
+   considered Bogus.
+
+4.1.1.  Time Considerations
+
+   Because of the expiration of signatures, one should consider the
+   following:
+
+   o  We suggest the Maximum Zone TTL of your zone data to be a fraction
+      of your signature validity period.
+
+         If the TTL would be of similar order as the signature validity
+         period, then all RRSets fetched during the validity period
+         would be cached until the signature expiration time.  Section
+         7.1 of [4] suggests that "the resolver may use the time
+         remaining before expiration of the signature validity period of
+         a signed RRSet as an upper bound for the TTL".  As a result,
+         query load on authoritative servers would peak at signature
+         expiration time, as this is also the time at which records
+         simultaneously expire from caches.
+
+         To avoid query load peaks, we suggest the TTL on all the RRs in
+         your zone to be at least a few times smaller than your
+         signature validity period.
+
+   o  We suggest the signature publication period to end at least one
+      Maximum Zone TTL duration before the end of the signature validity
+      period.
+
+
+
+
+
+
+
+Kolkman & Gieben             Informational                     [Page 12]
+
+RFC 4641              DNSSEC Operational Practices        September 2006
+
+
+         Re-signing a zone shortly before the end of the signature
+         validity period may cause simultaneous expiration of data from
+         caches.  This in turn may lead to peaks in the load on
+         authoritative servers.
+
+   o  We suggest the Minimum Zone TTL to be long enough to both fetch
+      and verify all the RRs in the trust chain.  In workshop
+      environments, it has been demonstrated [18] that a low TTL (under
+      5 to 10 minutes) caused disruptions because of the following two
+      problems:
+
+         1.  During validation, some data may expire before the
+             validation is complete.  The validator should be able to
+             keep all data until it is completed.  This applies to all
+             RRs needed to complete the chain of trust: DSes, DNSKEYs,
+             RRSIGs, and the final answers, i.e., the RRSet that is
+             returned for the initial query.
+
+         2.  Frequent verification causes load on recursive nameservers.
+             Data at delegation points, DSes, DNSKEYs, and RRSIGs
+             benefit from caching.  The TTL on those should be
+             relatively long.
+
+   o  Slave servers will need to be able to fetch newly signed zones
+      well before the RRSIGs in the zone served by the slave server pass
+      their signature expiration time.
+
+         When a slave server is out of sync with its master and data in
+         a zone is signed by expired signatures, it may be better for
+         the slave server not to give out any answer.
+
+         Normally, a slave server that is not able to contact a master
+         server for an extended period will expire a zone.  When that
+         happens, the server will respond differently to queries for
+         that zone.  Some servers issue SERVFAIL, whereas others turn
+         off the 'AA' bit in the answers.  The time of expiration is set
+         in the SOA record and is relative to the last successful
+         refresh between the master and the slave servers.  There exists
+         no coupling between the signature expiration of RRSIGs in the
+         zone and the expire parameter in the SOA.
+
+         If the server serves a DNSSEC zone, then it may well happen
+         that the signatures expire well before the SOA expiration timer
+         counts down to zero.  It is not possible to completely prevent
+         this from happening by tweaking the SOA parameters.  However,
+         the effects can be minimized where the SOA expiration time is
+         equal to or shorter than the signature validity period.  The
+         consequence of an authoritative server not being able to update
+
+
+
+Kolkman & Gieben             Informational                     [Page 13]
+
+RFC 4641              DNSSEC Operational Practices        September 2006
+
+
+         a zone, whilst that zone includes expired signatures, is that
+         non-secure resolvers will continue to be able to resolve data
+         served by the particular slave servers while security-aware
+         resolvers will experience problems because of answers being
+         marked as Bogus.
+
+         We suggest the SOA expiration timer being approximately one
+         third or one fourth of the signature validity period.  It will
+         allow problems with transfers from the master server to be
+         noticed before the actual signature times out.  We also suggest
+         that operators of nameservers that supply secondary services
+         develop 'watch dogs' to spot upcoming signature expirations in
+         zones they slave, and take appropriate action.
+
+         When determining the value for the expiration parameter one has
+         to take the following into account: What are the chances that
+         all my secondaries expire the zone? How quickly can I reach an
+         administrator of secondary servers to load a valid zone?  These
+         questions are not DNSSEC specific but may influence the choice
+         of your signature validity intervals.
+
+4.2.  Key Rollovers
+
+   A DNSSEC key cannot be used forever (see Section 3.3).  So key
+   rollovers -- or supercessions, as they are sometimes called -- are a
+   fact of life when using DNSSEC.  Zone administrators who are in the
+   process of rolling their keys have to take into account that data
+   published in previous versions of their zone still lives in caches.
+   When deploying DNSSEC, this becomes an important consideration;
+   ignoring data that may be in caches may lead to loss of service for
+   clients.
+
+   The most pressing example of this occurs when zone material signed
+   with an old key is being validated by a resolver that does not have
+   the old zone key cached.  If the old key is no longer present in the
+   current zone, this validation fails, marking the data "Bogus".
+   Alternatively, an attempt could be made to validate data that is
+   signed with a new key against an old key that lives in a local cache,
+   also resulting in data being marked "Bogus".
+
+4.2.1.  Zone Signing Key Rollovers
+
+   For "Zone Signing Key rollovers", there are two ways to make sure
+   that during the rollover data still cached can be verified with the
+   new key sets or newly generated signatures can be verified with the
+   keys still in caches.  One schema, described in Section 4.2.1.2, uses
+
+
+
+
+
+Kolkman & Gieben             Informational                     [Page 14]
+
+RFC 4641              DNSSEC Operational Practices        September 2006
+
+
+   double signatures; the other uses key pre-publication (Section
+   4.2.1.1).  The pros, cons, and recommendations are described in
+   Section 4.2.1.3.
+
+4.2.1.1.  Pre-Publish Key Rollover
+
+   This section shows how to perform a ZSK rollover without the need to
+   sign all the data in a zone twice -- the "pre-publish key rollover".
+   This method has advantages in the case of a key compromise.  If the
+   old key is compromised, the new key has already been distributed in
+   the DNS.  The zone administrator is then able to quickly switch to
+   the new key and remove the compromised key from the zone.  Another
+   major advantage is that the zone size does not double, as is the case
+   with the double signature ZSK rollover.  A small "how-to" for this
+   kind of rollover can be found in Appendix B.
+
+   Pre-publish key rollover involves four stages as follows:
+
+      ----------------------------------------------------------------
+      initial         new DNSKEY       new RRSIGs      DNSKEY removal
+      ----------------------------------------------------------------
+      SOA0            SOA1             SOA2            SOA3
+      RRSIG10(SOA0)   RRSIG10(SOA1)    RRSIG11(SOA2)   RRSIG11(SOA3)
+
+      DNSKEY1         DNSKEY1          DNSKEY1         DNSKEY1
+      DNSKEY10        DNSKEY10         DNSKEY10        DNSKEY11
+      DNSKEY11         DNSKEY11
+      RRSIG1 (DNSKEY) RRSIG1 (DNSKEY)  RRSIG1(DNSKEY)  RRSIG1 (DNSKEY)
+      RRSIG10(DNSKEY) RRSIG10(DNSKEY)  RRSIG11(DNSKEY) RRSIG11(DNSKEY)
+      ----------------------------------------------------------------
+
+                         Pre-Publish Key Rollover
+
+   initial: Initial version of the zone: DNSKEY 1 is the Key Signing
+      Key.  DNSKEY 10 is used to sign all the data of the zone, the Zone
+      Signing Key.
+
+   new DNSKEY: DNSKEY 11 is introduced into the key set.  Note that no
+      signatures are generated with this key yet, but this does not
+      secure against brute force attacks on the public key.  The minimum
+      duration of this pre-roll phase is the time it takes for the data
+      to propagate to the authoritative servers plus TTL value of the
+      key set.
+
+   new RRSIGs: At the "new RRSIGs" stage (SOA serial 2), DNSKEY 11 is
+      used to sign the data in the zone exclusively (i.e., all the
+      signatures from DNSKEY 10 are removed from the zone).  DNSKEY 10
+      remains published in the key set.  This way data that was loaded
+
+
+
+Kolkman & Gieben             Informational                     [Page 15]
+
+RFC 4641              DNSSEC Operational Practices        September 2006
+
+
+      into caches from version 1 of the zone can still be verified with
+      key sets fetched from version 2 of the zone.  The minimum time
+      that the key set including DNSKEY 10 is to be published is the
+      time that it takes for zone data from the previous version of the
+      zone to expire from old caches, i.e., the time it takes for this
+      zone to propagate to all authoritative servers plus the Maximum
+      Zone TTL value of any of the data in the previous version of the
+      zone.
+
+   DNSKEY removal: DNSKEY 10 is removed from the zone.  The key set, now
+      only containing DNSKEY 1 and DNSKEY 11, is re-signed with the
+      DNSKEY 1.
+
+   The above scheme can be simplified by always publishing the "future"
+   key immediately after the rollover.  The scheme would look as follows
+   (we show two rollovers); the future key is introduced in "new DNSKEY"
+   as DNSKEY 12 and again a newer one, numbered 13, in "new DNSKEY
+   (II)":
+
+      ----------------------------------------------------------------
+      initial             new RRSIGs          new DNSKEY
+      ----------------------------------------------------------------
+      SOA0                SOA1                SOA2
+      RRSIG10(SOA0)       RRSIG11(SOA1)       RRSIG11(SOA2)
+
+      DNSKEY1             DNSKEY1             DNSKEY1
+      DNSKEY10            DNSKEY10            DNSKEY11
+      DNSKEY11            DNSKEY11            DNSKEY12
+      RRSIG1(DNSKEY)      RRSIG1 (DNSKEY)     RRSIG1(DNSKEY)
+      RRSIG10(DNSKEY)     RRSIG11(DNSKEY)     RRSIG11(DNSKEY)
+      ----------------------------------------------------------------
+
+      ----------------------------------------------------------------
+      new RRSIGs (II)     new DNSKEY (II)
+      ----------------------------------------------------------------
+      SOA3                SOA4
+      RRSIG12(SOA3)       RRSIG12(SOA4)
+
+      DNSKEY1             DNSKEY1
+      DNSKEY11            DNSKEY12
+      DNSKEY12            DNSKEY13
+      RRSIG1(DNSKEY)      RRSIG1(DNSKEY)
+      RRSIG12(DNSKEY)     RRSIG12(DNSKEY)
+      ----------------------------------------------------------------
+
+              Pre-Publish Key Rollover, Showing Two Rollovers
+
+
+
+
+
+Kolkman & Gieben             Informational                     [Page 16]
+
+RFC 4641              DNSSEC Operational Practices        September 2006
+
+
+   Note that the key introduced in the "new DNSKEY" phase is not used
+   for production yet; the private key can thus be stored in a
+   physically secure manner and does not need to be 'fetched' every time
+   a zone needs to be signed.
+
+4.2.1.2.  Double Signature Zone Signing Key Rollover
+
+   This section shows how to perform a ZSK key rollover using the double
+   zone data signature scheme, aptly named "double signature rollover".
+
+   During the "new DNSKEY" stage the new version of the zone file will
+   need to propagate to all authoritative servers and the data that
+   exists in (distant) caches will need to expire, requiring at least
+   the Maximum Zone TTL.
+
+   Double signature ZSK rollover involves three stages as follows:
+
+      ----------------------------------------------------------------
+      initial             new DNSKEY         DNSKEY removal
+      ----------------------------------------------------------------
+      SOA0                SOA1               SOA2
+      RRSIG10(SOA0)       RRSIG10(SOA1)      RRSIG11(SOA2)
+      RRSIG11(SOA1)
+
+      DNSKEY1             DNSKEY1            DNSKEY1
+      DNSKEY10            DNSKEY10           DNSKEY11
+      DNSKEY11
+      RRSIG1(DNSKEY)      RRSIG1(DNSKEY)     RRSIG1(DNSKEY)
+      RRSIG10(DNSKEY)     RRSIG10(DNSKEY)    RRSIG11(DNSKEY)
+      RRSIG11(DNSKEY)
+      ----------------------------------------------------------------
+
+                Double Signature Zone Signing Key Rollover
+
+   initial: Initial Version of the zone: DNSKEY 1 is the Key Signing
+      Key.  DNSKEY 10 is used to sign all the data of the zone, the Zone
+      Signing Key.
+
+   new DNSKEY: At the "New DNSKEY" stage (SOA serial 1) DNSKEY 11 is
+      introduced into the key set and all the data in the zone is signed
+      with DNSKEY 10 and DNSKEY 11.  The rollover period will need to
+      continue until all data from version 0 of the zone has expired
+      from remote caches.  This will take at least the Maximum Zone TTL
+      of version 0 of the zone.
+
+   DNSKEY removal: DNSKEY 10 is removed from the zone.  All the
+      signatures from DNSKEY 10 are removed from the zone.  The key set,
+      now only containing DNSKEY 11, is re-signed with DNSKEY 1.
+
+
+
+Kolkman & Gieben             Informational                     [Page 17]
+
+RFC 4641              DNSSEC Operational Practices        September 2006
+
+
+   At every instance, RRSIGs from the previous version of the zone can
+   be verified with the DNSKEY RRSet from the current version and the
+   other way around.  The data from the current version can be verified
+   with the data from the previous version of the zone.  The duration of
+   the "new DNSKEY" phase and the period between rollovers should be at
+   least the Maximum Zone TTL.
+
+   Making sure that the "new DNSKEY" phase lasts until the signature
+   expiration time of the data in initial version of the zone is
+   recommended.  This way all caches are cleared of the old signatures.
+   However, this duration could be considerably longer than the Maximum
+   Zone TTL, making the rollover a lengthy procedure.
+
+   Note that in this example we assumed that the zone was not modified
+   during the rollover.  New data can be introduced in the zone as long
+   as it is signed with both keys.
+
+4.2.1.3.  Pros and Cons of the Schemes
+
+   Pre-publish key rollover: This rollover does not involve signing the
+      zone data twice.  Instead, before the actual rollover, the new key
+      is published in the key set and thus is available for
+      cryptanalysis attacks.  A small disadvantage is that this process
+      requires four steps.  Also the pre-publish scheme involves more
+      parental work when used for KSK rollovers as explained in Section
+      4.2.3.
+
+   Double signature ZSK rollover: The drawback of this signing scheme is
+      that during the rollover the number of signatures in your zone
+      doubles; this may be prohibitive if you have very big zones.  An
+      advantage is that it only requires three steps.
+
+4.2.2.  Key Signing Key Rollovers
+
+   For the rollover of a Key Signing Key, the same considerations as for
+   the rollover of a Zone Signing Key apply.  However, we can use a
+   double signature scheme to guarantee that old data (only the apex key
+   set) in caches can be verified with a new key set and vice versa.
+   Since only the key set is signed with a KSK, zone size considerations
+   do not apply.
+
+
+
+
+
+
+
+
+
+
+
+Kolkman & Gieben             Informational                     [Page 18]
+
+RFC 4641              DNSSEC Operational Practices        September 2006
+
+
+   --------------------------------------------------------------------
+       initial        new DNSKEY        DS change       DNSKEY removal
+   --------------------------------------------------------------------
+     Parent:
+       SOA0           -------->         SOA1            -------->
+       RRSIGpar(SOA0) -------->         RRSIGpar(SOA1)  -------->
+       DS1            -------->         DS2             -------->
+       RRSIGpar(DS)   -------->         RRSIGpar(DS)    -------->
+
+
+     Child:
+       SOA0            SOA1             -------->       SOA2
+       RRSIG10(SOA0)   RRSIG10(SOA1)    -------->       RRSIG10(SOA2)
+                                        -------->
+       DNSKEY1         DNSKEY1          -------->       DNSKEY2
+                       DNSKEY2          -------->
+       DNSKEY10        DNSKEY10         -------->       DNSKEY10
+       RRSIG1 (DNSKEY) RRSIG1 (DNSKEY)  -------->       RRSIG2 (DNSKEY)
+                       RRSIG2 (DNSKEY)  -------->
+       RRSIG10(DNSKEY) RRSIG10(DNSKEY)  -------->       RRSIG10(DNSKEY)
+   --------------------------------------------------------------------
+
+   Stages of Deployment for a Double Signature Key Signing Key Rollover
+
+   initial: Initial version of the zone.  The parental DS points to
+      DNSKEY1.  Before the rollover starts, the child will have to
+      verify what the TTL is of the DS RR that points to DNSKEY1 -- it
+      is needed during the rollover and we refer to the value as TTL_DS.
+
+   new DNSKEY: During the "new DNSKEY" phase, the zone administrator
+      generates a second KSK, DNSKEY2.  The key is provided to the
+      parent, and the child will have to wait until a new DS RR has been
+      generated that points to DNSKEY2.  After that DS RR has been
+      published on all servers authoritative for the parent's zone, the
+      zone administrator has to wait at least TTL_DS to make sure that
+      the old DS RR has expired from caches.
+
+   DS change: The parent replaces DS1 with DS2.
+
+   DNSKEY removal: DNSKEY1 has been removed.
+
+   The scenario above puts the responsibility for maintaining a valid
+   chain of trust with the child.  It also is based on the premise that
+   the parent only has one DS RR (per algorithm) per zone.  An
+   alternative mechanism has been considered.  Using an established
+   trust relation, the interaction can be performed in-band, and the
+   removal of the keys by the child can possibly be signaled by the
+   parent.  In this mechanism, there are periods where there are two DS
+
+
+
+Kolkman & Gieben             Informational                     [Page 19]
+
+RFC 4641              DNSSEC Operational Practices        September 2006
+
+
+   RRs at the parent.  Since at the moment of writing the protocol for
+   this interaction has not been developed, further discussion is out of
+   scope for this document.
+
+4.2.3.  Difference Between ZSK and KSK Rollovers
+
+   Note that KSK rollovers and ZSK rollovers are different in the sense
+   that a KSK rollover requires interaction with the parent (and
+   possibly replacing of trust anchors) and the ensuing delay while
+   waiting for it.
+
+   A zone key rollover can be handled in two different ways: pre-publish
+   (Section 4.2.1.1) and double signature (Section 4.2.1.2).
+
+   As the KSK is used to validate the key set and because the KSK is not
+   changed during a ZSK rollover, a cache is able to validate the new
+   key set of the zone.  The pre-publish method would also work for a
+   KSK rollover.  The records that are to be pre-published are the
+   parental DS RRs.  The pre-publish method has some drawbacks for KSKs.
+   We first describe the rollover scheme and then indicate these
+   drawbacks.
+
+   --------------------------------------------------------------------
+     initial         new DS           new DNSKEY      DS/DNSKEY removal
+   --------------------------------------------------------------------
+   Parent:
+     SOA0            SOA1             -------->       SOA2
+     RRSIGpar(SOA0)  RRSIGpar(SOA1)   -------->       RRSIGpar(SOA2)
+     DS1             DS1              -------->       DS2
+                     DS2              -------->
+     RRSIGpar(DS)    RRSIGpar(DS)     -------->       RRSIGpar(DS)
+
+
+   Child:
+     SOA0            -------->        SOA1            SOA1
+     RRSIG10(SOA0)   -------->        RRSIG10(SOA1)   RRSIG10(SOA1)
+                     -------->
+     DNSKEY1         -------->        DNSKEY2         DNSKEY2
+                     -------->
+     DNSKEY10        -------->        DNSKEY10        DNSKEY10
+     RRSIG1 (DNSKEY) -------->        RRSIG2(DNSKEY)  RRSIG2 (DNSKEY)
+     RRSIG10(DNSKEY) -------->        RRSIG10(DNSKEY) RRSIG10(DNSKEY)
+   --------------------------------------------------------------------
+
+      Stages of Deployment for a Pre-Publish Key Signing Key Rollover
+
+
+
+
+
+
+Kolkman & Gieben             Informational                     [Page 20]
+
+RFC 4641              DNSSEC Operational Practices        September 2006
+
+
+   When the child zone wants to roll, it notifies the parent during the
+   "new DS" phase and submits the new key (or the corresponding DS) to
+   the parent.  The parent publishes DS1 and DS2, pointing to DNSKEY1
+   and DNSKEY2, respectively.  During the rollover ("new DNSKEY" phase),
+   which can take place as soon as the new DS set propagated through the
+   DNS, the child replaces DNSKEY1 with DNSKEY2.  Immediately after that
+   ("DS/DNSKEY removal" phase), it can notify the parent that the old DS
+   record can be deleted.
+
+   The drawbacks of this scheme are that during the "new DS" phase the
+   parent cannot verify the match between the DS2 RR and DNSKEY2 using
+   the DNS -- as DNSKEY2 is not yet published.  Besides, we introduce a
+   "security lame" key (see Section 4.4.3).  Finally, the child-parent
+   interaction consists of two steps.  The "double signature" method
+   only needs one interaction.
+
+4.2.4.  Automated Key Rollovers
+
+   As keys must be renewed periodically, there is some motivation to
+   automate the rollover process.  Consider the following:
+
+   o  ZSK rollovers are easy to automate as only the child zone is
+      involved.
+
+   o  A KSK rollover needs interaction between parent and child.  Data
+      exchange is needed to provide the new keys to the parent;
+      consequently, this data must be authenticated and integrity must
+      be guaranteed in order to avoid attacks on the rollover.
+
+4.3.  Planning for Emergency Key Rollover
+
+   This section deals with preparation for a possible key compromise.
+   Our advice is to have a documented procedure ready for when a key
+   compromise is suspected or confirmed.
+
+   When the private material of one of your keys is compromised it can
+   be used for as long as a valid trust chain exists.  A trust chain
+   remains intact for
+
+   o  as long as a signature over the compromised key in the trust chain
+      is valid,
+
+   o  as long as a parental DS RR (and signature) points to the
+      compromised key,
+
+   o  as long as the key is anchored in a resolver and is used as a
+      starting point for validation (this is generally the hardest to
+      update).
+
+
+
+Kolkman & Gieben             Informational                     [Page 21]
+
+RFC 4641              DNSSEC Operational Practices        September 2006
+
+
+   While a trust chain to your compromised key exists, your namespace is
+   vulnerable to abuse by anyone who has obtained illegitimate
+   possession of the key.  Zone operators have to make a trade-off if
+   the abuse of the compromised key is worse than having data in caches
+   that cannot be validated.  If the zone operator chooses to break the
+   trust chain to the compromised key, data in caches signed with this
+   key cannot be validated.  However, if the zone administrator chooses
+   to take the path of a regular rollover, the malicious key holder can
+   spoof data so that it appears to be valid.
+
+4.3.1.  KSK Compromise
+
+   A zone containing a DNSKEY RRSet with a compromised KSK is vulnerable
+   as long as the compromised KSK is configured as trust anchor or a
+   parental DS points to it.
+
+   A compromised KSK can be used to sign the key set of an attacker's
+   zone.  That zone could be used to poison the DNS.
+
+   Therefore, when the KSK has been compromised, the trust anchor or the
+   parental DS should be replaced as soon as possible.  It is local
+   policy whether to break the trust chain during the emergency
+   rollover.  The trust chain would be broken when the compromised KSK
+   is removed from the child's zone while the parent still has a DS
+   pointing to the compromised KSK (the assumption is that there is only
+   one DS at the parent.  If there are multiple DSes this does not apply
+   -- however the chain of trust of this particular key is broken).
+
+   Note that an attacker's zone still uses the compromised KSK and the
+   presence of a parental DS would cause the data in this zone to appear
+   as valid.  Removing the compromised key would cause the attacker's
+   zone to appear as valid and the child's zone as Bogus.  Therefore, we
+   advise not to remove the KSK before the parent has a DS to a new KSK
+   in place.
+
+4.3.1.1.  Keeping the Chain of Trust Intact
+
+   If we follow this advice, the timing of the replacement of the KSK is
+   somewhat critical.  The goal is to remove the compromised KSK as soon
+   as the new DS RR is available at the parent.  And also make sure that
+   the signature made with a new KSK over the key set with the
+   compromised KSK in it expires just after the new DS appears at the
+   parent, thus removing the old cruft in one swoop.
+
+   The procedure is as follows:
+
+   1.  Introduce a new KSK into the key set, keep the compromised KSK in
+       the key set.
+
+
+
+Kolkman & Gieben             Informational                     [Page 22]
+
+RFC 4641              DNSSEC Operational Practices        September 2006
+
+
+   2.  Sign the key set, with a short validity period.  The validity
+       period should expire shortly after the DS is expected to appear
+       in the parent and the old DSes have expired from caches.
+
+   3.  Upload the DS for this new key to the parent.
+
+   4.  Follow the procedure of the regular KSK rollover: Wait for the DS
+       to appear in the authoritative servers and then wait as long as
+       the TTL of the old DS RRs.  If necessary re-sign the DNSKEY RRSet
+       and modify/extend the expiration time.
+
+   5.  Remove the compromised DNSKEY RR from the zone and re-sign the
+       key set using your "normal" validity interval.
+
+   An additional danger of a key compromise is that the compromised key
+   could be used to facilitate a legitimate DNSKEY/DS rollover and/or
+   nameserver changes at the parent.  When that happens, the domain may
+   be in dispute.  An authenticated out-of-band and secure notify
+   mechanism to contact a parent is needed in this case.
+
+   Note that this is only a problem when the DNSKEY and or DS records
+   are used for authentication at the parent.
+
+4.3.1.2.  Breaking the Chain of Trust
+
+   There are two methods to break the chain of trust.  The first method
+   causes the child zone to appear 'Bogus' to validating resolvers.  The
+   other causes the child zone to appear 'insecure'.  These are
+   described below.
+
+   In the method that causes the child zone to appear 'Bogus' to
+   validating resolvers, the child zone replaces the current KSK with a
+   new one and re-signs the key set.  Next it sends the DS of the new
+   key to the parent.  Only after the parent has placed the new DS in
+   the zone is the child's chain of trust repaired.
+
+   An alternative method of breaking the chain of trust is by removing
+   the DS RRs from the parent zone altogether.  As a result, the child
+   zone would become insecure.
+
+4.3.2.  ZSK Compromise
+
+   Primarily because there is no parental interaction required when a
+   ZSK is compromised, the situation is less severe than with a KSK
+   compromise.  The zone must still be re-signed with a new ZSK as soon
+   as possible.  As this is a local operation and requires no
+   communication between the parent and child, this can be achieved
+   fairly quickly.  However, one has to take into account that just as
+
+
+
+Kolkman & Gieben             Informational                     [Page 23]
+
+RFC 4641              DNSSEC Operational Practices        September 2006
+
+
+   with a normal rollover the immediate disappearance of the old
+   compromised key may lead to verification problems.  Also note that as
+   long as the RRSIG over the compromised ZSK is not expired the zone
+   may be still at risk.
+
+4.3.3.  Compromises of Keys Anchored in Resolvers
+
+   A key can also be pre-configured in resolvers.  For instance, if
+   DNSSEC is successfully deployed the root key may be pre-configured in
+   most security aware resolvers.
+
+   If trust-anchor keys are compromised, the resolvers using these keys
+   should be notified of this fact.  Zone administrators may consider
+   setting up a mailing list to communicate the fact that a SEP key is
+   about to be rolled over.  This communication will of course need to
+   be authenticated, e.g., by using digital signatures.
+
+   End-users faced with the task of updating an anchored key should
+   always validate the new key.  New keys should be authenticated out-
+   of-band, for example, through the use of an announcement website that
+   is secured using secure sockets (TLS) [21].
+
+4.4.  Parental Policies
+
+4.4.1.  Initial Key Exchanges and Parental Policies Considerations
+
+   The initial key exchange is always subject to the policies set by the
+   parent.  When designing a key exchange policy one should take into
+   account that the authentication and authorization mechanisms used
+   during a key exchange should be as strong as the authentication and
+   authorization mechanisms used for the exchange of delegation
+   information between parent and child.  That is, there is no implicit
+   need in DNSSEC to make the authentication process stronger than it
+   was in DNS.
+
+   Using the DNS itself as the source for the actual DNSKEY material,
+   with an out-of-band check on the validity of the DNSKEY, has the
+   benefit that it reduces the chances of user error.  A DNSKEY query
+   tool can make use of the SEP bit [3] to select the proper key from a
+   DNSSEC key set, thereby reducing the chance that the wrong DNSKEY is
+   sent.  It can validate the self-signature over a key; thereby
+   verifying the ownership of the private key material.  Fetching the
+   DNSKEY from the DNS ensures that the chain of trust remains intact
+   once the parent publishes the DS RR indicating the child is secure.
+
+   Note: the out-of-band verification is still needed when the key
+   material is fetched via the DNS.  The parent can never be sure
+   whether or not the DNSKEY RRs have been spoofed.
+
+
+
+Kolkman & Gieben             Informational                     [Page 24]
+
+RFC 4641              DNSSEC Operational Practices        September 2006
+
+
+4.4.2.  Storing Keys or Hashes?
+
+   When designing a registry system one should consider which of the
+   DNSKEYs and/or the corresponding DSes to store.  Since a child zone
+   might wish to have a DS published using a message digest algorithm
+   not yet understood by the registry, the registry can't count on being
+   able to generate the DS record from a raw DNSKEY.  Thus, we recommend
+   that registry systems at least support storing DS records.
+
+   It may also be useful to store DNSKEYs, since having them may help
+   during troubleshooting and, as long as the child's chosen message
+   digest is supported, the overhead of generating DS records from them
+   is minimal.  Having an out-of-band mechanism, such as a registry
+   directory (e.g., Whois), to find out which keys are used to generate
+   DS Resource Records for specific owners and/or zones may also help
+   with troubleshooting.
+
+   The storage considerations also relate to the design of the customer
+   interface and the method by which data is transferred between
+   registrant and registry; Will the child zone administrator be able to
+   upload DS RRs with unknown hash algorithms or does the interface only
+   allow DNSKEYs?  In the registry-registrar model, one can use the
+   DNSSEC extensions to the Extensible Provisioning Protocol (EPP) [15],
+   which allows transfer of DS RRs and optionally DNSKEY RRs.
+
+4.4.3.  Security Lameness
+
+   Security lameness is defined as what happens when a parent has a DS
+   RR pointing to a non-existing DNSKEY RR.  When this happens, the
+   child's zone may be marked "Bogus" by verifying DNS clients.
+
+   As part of a comprehensive delegation check, the parent could, at key
+   exchange time, verify that the child's key is actually configured in
+   the DNS.  However, if a parent does not understand the hashing
+   algorithm used by child, the parental checks are limited to only
+   comparing the key id.
+
+   Child zones should be very careful in removing DNSKEY material,
+   specifically SEP keys, for which a DS RR exists.
+
+   Once a zone is "security lame", a fix (e.g., removing a DS RR) will
+   take time to propagate through the DNS.
+
+
+
+
+
+
+
+
+
+Kolkman & Gieben             Informational                     [Page 25]
+
+RFC 4641              DNSSEC Operational Practices        September 2006
+
+
+4.4.4.  DS Signature Validity Period
+
+   Since the DS can be replayed as long as it has a valid signature, a
+   short signature validity period over the DS minimizes the time a
+   child is vulnerable in the case of a compromise of the child's
+   KSK(s).  A signature validity period that is too short introduces the
+   possibility that a zone is marked "Bogus" in case of a configuration
+   error in the signer.  There may not be enough time to fix the
+   problems before signatures expire.  Something as mundane as operator
+   unavailability during weekends shows the need for DS signature
+   validity periods longer than 2 days.  We recommend an absolute
+   minimum for a DS signature validity period of a few days.
+
+   The maximum signature validity period of the DS record depends on how
+   long child zones are willing to be vulnerable after a key compromise.
+   On the other hand, shortening the DS signature validity interval
+   increases the operational risk for the parent.  Therefore, the parent
+   may have policy to use a signature validity interval that is
+   considerably longer than the child would hope for.
+
+   A compromise between the operational constraints of the parent and
+   minimizing damage for the child may result in a DS signature validity
+   period somewhere between a week and months.
+
+   In addition to the signature validity period, which sets a lower
+   bound on the number of times the zone owner will need to sign the
+   zone data and which sets an upper bound to the time a child is
+   vulnerable after key compromise, there is the TTL value on the DS
+   RRs.  Shortening the TTL means that the authoritative servers will
+   see more queries.  But on the other hand, a short TTL lowers the
+   persistence of DS RRSets in caches thereby increasing the speed with
+   which updated DS RRSets propagate through the DNS.
+
+5.  Security Considerations
+
+   DNSSEC adds data integrity to the DNS.  This document tries to assess
+   the operational considerations to maintain a stable and secure DNSSEC
+   service.  Not taking into account the 'data propagation' properties
+   in the DNS will cause validation failures and may make secured zones
+   unavailable to security-aware resolvers.
+
+6.  Acknowledgments
+
+   Most of the ideas in this document were the result of collective
+   efforts during workshops, discussions, and tryouts.
+
+   At the risk of forgetting individuals who were the original
+   contributors of the ideas, we would like to acknowledge people who
+
+
+
+Kolkman & Gieben             Informational                     [Page 26]
+
+RFC 4641              DNSSEC Operational Practices        September 2006
+
+
+   were actively involved in the compilation of this document.  In
+   random order: Rip Loomis, Olafur Gudmundsson, Wesley Griffin, Michael
+   Richardson, Scott Rose, Rick van Rein, Tim McGinnis, Gilles Guette
+   Olivier Courtay, Sam Weiler, Jelte Jansen, Niall O'Reilly, Holger
+   Zuleger, Ed Lewis, Hilarie Orman, Marcos Sanz, and Peter Koch.
+
+   Some material in this document has been copied from RFC 2541 [12].
+
+   Mike StJohns designed the key exchange between parent and child
+   mentioned in the last paragraph of Section 4.2.2
+
+   Section 4.2.4 was supplied by G. Guette and O. Courtay.
+
+   Emma Bretherick, Adrian Bedford, and Lindy Foster corrected many of
+   the spelling and style issues.
+
+   Kolkman and Gieben take the blame for introducing all miscakes (sic).
+
+   While working on this document, Kolkman was employed by the RIPE NCC
+   and Gieben was employed by NLnet Labs.
+
+7.  References
+
+7.1.  Normative References
+
+   [1]   Mockapetris, P., "Domain names - concepts and facilities", STD
+         13, RFC 1034, November 1987.
+
+   [2]   Mockapetris, P., "Domain names - implementation and
+         specification", STD 13, RFC 1035, November 1987.
+
+   [3]   Kolkman, O., Schlyter, J., and E. Lewis, "Domain Name System
+         KEY (DNSKEY) Resource Record (RR) Secure Entry Point (SEP)
+         Flag", RFC 3757, May 2004.
+
+   [4]   Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+         "DNS Security Introduction and Requirements", RFC 4033, March
+         2005.
+
+   [5]   Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+         "Resource Records for the DNS Security Extensions", RFC 4034,
+         March 2005.
+
+   [6]   Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
+         "Protocol Modifications for the DNS Security Extensions", RFC
+         4035, March 2005.
+
+
+
+
+
+Kolkman & Gieben             Informational                     [Page 27]
+
+RFC 4641              DNSSEC Operational Practices        September 2006
+
+
+7.2.  Informative References
+
+   [7]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
+         Levels", BCP 14, RFC 2119, March 1997.
+
+   [8]   Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, August
+         1996.
+
+   [9]   Vixie, P., "A Mechanism for Prompt Notification of Zone Changes
+         (DNS NOTIFY)", RFC 1996, August 1996.
+
+   [10]  Wellington, B., "Secure Domain Name System (DNS) Dynamic
+         Update", RFC 3007, November 2000.
+
+   [11]  Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)",
+         RFC 2308, March 1998.
+
+   [12]  Eastlake, D., "DNS Security Operational Considerations", RFC
+         2541, March 1999.
+
+   [13]  Orman, H. and P. Hoffman, "Determining Strengths For Public
+         Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766,
+         April 2004.
+
+   [14]  Eastlake, D., Schiller, J., and S. Crocker, "Randomness
+         Requirements for Security", BCP 106, RFC 4086, June 2005.
+
+   [15]  Hollenbeck, S., "Domain Name System (DNS) Security Extensions
+         Mapping for the Extensible Provisioning Protocol (EPP)", RFC
+         4310, December 2005.
+
+   [16]  Lenstra, A. and E. Verheul, "Selecting Cryptographic Key
+         Sizes", The Journal of Cryptology 14 (255-293), 2001.
+
+   [17]  Schneier, B., "Applied Cryptography: Protocols, Algorithms, and
+         Source Code in C", ISBN (hardcover) 0-471-12845-7, ISBN
+         (paperback) 0-471-59756-2, Published by John Wiley & Sons Inc.,
+         1996.
+
+   [18]  Rose, S., "NIST DNSSEC workshop notes", June 2001.
+
+   [19]  Jansen, J., "Use of RSA/SHA-256 DNSKEY and RRSIG Resource
+         Records in DNSSEC", Work in Progress, January 2006.
+
+   [20]  Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer (DS)
+         Resource Records (RRs)", RFC 4509, May 2006.
+
+
+
+
+
+Kolkman & Gieben             Informational                     [Page 28]
+
+RFC 4641              DNSSEC Operational Practices        September 2006
+
+
+   [21]  Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and
+         T. Wright, "Transport Layer Security (TLS) Extensions", RFC
+         4366, April 2006.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kolkman & Gieben             Informational                     [Page 29]
+
+RFC 4641              DNSSEC Operational Practices        September 2006
+
+
+Appendix A.  Terminology
+
+   In this document, there is some jargon used that is defined in other
+   documents.  In most cases, we have not copied the text from the
+   documents defining the terms but have given a more elaborate
+   explanation of the meaning.  Note that these explanations should not
+   be seen as authoritative.
+
+   Anchored key: A DNSKEY configured in resolvers around the globe.
+      This key is hard to update, hence the term anchored.
+
+   Bogus: Also see Section 5 of [4].  An RRSet in DNSSEC is marked
+      "Bogus" when a signature of an RRSet does not validate against a
+      DNSKEY.
+
+   Key Signing Key or KSK: A Key Signing Key (KSK) is a key that is used
+      exclusively for signing the apex key set.  The fact that a key is
+      a KSK is only relevant to the signing tool.
+
+   Key size: The term 'key size' can be substituted by 'modulus size'
+      throughout the document.  It is mathematically more correct to use
+      modulus size, but as this is a document directed at operators we
+      feel more at ease with the term key size.
+
+   Private and public keys: DNSSEC secures the DNS through the use of
+      public key cryptography.  Public key cryptography is based on the
+      existence of two (mathematically related) keys, a public key and a
+      private key.  The public keys are published in the DNS by use of
+      the DNSKEY Resource Record (DNSKEY RR).  Private keys should
+      remain private.
+
+   Key rollover: A key rollover (also called key supercession in some
+      environments) is the act of replacing one key pair with another at
+      the end of a key effectivity period.
+
+   Secure Entry Point (SEP) key: A KSK that has a parental DS record
+      pointing to it or is configured as a trust anchor.  Although not
+      required by the protocol, we recommend that the SEP flag [3] is
+      set on these keys.
+
+   Self-signature: This only applies to signatures over DNSKEYs; a
+      signature made with DNSKEY x, over DNSKEY x is called a self-
+      signature.  Note: without further information, self-signatures
+      convey no trust.  They are useful to check the authenticity of the
+      DNSKEY, i.e., they can be used as a hash.
+
+
+
+
+
+
+Kolkman & Gieben             Informational                     [Page 30]
+
+RFC 4641              DNSSEC Operational Practices        September 2006
+
+
+   Singing the zone file: The term used for the event where an
+      administrator joyfully signs its zone file while producing melodic
+      sound patterns.
+
+   Signer: The system that has access to the private key material and
+      signs the Resource Record sets in a zone.  A signer may be
+      configured to sign only parts of the zone, e.g., only those RRSets
+      for which existing signatures are about to expire.
+
+   Zone Signing Key (ZSK): A key that is used for signing all data in a
+      zone.  The fact that a key is a ZSK is only relevant to the
+      signing tool.
+
+   Zone administrator: The 'role' that is responsible for signing a zone
+      and publishing it on the primary authoritative server.
+
+Appendix B.  Zone Signing Key Rollover How-To
+
+   Using the pre-published signature scheme and the most conservative
+   method to assure oneself that data does not live in caches, here
+   follows the "how-to".
+
+   Step 0: The preparation: Create two keys and publish both in your key
+      set.  Mark one of the keys "active" and the other "published".
+      Use the "active" key for signing your zone data.  Store the
+      private part of the "published" key, preferably off-line.  The
+      protocol does not provide for attributes to mark a key as active
+      or published.  This is something you have to do on your own,
+      through the use of a notebook or key management tool.
+
+   Step 1: Determine expiration: At the beginning of the rollover make a
+      note of the highest expiration time of signatures in your zone
+      file created with the current key marked as active.  Wait until
+      the expiration time marked in Step 1 has passed.
+
+   Step 2: Then start using the key that was marked "published" to sign
+      your data (i.e., mark it "active").  Stop using the key that was
+      marked "active"; mark it "rolled".
+
+   Step 3: It is safe to engage in a new rollover (Step 1) after at
+      least one signature validity period.
+
+
+
+
+
+
+
+
+
+
+Kolkman & Gieben             Informational                     [Page 31]
+
+RFC 4641              DNSSEC Operational Practices        September 2006
+
+
+Appendix C.  Typographic Conventions
+
+   The following typographic conventions are used in this document:
+
+   Key notation: A key is denoted by DNSKEYx, where x is a number or an
+   identifier, x could be thought of as the key id.
+
+   RRSet notations: RRs are only denoted by the type.  All other
+   information -- owner, class, rdata, and TTL--is left out.  Thus:
+   "example.com 3600 IN A 192.0.2.1" is reduced to "A".  RRSets are a
+   list of RRs.  A example of this would be "A1, A2", specifying the
+   RRSet containing two "A" records.  This could again be abbreviated to
+   just "A".
+
+   Signature notation: Signatures are denoted as RRSIGx(RRSet), which
+   means that RRSet is signed with DNSKEYx.
+
+   Zone representation: Using the above notation we have simplified the
+   representation of a signed zone by leaving out all unnecessary
+   details such as the names and by representing all data by "SOAx"
+
+   SOA representation: SOAs are represented as SOAx, where x is the
+   serial number.
+
+   Using this notation the following signed zone:
+
+   example.net.      86400  IN SOA  ns.example.net. bert.example.net. (
+                            2006022100   ; serial
+                            86400        ; refresh (  24 hours)
+                            7200         ; retry   (   2 hours)
+                            3600000      ; expire  (1000 hours)
+                            28800 )      ; minimum (   8 hours)
+                     86400  RRSIG   SOA 5 2 86400 20130522213204 (
+                                  20130422213204 14 example.net.
+                                  cmL62SI6iAX46xGNQAdQ... )
+                     86400  NS      a.iana-servers.net.
+                     86400  NS      b.iana-servers.net.
+                     86400  RRSIG   NS 5 2 86400 20130507213204 (
+                                  20130407213204 14 example.net.
+                                  SO5epiJei19AjXoUpFnQ ... )
+                     86400  DNSKEY  256 3 5 (
+                                  EtRB9MP5/AvOuVO0I8XDxy0... ) ; id = 14
+                     86400  DNSKEY  257 3 5 (
+                                  gsPW/Yy19GzYIY+Gnr8HABU... ) ; id = 15
+                     86400  RRSIG   DNSKEY 5 2 86400 20130522213204 (
+                                  20130422213204 14 example.net.
+                                  J4zCe8QX4tXVGjV4e1r9... )
+
+
+
+
+Kolkman & Gieben             Informational                     [Page 32]
+
+RFC 4641              DNSSEC Operational Practices        September 2006
+
+
+                     86400  RRSIG   DNSKEY 5 2 86400 20130522213204 (
+                                  20130422213204 15 example.net.
+                                  keVDCOpsSeDReyV6O... )
+                     86400  RRSIG   NSEC 5 2 86400 20130507213204 (
+                                  20130407213204 14 example.net.
+                                  obj3HEp1GjnmhRjX... )
+   a.example.net.    86400  IN TXT  "A label"
+                     86400  RRSIG   TXT 5 3 86400 20130507213204 (
+                                  20130407213204 14 example.net.
+                                  IkDMlRdYLmXH7QJnuF3v... )
+                     86400  NSEC    b.example.com. TXT RRSIG NSEC
+                     86400  RRSIG   NSEC 5 3 86400 20130507213204 (
+                                  20130407213204 14 example.net.
+                                  bZMjoZ3bHjnEz0nIsPMM... )
+                     ...
+
+   is reduced to the following representation:
+
+       SOA2006022100
+       RRSIG14(SOA2006022100)
+       DNSKEY14
+       DNSKEY15
+
+       RRSIG14(KEY)
+       RRSIG15(KEY)
+
+   The rest of the zone data has the same signature as the SOA record,
+   i.e., an RRSIG created with DNSKEY 14.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kolkman & Gieben             Informational                     [Page 33]
+
+RFC 4641              DNSSEC Operational Practices        September 2006
+
+
+Authors' Addresses
+
+   Olaf M. Kolkman
+   NLnet Labs
+   Kruislaan 419
+   Amsterdam  1098 VA
+   The Netherlands
+
+   EMail: olaf@nlnetlabs.nl
+   URI:   http://www.nlnetlabs.nl
+
+
+   R. (Miek) Gieben
+
+   EMail: miek@miek.nl
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kolkman & Gieben             Informational                     [Page 34]
+
+RFC 4641              DNSSEC Operational Practices        September 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Kolkman & Gieben             Informational                     [Page 35]
+
diff --git a/doc/rfc/rfc4648.txt b/doc/rfc/rfc4648.txt
new file mode 100644
index 0000000..c7599b4
--- /dev/null
+++ b/doc/rfc/rfc4648.txt
@@ -0,0 +1,1011 @@
+
+
+
+
+
+
+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
new file mode 100644
index 0000000..03e3c54
--- /dev/null
+++ b/doc/rfc/rfc4701.txt
@@ -0,0 +1,675 @@
+
+
+
+
+
+
+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
new file mode 100644
index 0000000..d4b7297
--- /dev/null
+++ b/doc/rfc/rfc5155.txt
@@ -0,0 +1,2915 @@
+
+
+
+
+
+
+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
new file mode 100644
index 0000000..7df339a
--- /dev/null
+++ b/doc/rfc/rfc952.txt
@@ -0,0 +1,340 @@
+Network Working Group                               K. Harrenstien (SRI)
+Request for Comments: 952                                 M. Stahl (SRI)
+                                                        E. Feinler (SRI)
+Obsoletes:  RFC 810, 608                                    October 1985
+
+                 DOD INTERNET HOST TABLE SPECIFICATION
+
+
+STATUS OF THIS MEMO
+
+   This RFC is the official specification of the format of the Internet
+   Host Table.  This edition of the specification includes minor
+   revisions to RFC-810 which brings it up to date. Distribution of this
+   memo is unlimited.
+
+INTRODUCTION
+
+   The DoD Host Table is utilized by the DoD Hostname Server maintained
+   by the DDN Network Information Center (NIC) on behalf of the Defense
+   Communications Agency (DCA) [See RFC-953].
+
+LOCATION OF THE STANDARD DOD ONLINE HOST TABLE
+
+   A machine-translatable ASCII text version of the DoD Host Table is
+   online in the file NETINFO:HOSTS.TXT on the SRI-NIC host.  It can be
+   obtained via FTP from your local host by connecting to host
+   SRI-NIC.ARPA (26.0.0.73 or 10.0.0.51), logging in as user =
+   ANONYMOUS, password = GUEST, and retrieving the file
+   "NETINFO:HOSTS.TXT".  The same table may also be obtained via the NIC
+   Hostname Server, as described in RFC-953.  The latter method is
+   faster and easier, but requires a user program to make the necessary
+   connection to the Name Server.
+
+ASSUMPTIONS
+
+   1. A "name" (Net, Host, Gateway, or Domain name) is a text string up
+   to 24 characters drawn from the alphabet (A-Z), digits (0-9), minus
+   sign (-), and period (.).  Note that periods are only allowed when
+   they serve to delimit components of "domain style names". (See
+   RFC-921, "Domain Name System Implementation Schedule", for
+   background).  No blank or space characters are permitted as part of a
+   name. No distinction is made between upper and lower case.  The first
+   character must be an alpha character.  The last character must not be
+   a minus sign or period.  A host which serves as a GATEWAY should have
+   "-GATEWAY" or "-GW" as part of its name.  Hosts which do not serve as
+   Internet gateways should not use "-GATEWAY" and "-GW" as part of
+   their names. A host which is a TAC should have "-TAC" as the last
+   part of its host name, if it is a DoD host.  Single character names
+   or nicknames are not allowed.
+
+   2. Internet Addresses are 32-bit addresses [See RFC-796].  In the
+
+
+Harrenstien & Stahl & Feinler                                   [Page 1]
+
+
+
+RFC 952                                                     October 1985
+DOD INTERNET HOST TABLE SPECIFICATION
+
+
+   host table described herein each address is represented by four
+   decimal numbers separated by a period.  Each decimal number
+   represents 1 octet.
+
+   3. If the first bit of the first octet of the address is 0 (zero),
+   then the next 7 bits of the first octet indicate the network number
+   (Class A Address).  If the first two bits are 1,0 (one,zero), then
+   the next 14 bits define the net number (Class B Address).  If the
+   first 3 bits are 1,1,0 (one,one,zero), then the next 21 bits define
+   the net number (Class C Address) [See RFC-943].
+
+      This is depicted in the following diagram:
+
+      +-+------------+--------------+--------------+--------------+
+      |0|  NET <-7-> |         LOCAL ADDRESS <-24->               |
+      +-+------------+--------------+--------------+--------------+
+
+      +---+----------+--------------+--------------+--------------+
+      |1 0|      NET  <-14->        |  LOCAL ADDRESS <-16->       |
+      +---+----------+--------------+--------------+--------------+
+
+      +-----+--------+--------------+--------------+--------------+
+      |1 1 0|            NET  <-21->               | LOCAL ADDRESS|
+      +-----+--------+--------------+--------------+--------------+
+
+   4. The LOCAL ADDRESS portion of the internet address identifies a
+   host within the network specified by the NET portion of the address.
+
+   5. The ARPANET and MILNET are both Class A networks.  The NET portion
+   is 10 decimal for ARPANET, 26 decimal for MILNET, and the LOCAL
+   ADDRESS maps as follows: the second octet identifies the physical
+   host, the third octet identifies the logical host, and the fourth
+   identifies the Packet Switching Node (PSN), formerly known as an
+   Interface Message Processor (IMP).
+
+      +-+------------+--------------+--------------+--------------+
+      |0|  10 or 26  |    HOST      | LOGICAL HOST |   PSN (IMP)  |
+      +-+------------+--------------+--------------+--------------+
+
+      (NOTE:  RFC-796 also describes the local address mappings for
+      several other networks.)
+
+   6. It is the responsibility of the users of this host table to
+   translate it into whatever format is needed for their purposes.
+
+   7. Names and addresses for DoD hosts and gateways will be negotiated
+   and registered with the DDN PMO, and subsequently with the NIC,
+
+
+Harrenstien & Stahl & Feinler                                   [Page 2]
+
+
+
+RFC 952                                                     October 1985
+DOD INTERNET HOST TABLE SPECIFICATION
+
+
+   before being used and before traffic is passed by a DoD host.  Names
+   and addresses for domains and networks are to be registered with the
+   DDN Network Information Center (HOSTMASTER@SRI-NIC.ARPA) or
+   800-235-3155.
+
+   The NIC will attempt to keep similar information for non-DoD networks
+   and hosts, if this information is provided, and as long as it is
+   needed, i.e., until intercommunicating network name servers are in
+   place.
+
+EXAMPLE OF HOST TABLE FORMAT
+
+   NET : 10.0.0.0 : ARPANET :
+   NET : 128.10.0.0 : PURDUE-CS-NET :
+   GATEWAY : 10.0.0.77, 18.10.0.4 : MIT-GW.ARPA,MIT-GATEWAY : PDP-11 :
+             MOS : IP/GW,EGP :
+   HOST : 26.0.0.73, 10.0.0.51 : SRI-NIC.ARPA,SRI-NIC,NIC : DEC-2060 :
+          TOPS20 :TCP/TELNET,TCP/SMTP,TCP/TIME,TCP/FTP,TCP/ECHO,ICMP :
+   HOST : 10.2.0.11 : SU-TAC.ARPA,SU-TAC : C/30 : TAC : TCP :
+
+SYNTAX AND CONVENTIONS
+
+   ; (semicolon)   is used to denote the beginning of a comment.
+                   Any text on a given line following a ';' is a
+                   comment, and not part of the host table.
+
+   NET             keyword introducing a network entry
+
+   GATEWAY         keyword introducing a gateway entry
+
+   HOST            keyword introducing a host entry
+
+   DOMAIN          keyword introducing a domain entry
+
+   :(colon)        is used as a field delimiter
+
+   ::(2 colons)    indicates a null field
+
+   ,(comma)        is used as a data element delimiter
+
+   XXX/YYY         indicates protocol information of the type
+                   TRANSPORT/SERVICE.
+
+      where TRANSPORT/SERVICE options are specified as
+
+         "FOO/BAR"       both transport and service known
+
+
+
+Harrenstien & Stahl & Feinler                                   [Page 3]
+
+
+
+RFC 952                                                     October 1985
+DOD INTERNET HOST TABLE SPECIFICATION
+
+
+         "FOO"           transport known; services not known
+
+         "BAR"           service is known, transport not known
+
+         NOTE:  See "Assigned Numbers" for specific options and acronyms
+         for machine types, operating systems, and protocol/services.
+
+   Each host table entry is an ASCII text string comprised of 6 fields,
+   where
+
+      Field 1         KEYWORD indicating whether this entry pertains to
+                      a NET, GATEWAY, HOST, or DOMAIN.  NET entries are
+                      assigned and cannot have alternate addresses or
+                      nicknames.  DOMAIN entries do not use fields 4, 5,
+                      or 6.
+
+      Field 2         Internet Address of Network, Gateway, or Host
+                      followed by alternate addresses.  Addresses for a
+                      Domain are those where a Domain Name Server exists
+                      for that domain.
+
+      Field 3         Official Name of Network, Gateway, Host, or Domain
+                      (with optional nicknames, where permitted).
+
+      Field 4         Machine Type
+
+      Field 5         Operating System
+
+      Field 6         Protocol List
+
+   Fields 4, 5 and 6 are optional.  For a Domain they are not used.
+
+   Fields 3-6, if included, pertain to the first address in Field 2.
+
+   'Blanks' (spaces and tabs) are ignored between data elements or
+   fields, but are disallowed within a data element.
+
+   Each entry ends with a colon.
+
+   The entries in the table are grouped by types in the order Domain,
+   Net, Gateway, and Host.  Within each type the ordering is
+   unspecified.
+
+   Note that although optional nicknames are allowed for hosts, they are
+   discouraged, except in the case where host names have been changed
+
+
+
+
+Harrenstien & Stahl & Feinler                                   [Page 4]
+
+
+
+RFC 952                                                     October 1985
+DOD INTERNET HOST TABLE SPECIFICATION
+
+
+   and both the new and the old names are maintained for a suitable
+   period of time to effect a smooth transition.  Nicknames are not
+   permitted for NET names.
+
+GRAMMATICAL HOST TABLE SPECIFICATION
+
+   A. Parsing grammar
+
+      <entry> ::= <keyword> ":" <addresses> ":" <names> [":" [<cputype>]
+         [":" [<opsys>]  [":" [<protocol list>] ]]] ":"
+      <addresses> ::= <address> *["," <address>]
+      <address> ::= <octet> "." <octet> "." <octet> "." <octet>
+      <octet> ::= <0 to 255 decimal>
+      <names> ::= <netname> | <gatename> | <domainname> *[","
+         <nicknames>]
+         | <official hostname> *["," <nicknames>]
+      <netname>  ::= <name>
+      <gatename> ::= <hname>
+      <domainname> ::= <hname>
+      <official hostname> ::= <hname>
+      <nickname> ::= <hname>
+      <protocol list> ::= <protocol spec> *["," <protocol spec>]
+      <protocol spec> ::= <transport name> "/" <service name>
+         | <raw protocol name>
+
+   B. Lexical grammar
+
+      <entry-field> ::= <entry-text> [<cr><lf> <blank> <entry-field>]
+      <entry-text>  ::= <print-char> *<text>
+      <blank> ::= <space-or-tab> [<blank>]
+      <keyword> ::= NET | GATEWAY | HOST | DOMAIN
+      <hname> ::= <name>*["."<name>]
+      <name>  ::= <let>[*[<let-or-digit-or-hyphen>]<let-or-digit>]
+      <cputype> ::= PDP-11/70 | DEC-1080 | C/30 | CDC-6400...etc.
+      <opsys>   ::= ITS | MULTICS | TOPS20 | UNIX...etc.
+      <transport name> ::= TCP | NCP | UDP | IP...etc.
+      <service name> ::= TELNET | FTP | SMTP | MTP...etc.
+      <raw protocol name> ::= <name>
+      <comment> ::= ";" <text><cr><lf>
+      <text>    ::= *[<print-char> | <blank>]
+      <print-char>  ::= <any printing char (not space or tab)>
+
+   Notes:
+
+      1. Zero or more 'blanks' between separators " , : " are allowed.
+      'Blanks' are spaces and tabs.
+
+
+
+Harrenstien & Stahl & Feinler                                   [Page 5]
+
+
+
+RFC 952                                                     October 1985
+DOD INTERNET HOST TABLE SPECIFICATION
+
+
+      2. Continuation lines are lines that begin with at least one
+      blank.  They may be used anywhere 'blanks' are legal to split an
+      entry across lines.
+
+BIBLIOGRAPHY
+
+   1. Feinler, E., Harrenstien, K., Su, Z. and White, V., "Official DoD
+      Internet Host Table Specification", RFC-810, Network Information
+      Center, SRI International, March 1982.
+
+   2. Harrenstien, K., Stahl, M., and Feinler, E., "Hostname Server",
+      RFC-953, Network Information Center, SRI International, October
+      1985.
+
+   3. Kudlick, M. "Host Names Online", RFC-608, Network Information
+      Center, SRI International, January 1973.
+
+   4. Postel, J., "Internet Protocol", RFC-791, Information Sciences
+      Institute, University of Southern California, Marina del Rey,
+      September 1981.
+
+   5. Postel, J., "Address Mappings", RFC-796, Information Sciences
+      Institute, University of Southern California, Marina del Rey,
+      September 1981.
+
+   6. Postel, J., "Domain Name System Implementation Schedule", RFC-921,
+      Information Sciences Institute, University of Southern California,
+      Marina del Rey, October 1984.
+
+   7. Reynolds, J. and Postel, J., "Assigned Numbers", RFC-943,
+      Information Sciences Institute, University of Southern California,
+      Marina del Rey, April 1985.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Harrenstien & Stahl & Feinler                                   [Page 6]
+